One document matched: draft-miller-posh-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miller-posh-00" ipr="trust200902">
<front>
<title abbrev="POSH">PKIX over Secure HTTP (POSH)</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>psaintan@cisco.com</email>
</address>
</author>
<date/>
<area>SEC</area>
<keyword>Internet-Draft</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>federation</keyword>
<abstract>
<t>This document defines two methods that make it easier to deploy certificates for proper server identity checking in application protocols. The first method enables a TLS client to obtain a TLS server's end-entity certificate over secure HTTP as an alternative to standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based Authentication of Named Entities (DANE). The second method enables a source domain to securely delegate an application to a derived domain using HTTPS redirects.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>Channel encryption with TLS depends on proper checking of the server's identity, as specified in <xref target='RFC6125'/> or its application-specific equivalent for Public Key Infrastructure using X.509 (PKIX) <xref target='RFC5280'/> and in <xref target='RFC6698'/> for DNS-Based Authentication of Named Entities (DANE). However, in multi-tenanted environments it is effectively impossible for a hosting service to offer the correct PKIX certificates on behalf of a hosted domain, since neither party wants the hosting service to hold the hosted domain's private keys. As a result, typically the hosting service offers its own PKIX certificate (say, for hosting.example.net), which means that TLS clients need to "just know" that the hosted domain (say, foo.example.com) is offered at the hosting service rather than the hosted domain. Further background information on this problem can be found in <xref target='XMPP-DNA'/>.</t>
<t>This situation is clearly insecure. It is true that DNS-based technologies are emerging for secure delegation, in the form of DNS SRV records <xref target='RFC2782'/> or their functional equivalent when DNS Security <xref target="RFC4033"/> is used, along with DNS-Based Authentication of Named Entities (DANE) <xref target="RFC6698"/>. However, these technologies are not yet widely deployed and might not be deployed in the near future for domains outside the most common top-level domains. Hosting services and hosted domains need a method that can be deployed more quickly to overcome the lack of secure delegation and proper server identity checking on the Internet today.</t>
<t>POSH (PKIX Over Secure HTTP) provides two interconnected methods for solving the problem, at least with application protocols other than HTTP:</t>
<t>
<list style='numbers'>
<t>A TLS client retrieves the material to be used in checking the TLS server's identity by requesting it from a well-known HTTPS URI, where the response contains one or more certificates formatted as a JSON Web Key set <xref target='JOSE-JWK'/> defined within the JOSE WG.<vspace blankLines='1'/></t>
<t>If a hosted domain securely delegates an application to a hosting service, it redirects all requests for the well-known HTTPS URI to an HTTPS URI at the hosting service.</t>
</list>
</t>
<t>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.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits security terminology from <xref target="RFC5280"/>. The terms "source domain", "derived domain", "reference identifier", and "presented identifier" are used as defined in the "CertID" specification <xref target="RFC6125"/>.</t>
<t>This document uses the Extensible Messaging and Presence Protocol (XMPP) <xref target='RFC6120'/> in its examples. Whether connections are made from an XMPP client to an XMPP server (based on a DNS SRV record of "_xmpp-client._tcp") or between XMPP servers ("_xmpp-server._tcp"), the XMPP initiating entity acts as a TLS client and the XMPP receiving entity acts as a TLS server. Therefore, to simplify discussion this document uses "_xmpp-client._tcp" to describe both cases, unless otherwise indicated.</t>
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Obtaining Verification Materials" anchor="obtain">
<t>Server identity checking (see <xref target='RFC6125'/>) involves three different aspects:</t>
<t>
<list style='numbers'>
<t>A proof of the TLS server's identity (in PKIX, this takes the form of a PKIX certificate <xref target='RFC5280'/>).</t>
<t>Rules for checking the certificate (which vary by application protocol, although <xref target='RFC6125'/> attempts to harmonize those rules).</t>
<t>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 <xref target='RFC5280'/>, <xref target='RFC6125'/>, and the relevant application protocol specification).</t>
</list>
</t>
<t>When POSH is used, the first two aspects remain the same: the TLS server proves it identity by presenting a PKIX certificate <xref target="RFC5280"/> and the certificate is checked according to the rules defined in the appropriate application protocol specification (such as <xref target="RFC6120"/> for XMPP). However, the TLS client obtains the material it will use to verify the server's proof by retrieving a JSON Web Key (JWK) set <xref target='JOSE-JWK'/> over HTTPS (<xref target="RFC2616"/> and <xref target="RFC2818"/>) from a well-known URI <xref target="RFC5785"/>. (In this case, secure DNS is not necessary since the HTTPS retrieval mechanism relies on the chain of trust based on the public key infrastructure.)</t>
<t>The process for retrieving a PKIX certificate over secure HTTP is as follows.</t>
<t>
<list style="numbers">
<t>The TLS client performs an HTTPS GET at the source domain to the path "/.well-known/posh.{service}.{protocol}.json". For example, if the application protocol is XMPP then the "{service}" is either "_xmpp-client" for XMPP client-to-server connections, and the "{protocol}" is "_tcp"; thus if an XMPP client were to use POSH to verify an XMPP server for the domain "im.example.com", the HTTPS GET request would be as follows:
<vspace blankLines='1'/>
<figure>
<artwork><![CDATA[
GET /.well-known/posh._xmpp-client._tcp.json HTTP/1.1
Host: im.example.com
]]></artwork>
</figure>
</t>
<t>The source domain HTTPS server responds in one of three ways:<vspace blankLines="1"/>
<list style="symbols">
<t>If it possesses a PKIX certificate for the requested path, it responds as detailed in <xref target="prooftype-possess"/>.<vspace blankLines="1"/></t>
<t>If it has a reference to where the PKIX certificate can be obtained, it responds as detailed in <xref target="prooftype-ref"/>.<vspace blankLines='1'/></t>
<t>If it does not have any PKIX certificate for the requested path, it responds with a client error status code (e.g., 404).</t>
</list>
</t>
</list>
</t>
<section title="Source Domain Possesses PKIX Certificate" anchor="prooftype-possess">
<t>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 <xref target="JOSE-JWK"/>. The JWK set MUST contain at least one JWK with the following information:</t>
<t>
<list style="symbols">
<t>The "kty" field set to the appropriate key type (e.g., "RSA" for a certificate using an RSA key).<vspace blankLines="1"/></t>
<t>The required fields for the key type (e.g., "n" and "e" for a certificate using an RSA key).<vspace blankLines="1"/></t>
<t>The "x5c" field set to the certificate chain.</t>
</list>
</t>
<t>
<figure>
<preamble>Example Content Response</preamble>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/jwk-set+json
Content-Length: 2785
{
"keys": [
{
"kty": "RSA",
"kid": "im.example.com:2011-07-04",
"n": "ANxwssdcU3LbODErec3owrwUhlzjtuskAn8rAcBMRPImn5xA
JRX-1T5g2D7MTozWWFk4TlpgzAR5slvM0tc35qAI9I0Cqk4Z
LChQrYsWuY7alTrnNXdusHUYc6Eq89DZaH2knTcp57wAXzJP
IG_tpBi5F7ck9LVRvRjybix0HJ7i4YrL-GeLuSgrjO4-GDcX
Ip8oV0FMKZH-NoMfUITlWYl_JcX1D0WUAiuAnvWtD4Kh_qMJ
U6FZuupZGHqPdc3vrXtp27LWgxzxjFa9qnOU6y53vCCJXLLI
5sy2fCwEDzLJqh2T6UItIzjrSUZMIsK8r2pXkroI0uYuNn3W
y-jAzK8",
"e": "AQAB",
"x5c": [
"MIIDgzCCAmugAwIBAgIBBjANBgkqhkiG9w0BAQUFADBGMQswCQYDV
QQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
ZlcjETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMTA3MDQwMDAwMDB
aFw0xMzA3MDIyMzU5NTlaMEoxCzAJBgNVBAYTAlVTMREwDwYDVQQI
EwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRcwFQYDVQQDEw5pb
S5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQ
oCggEBANxwssdcU3LbODErec3owrwUhlzjtuskAn8rAcBMRPImn5x
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"
]
}
]
}
]]></artwork>
</figure>
</t>
<t>The TLS client uses the provided certificate to verify the TLS connection to the TLS server. In order for the TLS client to verify the identity of the TLS server, it MUST ensure that the PKIX certificate presented by the TLS server during the TLS negotiation matches the certificate that it obtained via POSH.</t>
<t>The TLS client MAY verify the certificate chain provided in the JWK, but it SHOULD consider the final issuer certificate to be a trust anchor for the purposes of this verification only. Once it has verified the identity of the TLS server, the TLS client MUST NOT continue to treat this final issuer certificate as a trust anchor.</t>
</section>
<section title="Source Domain References PKIX Certificate" anchor="prooftype-ref">
<t>If the source domain HTTPS server has a reference to the certificate information, it responds to the HTTPS GET with a redirect status code (e.g., 302, 303, 307, or 308), and includes a 'Location' header, which MUST specify an HTTPS URL.</t>
<t>
<figure>
<preamble>Example Redirect Response</preamble>
<artwork><![CDATA[
HTTP/1.1 302 Found
Location: https://hosting.example.net/.well-known
/posh._xmpp-client._tcp.json
]]></artwork>
</figure>
</t>
<t>The client follows the redirect, the HTTPS server for the URI at which the client has been redirected responds to the request, and the client performs actions appropriate to the new response (whether it is a possession, a reference, or another redirect).</t>
<section title="Redirect Status Codes" anchor="prooftype-ref-statuscodes">
<t>Care needs to be taken regarding the redirect mechanism is used for delegation. Clients might remember the redirected location in place of the original, which can lead to verification mismatches when a source domain is migrated to a different delegated domain.</t>
<t>To mitigate this concern, source domains SHOULD use only temporary redirect mechanisms, such as HTTP status codes 302 (Found) and 307 (Temporary Redirect). Clients MAY treat any redirect as temporary, ignoring the specific semantics for 301 (Moved Permanently) and 308 (Permanent Redirect) <xref target="HTTP-STATUS-308"/>.</t>
</section>
<section title="Redirect Depth" anchor="prooftype-ref-depth">
<t>To protect against circular references, clients MUST NOT follow an infinite number of redirects. It is RECOMMENDED that clients follow no more than 10 redirects, although applications or implementations can require that fewer redirects be followed.</t>
</section>
</section>
<section title="Additional Security Mechanisms" anchor="prooftype-more-sec">
<t>POSH can benefit from additional HTTPS security mechanisms, such as HTTP Strict Transport Security <xref target='RFC6797'/> and key pinning <xref target='KEYPIN'/>, especially if the TLS client shares some information with a common HTTPS implementation (e.g., platform-default web browser).</t>
</section>
</section>
<section title="Secure Delegation" anchor="delegation">
<t>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.</t>
</section>
<section title="Order of Operations" anchor="order">
<t>POSH processes MUST be complete before the end of the TLS handshake for the application protocol, so that the TLS client can perform verification of reference identifiers. Ideally a TLS client ought to perform the POSH processes in parallel with other application-level negotiation; this is sometimes called the "happy eyeballs" approach, similar to <xref target='RFC6555'/> for IPv4 and IPv6. However, a TLS client might delay as much of the application-level negotiation in order to gather all of the POSH-based verification material. For instance, a TLS client might not open the socket connection until it retrieves the PKIX certificates via POSH.</t>
</section>
<section title="Caching Results" anchor="caching">
<t>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.</t>
</section>
<section title="Alternates and Roll-over" anchor="rollover">
<t>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:</t>
<figure>
<artwork><![CDATA[
{
"keys":[
{
"kty": "RSA",
"kid": "hosting.example.net:2011-07-04",
"n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq
MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT
YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk
0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1
0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng
0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L
w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T
vYceNlE",
"e": "AQAB",
"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/
Y3CTPxoJqskWs06/eUpjXKyzZ+MmkCs5cm1yers8goWhaI8JmLlBW
LQE6v8MHdbUfb4M8la5cUd2BGtTlILOVnMv"
]
},
{
"kty": "RSA",
"kid": "hosting.example.net:2013-07-04",
"n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq
MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT
YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk
0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1
0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng
0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L
w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T
vYceNlE",
"e": "AQAB",
"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
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"
]
}
]
} ]]></artwork>
</figure>
</section>
<section title="Security Considerations" anchor="security">
<t>This document supplements but does not supersede the security considerations provided in specifications for application protocols that decide to use POSH (e.g., <xref target="RFC6120"/> and <xref target="RFC6125"/> for XMPP). Specifically, communication via HTTPS depends on checking the identity of the HTTP server in accordance with <xref target="RFC2818"/>.</t>
<t>Additionally, the security of POSH can benefit from other HTTP hardening protocols, such as HSTS <xref target="RFC6797"/> and key pinning <xref target="KEYPIN"/>.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>Protocols that use POSH MUST register an appropriate well-known URI or URIs <xref target='RFC5785'/> with the IANA. The IANA registration policy <xref target='RFC5226'/> is Specification Required.</t>
<t>The following sections register two such URIs for XMPP.</t>
<section title="The "posh._xmpp-client._tcp.json" Well-Known URI" anchor="iana-posh-client">
<t>This specification registers the "posh._xmpp-client._tcp.json" well-known URI in the Well-Known URI Registry as defined by <xref target="RFC5785"/>.</t>
<t>URI suffix: posh._xmpp-client._tcp.json</t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</section>
<section title="The "posh._xmpp-server._tcp.json" Well-Known URI" anchor="iana-posh-server">
<t>This specification registers the "posh._xmpp-server._tcp.json" well-known URI in the Well-Known URI Registry as defined by <xref target="RFC5785"/>.</t>
<t>URI suffix: posh._xmpp-server._tcp.json</t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="JOSE-JWK">
<front>
<title>JSON Web Key (JWK)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
</address>
</author>
<date month="May" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-key-11"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t></list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC2616">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code>
</postal>
<email>mogul@wrl.dec.com</email>
</address>
</author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code>
</postal>
<email>masinter@parc.xerox.com</email>
</address>
</author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
</postal>
<email>paulle@microsoft.com</email>
</address>
</author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>
<date year="1999" month="June"/>
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317" target="http://www.rfc-editor.org/rfc/rfc2616.txt"/>
<format type="PS" octets="5529857" target="http://www.rfc-editor.org/rfc/rfc2616.ps"/>
<format type="PDF" octets="550558" target="http://www.rfc-editor.org/rfc/rfc2616.pdf"/>
<format type="HTML" octets="636125" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>
<reference anchor="RFC2818">
<front>
<title>HTTP Over TLS</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2000" month="May"/>
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2818"/>
<format type="TXT" octets="15170" target="http://www.rfc-editor.org/rfc/rfc2818.txt"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" octets="352580" target="ftp://ftp.isi.edu/in-notes/rfc5280.txt"/>
</reference>
<reference anchor="RFC5785">
<front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials="M." surname="Nottingham" fullname="M. Nottingham">
<organization/>
</author>
<author initials="E." surname="Hammer-Lahav" fullname="E. Hammer-Lahav">
<organization/>
</author>
<date year="2010" month="April"/>
<abstract>
<t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5785"/>
<format type="TXT" octets="13779" target="http://www.rfc-editor.org/rfc/rfc5785.txt"/>
</reference>
<reference anchor="RFC6125">
<front>
<title>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)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization>PayPal</organization>
<address>
<email>jeff.hodges@paypal.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6125"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6125.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="HTTP-STATUS-308">
<front>
<title>The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)</title>
<author initials="J." surname="Reschke" fullname="Julian F. Reschke">
<organization>greenbytes GmbH</organization>
<address>
<email>julian.reschke@greenbytes.de</email>
</address>
</author>
<date month="March" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-reschke-http-status-308-07"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-reschke-http-status-308-07.txt"/>
</reference>
<reference anchor="KEYPIN">
<front>
<title>Public Key Pinning Extension for HTTP</title>
<author initials="C." surname="Evans" fullname="Chris Evans">
<organization>Google, Inc.</organization>
<address>
<email>cevans@google.com</email>
</address>
</author>
<author initials="C." surname="Palmer" fullname="Chris Palmer">
<organization>Google, Inc.</organization>
<address>
<email>palmer@google.com</email>
</address>
</author>
<author initials="R." surname="Sleevi" fullname="Ryan Palmer">
<organization>Google, Inc.</organization>
<address>
<email>sleevi@google.com</email>
</address>
</author>
<date month="December" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-websec-key-pinning-04"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04.txt"/>
</reference>
<reference anchor='RFC2782'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date year='2000' month='February' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='http://www.rfc-editor.org/rfc/rfc2782.txt' />
</reference>
<reference anchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials="R." surname="Arends" fullname="Roy Arends">
<organization>Telematica Instituut</organization>
<address>
<email>roy.arends@telin.nl</email>
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Internet Systems Consortium</organization>
<address>
<email>sra@isc.org</email>
</address>
</author>
<author initials="M." surname="Larson" fullname="Matt Larson">
<organization>VeriSign, Inc.</organization>
<address>
<email>mlarson@verisign.com</email>
</address>
</author>
<author initials="D." surname="Massey" fullname="Dan Massey">
<organization>Colorado State University</organization>
<address>
<email>massey@cs.colostate.edu</email>
</address>
</author>
<author initials="S." surname="Rose" fullname="Scott Rose">
<organization>National Institute for Standards and Technology</organization>
<address>
<email>scott.rose@nist.gov</email>
</address>
</author>
<date month="May" year="2005"/>
</front>
<seriesInfo name="RFC" value="4033"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc4033.txt"/>
</reference>
<reference anchor='RFC5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6120"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6120.txt"/>
</reference>
<reference anchor='RFC6555'>
<front>
<title>Happy Eyeballs: Success with Dual-Stack Hosts</title>
<author initials='D.' surname='Wing' fullname='D. Wing'><organization /></author>
<author initials='A.' surname='Yourtchenko' fullname='A. Yourtchenko'><organization /></author>
<date year='2012' month='April' />
<abstract>
<t>When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6555' />
<format type='TXT' octets='34048' target='http://www.rfc-editor.org/rfc/rfc6555.txt' />
</reference>
<reference anchor='RFC6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization />
</author>
<author initials='J.' surname='Schlyter' fullname='J. Schlyter'>
<organization />
</author>
<date year='2012' month='August' />
<abstract>
<t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6698' />
<format type='TXT' octets='84034' target='http://www.rfc-editor.org/rfc/rfc6698.txt' />
</reference>
<reference anchor='RFC6797'>
<front>
<title>HTTPS Strict Transport Security (HSTS)</title>
<author initials='J.' surname='Hodges' fullname='Jeff Hodges'>
<organization />
</author>
<author initials='C.' surname='Jackson' fullname='Collin Jackson'>
<organization />
</author>
<author initials='A.' surname='Barth' fullname='Adam Jackson'>
<organization />
</author>
<date year='2012' month='November' />
<abstract>
<t>This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6797' />
<format type='TXT' target='http://www.rfc-editor.org/rfc/rfc6797.txt' />
</reference>
<reference anchor="XMPP-DNA">
<front>
<title>Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<date month="April" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-xmpp-dna-02"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-ietf-xmpp-dna-02.txt"/>
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Dave Cridland, Max Pritikin, and Joe Salowey for their feedback.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:42 |