Network Working Group M. Miller
Internet-Draft P. Saint-Andre
Intended status: Standards Track Cisco Systems, Inc.
Expires: March 10, 2014 September 06, 2013
PKIX over Secure HTTP (POSH)
draft-miller-posh-01
Abstract
Experience has shown that it is extremely difficult to deploy proper
PKIX certificates for TLS in multi-tenanted environments, since
certification authorities will not issue certificates for hosted
domains to hosting services, hosted domains do not want hosting
services to hold their private keys, and hosting services wish to
avoid liability for holding those keys. As a result, domains hosted
in multi-tenanted environments often deploy non-HTTP applications
such as email and instant messaging using certificates that identify
the hosting service, not the hosted domain. Such deployments force
end users and peer services to accept a certificate with an improper
identifier, resulting in obvious security implications. This
document defines two methods that make it easier to deploy
certificates for proper server identity checking in non-HTTP
application protocols. The first method enables the TLS client
associated with a user agent or peer application server to obtain the
end-entity certificate of a hosted domain over secure HTTP as an
alternative to standard PKIX techniques. The second method enables a
hosted domain to securely delegate a non-HTTP application to a
hosting service using redirects provided by HTTPS itself or by a
pointer in a file served over HTTPS at the hosted domain.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 10, 2014.
Miller & Saint-Andre Expires March 10, 2014 [Page 1]
Internet-Draft POSH September 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Obtaining Verification Materials . . . . . . . . . . . . . . 4
4.1. Source Domain Possesses PKIX Certificate . . . . . . . . 5
4.2. Source Domain References PKIX Certificate . . . . . . . . 7
4.3. Performing Verification . . . . . . . . . . . . . . . . . 8
5. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 9
6. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9
7. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 9
8. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
We start with a thought experiment.
Imagine that you work on the operations team of a hosting company
that provides the "foo" service (or email or instant messaging or
social networking service) for ten thousand different customer
organizations. Each customer wants their service to be identified by
the customer's domain name (e.g., foo.example.com), not the hosting
company's domain name (e.g., hosting.example.net).
Miller & Saint-Andre Expires March 10, 2014 [Page 2]
Internet-Draft POSH September 2013
In order to properly secure each customer's "foo" service via
Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX
certificates [RFC5280] containing identifiers such as
foo.example.com, as explained in the "CertID" specification
[RFC6125]. Unfortunately, you can't obtain such certificates
because:
o Certification authorities won't issue such certificates to you
because you work for the hosting company, not the customer
organization.
o Customers won't obtain such certificates and then give them (plus
the associated private keys) to you because their legal department
is worried about liability.
o You don't want to install such certificates (plus the associated
private keys) on your servers anyway because your legal department
is worried about liability, too.
Given your inability to deploy public keys / certificates containing
the right identifiers, your back-up approach was always to use a
certificate containing hosting.example.net as the identifier.
However, more and more customers and end users are complaining about
warning messages in user agents and the inherent security issues
involved with taking a "leap of faith" to accept the identity
mismatch between the source domain (foo.example.com) and the
delegated domain (hosting.example.net).
This situation is both insecure and unsustainable. You have
investigated the possibility of using DNS Security [RFC4033] and DNS-
Based Authentication of Named Entities (DANE) [RFC6698] to solve the
problem. However, your customers and your operations team have told
you that they will not be able to deploy DNSSEC and DANE for several
years at least. The product managers in your company are pushing you
to find a method that can be deployed more quickly to overcome the
lack of proper server identity checking for your hosted customers.
One possible approach is to ask each customer to provide the public
key / certificate for the "foo" service at a special HTTPS URI on
their website ("https://foo.example.com/.well-known/posh.foo.json" is
one possibility). This could be a public key that you generate for
the customer, but because the customer hosts it via HTTPS, any user
agent can find that public key and check it against the public key
you provide during TLS negotiation for the "foo" service (as one
added benefit, the customer never needs to hand you a private key).
Alternatively, the customer can redirect requests for that special
Miller & Saint-Andre Expires March 10, 2014 [Page 3]
Internet-Draft POSH September 2013
HTTPS URI to an HTTPS URI at your own website, thus making it
explicit that they have delegated the "foo" service to you.
The approach sketched out above, called POSH ("PKIX Over Secure
HTTP"), is explained in the remainder of this document.
2. Discussion Venue
The discussion venue for this document is the posh@ietf.org mailing
list; visit https://www.ietf.org/mailman/listinfo/posh for
subscription information and discussion archives.
3. Terminology
This document inherits security terminology from [RFC5280]. The
terms "source domain", "derived domain", "reference identifier", and
"presented identifier" are used as defined in the "CertID"
specification [RFC6125].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
4. Obtaining Verification Materials
Server identity checking (see [RFC6125]) involves three different
aspects:
1. A proof of the TLS server's identity (in PKIX, this takes the
form of a PKIX certificate [RFC5280]).
2. Rules for checking the certificate (which vary by application
protocol, although [RFC6125] attempts to harmonize those rules).
3. The materials that a TLS client uses to verify the TLS server's
identity or check the TLS server's proof (in PKIX, this takes the
form of chaining the end-entity certificate back to a trusted
root and performing all validity checks as described in
[RFC5280], [RFC6125], and the relevant application protocol
specification).
When POSH is used, the first two aspects remain the same: the TLS
server proves it identity by presenting a PKIX certificate [RFC5280]
and the certificate is checked according to the rules defined in the
appropriate application protocol specification (such as [RFC6120] for
Miller & Saint-Andre Expires March 10, 2014 [Page 4]
Internet-Draft POSH September 2013
XMPP). However, the TLS client obtains the materials it will use to
verify the server's proof by retrieving a JSON Web Key (JWK) set
[JOSE-JWK] over HTTPS ([RFC2616] and [RFC2818]) from a well-known URI
[RFC5785].
The process for retrieving a PKIX certificate over secure HTTP is as
follows.
1. The TLS client performs an HTTPS GET at the source domain to the
path "/.well-known/posh.{servicedesc}.json". The value of
"{servicedesc}" is application-specific; see Section 9 of this
document for more details. For example, if the application
protocol is some hypothetical "Foo" service, then "{servicedesc}"
could be "foo"; thus if a Foo client were to use POSH to verify a
Foo server for the domain "foo.example.com", the HTTPS GET
request would be as follows:
GET /.well-known/posh.foo.json HTTP/1.1
Host: foo.example.com
2. The source domain HTTPS server responds in one of three ways:
* If it possesses a PKIX certificate for the requested path, it
responds as detailed in Section 4.1.
* If it has a reference to where the PKIX certificate can be
obtained, it responds as detailed in Section 4.2.
* If it does not have any PKIX certificate for the requested
path, it responds with a client error status code (e.g., 404).
4.1. Source Domain Possesses PKIX Certificate
If the source domain HTTPS server possesses the certificate
information, it responds to the HTTPS GET with a success status code
and the message body set to a JSON Web Key (JWK) set [JOSE-JWK]. The
JWK set MUST contain at least one JWK object.
Each included JWK object MUST possess the following information:
Miller & Saint-Andre Expires March 10, 2014 [Page 5]
Internet-Draft POSH September 2013
o The "kty" field set to the appropriate key type used for TLS
connections (e.g., "RSA" for a certificate using an RSA key).
o The required parameters for the key type (e.g., "n" and "e" for a
certificate using an RSA key).
Additionally, each JWK object MUST possess at least one of the
following:
o The "x5t" field set to the certificate thumbprint, as per section
3.6 of [JOSE-JWK].
o The "x5c" field set to the certificate chain, as per section 3.7
of [JOSE-JWK].
The following example illustrates the usage described above.
Example Content Response
HTTP/1.1 200 OK
Content-Type: application/jwk-set+json
Content-Length: 2785
{
"keys": [
{
"kty": "RSA",
"kid": "c8fb8b80-1193-11e3-b2b1-835742119fe8",
"n": "ANxwssdcU3LbODErec3owrwUhlzjtuskAn8rAcBMRPImn5xA
JRX-1T5g2D7MTozWWFk4TlpgzAR5slvM0tc35qAI9I0Cqk4Z
LChQrYsWuY7alTrnNXdusHUYc6Eq89DZaH2knTcp57wAXzJP
IG_tpBi5F7ck9LVRvRjybix0HJ7i4YrL-GeLuSgrjO4-GDcX
Ip8oV0FMKZH-NoMfUITlWYl_JcX1D0WUAiuAnvWtD4Kh_qMJ
U6FZuupZGHqPdc3vrXtp27LWgxzxjFa9qnOU6y53vCCJXLLI
5sy2fCwEDzLJqh2T6UItIzjrSUZMIsK8r2pXkroI0uYuNn3W
y-jAzK8",
"e": "AQAB",
"x5t": "UpjRI_A3afKE8_AIeTZ5o1dECTY",
"x5c": [
"MIIDgzCCAmugAwIBAgIBBjANBgkqhkiG9w0BAQUFADBGMQswCQYDV
QQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
ZlcjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMTA3MDQwMDAwMDB
aFw0xMzA3MDIyMzU5NTlaMEoxCzAJBgNVBAYTAlVTMREwDwYDVQQI
EwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRcwFQYDVQQDEw5pb
S5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQ
oCggEBANxwssdcU3LbODErec3owrwUhlzjtuskAn8rAcBMRPImn5x
Miller & Saint-Andre Expires March 10, 2014 [Page 6]
Internet-Draft POSH September 2013
AJRX+1T5g2D7MTozWWFk4TlpgzAR5slvM0tc35qAI9I0Cqk4ZLChQ
rYsWuY7alTrnNXdusHUYc6Eq89DZaH2knTcp57wAXzJPIG/tpBi5F
7ck9LVRvRjybix0HJ7i4YrL+GeLuSgrjO4+GDcXIp8oV0FMKZH+No
MfUITlWYl/JcX1D0WUAiuAnvWtD4Kh/qMJU6FZuupZGHqPdc3vrXt
p27LWgxzxjFa9qnOU6y53vCCJXLLI5sy2fCwEDzLJqh2T6UItIzjr
SUZMIsK8r2pXkroI0uYuNn3Wy+jAzK8CAwEAAaN4MHYwDAYDVR0TA
QH/BAIwADAdBgNVHQ4EFgQUTmRcur7xqaIUoU6wjVFPFxpf3UYwCw
YDVR0PBAQDAgXgMCcGA1UdEQQgMB6gHAYIKwYBBQUHCAWgEAwOaW0
uZXhhbXBsZS5jb20wEQYJYIZIAYb4QgEBBAQDAgZAMA0GCSqGSIb3
DQEBBQUAA4IBAQBrtpz4USAT+gNWI8ccU9rFiP0Jr+76VCf8Leims
qjINfKuUFxVUK5TBcCU8pyRUdXBk5THt+LUW+bPqE4SAuKjTJ1wwm
e8kOqtsvrr6XDfPHyX6H7nQAaKD0VbvbHfTBKh6jNVVi+4gJACeSE
JdiskoNYuJAxNDI8DmN9qAxu/8dlQHlIT3NkTxMWFUdmW8rj2xdia
nfZEwuPXoI93jdpgvGhcSM92ahumFyEZ5ysK6KFsXyUmVuOQFaVsH
tSAwrSGr70ASLzsCAi7JsvzO53QFW/KddkFLvEwCh/tgKK876poBo
x1NI6YYuWqhcKWADOOJdSfiXeu23E25tlbDRo8",
"MIIDWTCCAkGgAwIBAgIBATANBgkqhkiG9w0BAQUFADBGMQswCQYDV
QQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
ZlcjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMTA1MDIwMDAwMDB
aFw0yMzA1MTYyMzU5NTlaMEYxCzAJBgNVBAYTAlVTMREwDwYDVQQI
EwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRMwEQYDVQQDEwpFe
GFtcGxlIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQ
EAzNQ30X7uXTg+4jKadtRO5uQEMRMnkZvDnptbWAtx0d1PsufQ2kf
vog0gDhigjPEZDV9S+zm63Ia+eqJ3ROT9jDXjtF6s/IawITf5cPSN
xn8qP8w+vbiy0rB4W4Nk1Dwji7KJ/wKNo0mwOx/qWNjSk3yoaU4sU
EuIypizgLxKAr25vVvAJAxF6HAfdQoVAIdCZ/7qbBPI7aurdU/Ndm
bbKBK0lp8aV1MYLzz8DI0hWcBQa2+gOSUcd/yT1az7UpMjGllbnVl
UDxyJeCzbBaHny5NlWWHsGnsbucbM+9yeAMbRes/z0KeHxcRtomd8
bh7As12RIXKrk5GRoNVKAoiwLQIDAQABo1IwUDAPBgNVHRMBAf8EB
TADAQH/MB0GA1UdDgQWBBSyiet77RfWpH3X8NMwGFVu2ldJPTALBg
NVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgAHMA0GCSqGSIb3DQE
BBQUAA4IBAQBd1mMx4Wx9xFLqecbjWyy7tOE2+mrWhWxg82q7z3bB
rHWjUGzolHe97Ch+6QI3+MPk9JQWYaMgYe11tyf0mgZ18NFQall4M
ho2yT+E8ju11PW+RNqUdRG6rZfdeN5Geb1o1L2g5WNTdtPXoFYgHY
VPQ1HmjloEic2eGnlBvOi49wAdwnASv53fgzkSJB2/GdBJ3wPIWp0
49/1vS5rsF5SJg+3mj3ZAuPYt80TRKbA/cjxEny5RfK+VJs3f7RQ/
Y3CTPxoJqskWs06/eUpjXKyzZ+MmkCs5cm1yers8goWhaI8JmLlBW
LQE6v8MHdbUfb4M8la5cUd2BGtTlILOVnMv"
]
}
]
}
4.2. Source Domain References PKIX Certificate
Miller & Saint-Andre Expires March 10, 2014 [Page 7]
Internet-Draft POSH September 2013
If the source domain HTTPS server has a reference to the certificate
information, it responds to the HTTPS GET with a JSON document. The
document contains a "url" field whose value is the HTTPS URL where
TLS clients can obtain the actual JWK set.
Example Reference Response
HTTP/1.1 200 Ok
Content-Type: application/json
Content-Length: 78
{
"url":"https://hosting.example.com/.well-known/
posh.foo.json"
}
The client performs an HTTPS GET for the URL specified in the "url"
field value. The HTTPS server for the URI at which the client has
been redirected responds to the request with a JWK set. The content
retrieved from the "url" location MUST NOT itself be a reference
(e.g., containing only the "url" field and no "keys" field), in order
to prevent circular references.
Note: The JSON document returned by the source domain HTTPS server
MUST contain either a reference or a JSON Web Key set, but MUST NOT
contain both.
4.3. Performing Verification
The TLS client compares the PKIX information obtained from the TLS
server against each JWK object in the POSH results, until a match is
found or the collection of POSH verification materials is exhausted.
If none of the JWK objects match the TLS server PKIX information, the
TLS client SHOULD reject the connection.
The TLS client SHOULD compare the fingerprint of the PKIX certificate
from the TLS server against the "x5t" field of the JWK object (note
the "x5t" field is the base64url encoding of the fingerprint). If
the "x5c" field is present instead of the "x5t" field, the TLS client
generates a fingerprint of the first array element, by performing a
SHA-1 hash over the PKIX certificate's DER encoding.
The TLS client MAY verify the certificate chain provided in the "x5c"
field of the JWK object, but it MUST NOT implicitly consider the
final certificate in the "x5c" field to be a trust anchor itself; the
TLS client only uses the end entity certificate information for
verification.
Miller & Saint-Andre Expires March 10, 2014 [Page 8]
Internet-Draft POSH September 2013
5. Secure Delegation
The delegation from the source domain to the delegated domain can be
considered secure if the certificate offered by the TLS server
matches the POSH certificate, regardless of how the POSH certificates
are obtained.
6. Order of Operations
In order for the TLS client to perform verification of reference
identifiers without potentially compromising data, POSH processes
MUST be complete before any application-level data is exchanged for
the source domain. The TLS client SHOULD perform all POSH retrievals
before opening any socket connections to the application protocol
server. For application protocols that use DNS SRV, the POSH
processes ideally ought to be done in parallel with resolving the SRV
records and the addresses of any targets, similar to the "happy
eyeballs" approach for IPv4 and IPv6 [RFC6555].
7. Caching Results
Ideally, the TLS client relies on the expiration time of the
certificate obtained via POSH, and not on HTTP caching mechanisms.
To that end, the HTTPS servers for source and derived domains SHOULD
specify a 'Cache-Control' header indicating a short duration (e.g.,
max-age=60) or "no-cache" to indicate that the response (redirect or
content) is not appropriate to cache at the HTTP level.
8. Alternates and Roll-over
To indicate alternate PKIX certificates (such as when an existing
certificate will soon expire), the returned JWK set MAY contain
multiple JWK objects. The JWK set SHOULD be ordered with the most
relevant certificate first as determined by the application service
operator (e.g., the renewed certificate), followed by the next most
relevant certificate (e.g., the certificate soonest to expire). Here
is an example:
{
"keys":[
{
"kty": "RSA",
"kid": "cfc0ca70-1193-11e3-b2b1-835742119fe8",
"n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq
MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT
YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk
0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1
0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng
Miller & Saint-Andre Expires March 10, 2014 [Page 9]
Internet-Draft POSH September 2013
0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L
w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T
vYceNlE",
"e": "AQAB",
"x5t": "Ae0sLVtm78VT-mQXJQop-ENOM6o",
"x5c": [
"MIIDXzCCAkegAwIBAgIBAzANBgkqhkiG9w0BAQUFADBGMQswCQYDV
QQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
ZlcjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMTA3MDQxOTUyMDB
aFw0xMzA3MDMxOTUyMDBaME8xCzAJBgNVBAYTAlVTMREwDwYDVQQI
EwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQDExNob
3N0aW5nLmV4YW1wbGUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ
8AMIIBCgKCAQEAz6S1aRDxu2P8cR0ADqQ6nMkaCgc1mwmbGOH8+J+
mABR9B6ow79gFHXTQh0llHMl9QvKFHCf1uKQKrztZOjGA9Y6d3ewf
epNiIBwhHlLq0FuzKnpZibAzXK4LS8sKjpKgPN0rVK+RAozdBaTQY
U1TiXipdgAzFpLDzeLrK/kMFVtJPsT3a9Loar/imAjbqXXQmHJtm5
MRU9FQIbqlMoBdCkvGaMnmgb0z3VE/Xuey5B4Ts2DQCngEGfmGhyi
OR+2HCBtfiWoEx5ykECeTLmOfqyWbNL+sv4vD7/yFSV1pM8P0weUc
+u9yxFXm7DzArkwHpDJ9LrAXhvQqPZO9hx42UQIDAQABo08wTTAMB
gNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ/veMa6XwrIaUv8Y7PmW0RyA
Um9jALBgNVHQ8EBAMCBeAwEQYJYIZIAYb4QgEBBAQDAgZAMA0GCSq
GSIb3DQEBBQUAA4IBAQA7V50iyHg8+l2UBkFa8l6APKQ5zL2qN8d3
sE3mDK5a6l/597xHDxzHKMmROvHD9+MHZtYxbB0dHz1lJY0zCUAgo
nfYc9J3VB4kKPB9H7u8h70pRuPudFWvQ4ZRraRPm7eSP+7/kTlOKa
MCpBCiA95GKAbsbY3vQ0Hkmu5sgbIwGNs5x5V4kZSN9AfFHcmaQ2K
ZufaiLjLPj6UC5CObGXjsMCWMiS7kzw8GWxnQ9viCM0uopmraMOUH
cPnmtlzXparpWbiFKXGwFo1qU9QntoO71kJwVm9+ABl+lMD22WKxj
5DDutWSyxV7Nbbhni/j6HdWHNNcCNllbKzqJ54RhDoi",
"MIIDWTCCAkGgAwIBAgIBATANBgkqhkiG9w0BAQUFADBGMQswCQYDV
QQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
ZlcjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMTA1MDIwMDAwMDB
aFw0yMzA1MTYyMzU5NTlaMEYxCzAJBgNVBAYTAlVTMREwDwYDVQQI
EwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRMwEQYDVQQDEwpFe
GFtcGxlIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQ
EAzNQ30X7uXTg+4jKadtRO5uQEMRMnkZvDnptbWAtx0d1PsufQ2kf
vog0gDhigjPEZDV9S+zm63Ia+eqJ3ROT9jDXjtF6s/IawITf5cPSN
xn8qP8w+vbiy0rB4W4Nk1Dwji7KJ/wKNo0mwOx/qWNjSk3yoaU4sU
EuIypizgLxKAr25vVvAJAxF6HAfdQoVAIdCZ/7qbBPI7aurdU/Ndm
bbKBK0lp8aV1MYLzz8DI0hWcBQa2+gOSUcd/yT1az7UpMjGllbnVl
UDxyJeCzbBaHny5NlWWHsGnsbucbM+9yeAMbRes/z0KeHxcRtomd8
bh7As12RIXKrk5GRoNVKAoiwLQIDAQABo1IwUDAPBgNVHRMBAf8EB
TADAQH/MB0GA1UdDgQWBBSyiet77RfWpH3X8NMwGFVu2ldJPTALBg
NVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgAHMA0GCSqGSIb3DQE
BBQUAA4IBAQBd1mMx4Wx9xFLqecbjWyy7tOE2+mrWhWxg82q7z3bB
rHWjUGzolHe97Ch+6QI3+MPk9JQWYaMgYe11tyf0mgZ18NFQall4M
ho2yT+E8ju11PW+RNqUdRG6rZfdeN5Geb1o1L2g5WNTdtPXoFYgHY
VPQ1HmjloEic2eGnlBvOi49wAdwnASv53fgzkSJB2/GdBJ3wPIWp0
49/1vS5rsF5SJg+3mj3ZAuPYt80TRKbA/cjxEny5RfK+VJs3f7RQ/
Miller & Saint-Andre Expires March 10, 2014 [Page 10]
Internet-Draft POSH September 2013
Y3CTPxoJqskWs06/eUpjXKyzZ+MmkCs5cm1yers8goWhaI8JmLlBW
LQE6v8MHdbUfb4M8la5cUd2BGtTlILOVnMv"
]
},
{
"kty": "RSA",
"kid": "dbc28570-1193-11e3-b2b1-835742119fe8",
"n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq
MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT
YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk
0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1
0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng
0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L
w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T
vYceNlE",
"e": "AQAB",
"x5t": "lYZC2n9TBpOaUsBclEIacQTKToA",
"x5c": [
"MIIDjTCCAnWgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBGMQswCQYDV
QQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZ
lcjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMzA1MTcwMDAwMDBaF
w0xNTA1MTYyMzU5NTlaME8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwh
Db2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQDExNob3N0a
W5nLmV4YW1wbGUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMII
BCgKCAQEAz6S1aRDxu2P8cR0ADqQ6nMkaCgc1mwmbGOH8+J+mABR9B
6ow79gFHXTQh0llHMl9QvKFHCf1uKQKrztZOjGA9Y6d3ewfepNiIBw
hHlLq0FuzKnpZibAzXK4LS8sKjpKgPN0rVK+RAozdBaTQYU1TiXipd
gAzFpLDzeLrK/kMFVtJPsT3a9Loar/imAjbqXXQmHJtm5MRU9FQIbq
lMoBdCkvGaMnmgb0z3VE/Xuey5B4Ts2DQCngEGfmGhyiOR+2HCBtfi
WoEx5ykECeTLmOfqyWbNL+sv4vD7/yFSV1pM8P0weUc+u9yxFXm7Dz
ArkwHpDJ9LrAXhvQqPZO9hx42UQIDAQABo30wezAMBgNVHRMBAf8EA
jAAMB0GA1UdDgQWBBQ/veMa6XwrIaUv8Y7PmW0RyAUm9jALBgNVHQ8
EBAMCBeAwLAYDVR0RBCUwI6AhBggrBgEFBQcIBaAVDBNob3N0aW5nL
mV4YW1wbGUubmV0MBEGCWCGSAGG+EIBAQQEAwIGQDANBgkqhkiG9w0
BAQUFAAOCAQEAfb3++qh/bxsVtcEWmNtj1QLTBiXC5T9U6NuWUKY3a
RTIsthO5yLsToUG1bbxLceVG+xPQT9uRqvV02sumiIn3gv87NU5gMR
b1Gy1P9N0YT5GiHCN5qCfegGH6jIokh0Js3v+ttR/rUns0/MEsr/ka
YQ7KRKzOdlxT+gWN9Lp0fOYdYcasDWNMTg1NZwzXKcdkhb1lRBYuP4
SeiJvy6ZbyUnoswthVTe0CK9+StDtJZLPSUu7TB2MwYMnv344NoTO2
ufRawLU0+8cJZxrXq/H/YQyoAFB9opw0wEoTIB5aZqI2em4Wjgx9sl
aonFlLEQysm5qJnhTGxEIDxQfqCcRfw==",
"MIIDWTCCAkGgAwIBAgIBATANBgkqhkiG9w0BAQUFADBGMQswCQYDVQ
QGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZl
cjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMTA1MDIwMDAwMDBaFw
0yMzA1MTYyMzU5NTlaMEYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhD
b2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRMwEQYDVQQDEwpFeGFtcG
xlIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNQ3
0X7uXTg+4jKadtRO5uQEMRMnkZvDnptbWAtx0d1PsufQ2kfvog0gDh
Miller & Saint-Andre Expires March 10, 2014 [Page 11]
Internet-Draft POSH September 2013
igjPEZDV9S+zm63Ia+eqJ3ROT9jDXjtF6s/IawITf5cPSNxn8qP8w+
vbiy0rB4W4Nk1Dwji7KJ/wKNo0mwOx/qWNjSk3yoaU4sUEuIypizgL
xKAr25vVvAJAxF6HAfdQoVAIdCZ/7qbBPI7aurdU/NdmbbKBK0lp8a
V1MYLzz8DI0hWcBQa2+gOSUcd/yT1az7UpMjGllbnVlUDxyJeCzbBa
Hny5NlWWHsGnsbucbM+9yeAMbRes/z0KeHxcRtomd8bh7As12RIXKr
k5GRoNVKAoiwLQIDAQABo1IwUDAPBgNVHRMBAf8EBTADAQH/MB0GA1
UdDgQWBBSyiet77RfWpH3X8NMwGFVu2ldJPTALBgNVHQ8EBAMCAQYw
EQYJYIZIAYb4QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQBd1m
Mx4Wx9xFLqecbjWyy7tOE2+mrWhWxg82q7z3bBrHWjUGzolHe97Ch+
6QI3+MPk9JQWYaMgYe11tyf0mgZ18NFQall4Mho2yT+E8ju11PW+RN
qUdRG6rZfdeN5Geb1o1L2g5WNTdtPXoFYgHYVPQ1HmjloEic2eGnlB
vOi49wAdwnASv53fgzkSJB2/GdBJ3wPIWp049/1vS5rsF5SJg+3mj3
ZAuPYt80TRKbA/cjxEny5RfK+VJs3f7RQ/Y3CTPxoJqskWs06/eUpj
XKyzZ+MmkCs5cm1yers8goWhaI8JmLlBWLQE6v8MHdbUfb4M8la5cU
d2BGtTlILOVnMv"
]
}
]
}
9. IANA Considerations
This document registers a well-known URI [RFC5785] for protocols that
use POSH. The completed template follows.
URI suffix: posh.
Change controller: IETF
Specification document: [[ this document ]]
Related information: Because the "posh." string is merely a
prefix, protocols that use POSH need to register particular
URIs that are prefixed with the "posh." string.
Note that the registered URI is "posh." (with a trailing dot). This
is merely a prefix to be placed at the front of well-known URIs
[RFC5785] registered by protocols that use POSH, which themselves are
responsible for the relevant registrations with the IANA. The URIs
registered by such protocols SHOULD begin with "posh." and end with
".json" (indicating a media type of application/json [RFC4627] or
application/jwk-set+json [JOSE-JWK]).
For POSH-using protocols that rely on DNS SRV records [RFC2782], the
part of the well-known URI between "posh." and ".json" SHOULD be
Miller & Saint-Andre Expires March 10, 2014 [Page 12]
Internet-Draft POSH September 2013
"{service}.{proto}", where the "{service}" is the DNS SRV "Service"
prepended by the underscore character "_" and the "{proto}" is the
DNS SRV "Proto" also prepended by the underscore character "_". As
an example, the well-known URI for XMPP server-to-server connections
would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
a service name of "xmpp-server" and uses TCP as the underlying
transport protocol.
For other POSH-using protocols, the part of the well-known URI
between "posh." and ".json" can be any unique string or identifier
for the protocol, which might be a service name registered with the
IANA in accordance with [RFC6335] or which might be an unregistered
name. As an example, the well-known URI for the mythical "Foo"
service could be "posh.foo.json".
Note: As explained in [RFC5785], the IANA registration policy
[RFC5226] for well-known URIs is Specification Required.
10. Security Considerations
This document supplements but does not supersede the security
considerations provided in specifications for application protocols
that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP).
Specifically, the security of requests and responses sent via HTTPS
depends on checking the identity of the HTTP server in accordance
with [RFC2818]. Additionally, the security of POSH can benefit from
other HTTP hardening protocols, such as HSTS [RFC6797] and key
pinning [KEYPIN], especially if the TLS client shares some
information with a common HTTPS implementation (e.g., platform-
default web browser).
Note well that POSH is used by a TLS client to obtain the public key
of a TLS server to which it might connect for a particular
application protocol such as IMAP or XMPP. POSH does not enable a
hosted domain to transfer private keys to a hosting service via
HTTPS. POSH also does not enable a TLS server to engage in
certificate enrollment with a certification authority via HTTPS, as
is done in Enrollment over Secure Transport [EST].
11. References
11.1. Normative References
[JOSE-JWK]
Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key-14 (work in progress), July 2013.
Miller & Saint-Andre Expires March 10, 2014 [Page 13]
Internet-Draft POSH September 2013
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April
2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
11.2. Informative References
[EST] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over
Secure Transport", draft-ietf-pkix-est-09 (work in
progress), August 2013.
[KEYPIN] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", draft-ietf-websec-key-pinning-04
(work in progress), December 2012.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, May 2005.
Miller & Saint-Andre Expires March 10, 2014 [Page 14]
Internet-Draft POSH September 2013
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTPS Strict
Transport Security (HSTS)", RFC 6797, November 2012.
Appendix A. Acknowledgements
Many thanks to Philipp Hancke, Joe Hildebrand, and Tobias Markmann
for their implementation feedback. Thanks also to Dave Cridland, Max
Pritikin, and Joe Salowey for their input on the specification.
Authors' Addresses
Matthew Miller
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Email: mamille2@cisco.com
Peter Saint-Andre
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Email: psaintan@cisco.com
Miller & Saint-Andre Expires March 10, 2014 [Page 15]