idnits 2.17.1 draft-miller-xmpp-posh-prooftype-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2013) is 4080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-key-08 == Outdated reference: A later version (-02) exists of draft-saintandre-xmpp-dna-01 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP M. Miller 3 Internet-Draft P. Saint-Andre 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 26, 2013 February 22, 2013 7 Using PKIX over Secure HTTP (POSH) as a Prooftype for XMPP Domain Name 8 Associations 9 draft-miller-xmpp-posh-prooftype-03 11 Abstract 13 This document defines a prooftype involving PKIX over Secure HTTP 14 (POSH) for associating a domain name with an XML stream in the 15 Extensible Messaging and Presence Protocol (XMPP). It also defines a 16 method involving HTTPS redirects (appropriate for use with the POSH 17 prooftype) for securely delegating a source domain to a derived 18 domain in XMPP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 26, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Prooftype . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Permanent versus Temporary Redirects . . . . . . . . . . 6 59 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9.1. The "posh._xmpp-client._tcp.json" Well-Known URI . . . . 9 65 9.2. The "posh._xmpp-server._tcp.json" Well-Known URI . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . 10 69 10.3. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The [XMPP-DNA] specification defines a framework for secure 75 delegation and strong domain name associations (DNA) in the 76 Extensible Messaging and Presence Protocol (XMPP). This document 77 defines a DNA prooftype using PKIX certificates obtained over secure 78 HTTP ("POSH"), as well as a secure delegation method, based on HTTPS 79 redirects, that is appropriate for use with the POSH prooftype. 81 The rationale for POSH is driven by current operational realities. 82 It is effectively impossible for a hosting service to provide and 83 maintain PKIX certificates [RFC5280] that include the appropriate 84 identifiers [RFC6125] for each hosted domain. It is true that DNS- 85 based technologies are emerging for secure delegation, in the form of 86 DNS Security ([RFC4033] and [RFC6698]); however, these technologies 87 are not yet widely deployed and might not be deployed in the near 88 future for domains outside the most common top-level domains (e.g., 89 ".COM", ".NET", ".EDU"). Because the XMPP community wishes to deploy 90 secure delegation and strong domain name associations as widely and 91 as quickly as possible, this document specifies how to use secure 92 HTTP ([RFC2616] and [RFC2818]) and PKIX certificates [RFC5280] to 93 verify that a domain is delegated to a hosting provider and also 94 establish a strong assocation between a domain name and an XML 95 stream. 97 2. Terminology 99 This document inherits XMPP terminology from [RFC6120] and security 100 terminology from [RFC5280]. The terms "source domain", "derived 101 domain", "reference identifier", and "presented identifier" are used 102 as defined in the "CertID" specification [RFC6125]. 104 This document is applicable to connections made from an XMPP client 105 to an XMPP server ("_xmpp-client._tcp") or between XMPP servers 106 ("_xmpp-server._tcp"). In both cases, the XMPP initiating entity 107 acts as a TLS client and the XMPP receiving entity acts as a TLS 108 server. Therefore, to simplify discussion this document uses "_xmpp- 109 client._tcp" to describe both cases, unless otherwise indicated. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119]. 116 3. Prooftype 118 POSH stands for PKIX Over Secure HTTP: the server's proof consist of 119 a PKIX certificate [RFC5280], the certificate is checked according to 120 the rules from [RFC6120] and [RFC6125], the client obtains its 121 verification material by retrieving the certificate over HTTPS 122 ([RFC2616] and [RFC2818]) from a well-known URI [RFC5785], and secure 123 DNS is not necessary since the HTTPS retrieval mechanism relies on 124 the chain of trust based on the public key infrastructure. 126 The process for retrieving a PKIX certificate over secure HTTP is as 127 follows. 129 1. The initiating entity performs an HTTPS GET at the source domain 130 to the path "/.well-known/posh._._tcp.json"; where 131 "_" MUST be either "_xmpp-client" for XMPP client-to- 132 server connections or "_xmpp-server" for XMPP server-to-server 133 connections. Here is an example: 135 HTTP GET /.well-known/posh._xmpp-server._tcp.json HTTP/1.1 136 Host: im.example.com 138 2. If the source domain HTTPS server has a certificate for the 139 requested path, it MUST respond with a success status code, with 140 the message body as a JSON Web Key Set (JWK Set) [JOSE-JWK], 141 which itself contains at least one JWK of type "PKIX" 142 [JOSE-PKIX-KEY] that the XMPP server at the source domain will 143 present during the TLS negotiation phase of XMPP stream setup 144 (linebreaks and whitespace added for readability). Here is an 145 example: 147 HTTP/1.1 200 OK 148 Content-Type: application/json 149 Content-Length: 806 151 { 152 "keys":[ 153 { 154 "kty":"PKIX", 155 "x5c":[ 156 "MIICPTCCAaYCCQDDVeBaBmWC_jANBgkqhkiG9w0BAQUFADBjMQswCQY 157 DVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn 158 ZlcjEXMBUGA1UEChMOaW0uZXhhbXBsZS5jb20xFzAVBgNVBAMTDmltL 159 mV4YW1wbGUuY29tMB4XDTEyMDYxMTIxNTQ0NFoXDTIyMDYwOTIxNTQ0 160 NFowYzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQY 161 DVQQHEwZEZW52ZXIxFzAVBgNVBAoTDmltLmV4YW1wbGUuY29tMRcwFQ 162 YDVQQDEw5pbS5leGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBj 163 QAwgYkCgYEA4hoKhi_B07eQH-1NB9gWiNFDT__AbTHQOEC0AOr4Gh_o 164 9PUp7kD0gklU4uv7rSAhAyCe4WaOiQ_HShzEryGfHiZmWht0BaYmj19 165 iuPWRecZOXWqKZji9NtAxn9l3kdon_YLJcrPGyNTGK66-ggNaqy8LkQ 166 QpI4rff60yHHZ_0XkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQDcwiu30 167 bSMlykWYz-tTDSlQ3wLSVB9RsR8jXmJvMo7y7icXwg54a9M3xipjZtr 168 fAhYM5I5iqUTQPki6s26n9SQpRm5bonEFDA3WGwrwma35biP9-NSBWz 169 SaDF8AztwFNKXXl6_U6hWwG05G_NdeS11gpww9NUDraJgVoDpRK04tg" 170 ] 171 } 172 ] 173 } 175 4. Secure Delegation 177 When PKIX Over Secure HTTP (POSH) is the DNA prooftype, it is 178 possible to use HTTPS redirects in determining if a domain is 179 securely delegated, as follows: 181 1. The initiating entity performs an HTTPS GET at the source domain 182 to the path "/.well-known/posh._._tcp.json"; where 183 "_" MUST be either "_xmpp-client" for XMPP client-to- 184 server connections or "_xmpp-server" for XMPP server-to-server 185 connections. Here is an example: 187 GET /.well-known/posh._xmpp-server._tcp.json HTTP/1.1 188 Host: im.example.com 190 2. If the source domain HTTPS server has delegated to a derived 191 domain, it MUST respond with one of the redirect mechanisms 192 provided by HTTP (e.g., using the 302, 303, 307, or 308 193 response). The 'Location' header MUST specify an HTTPS URL, 194 where the hostname and port is the derived domain HTTPS server, 195 and the path MUST match the pattern "_._tcp.json"; where 196 "_" MUST be identical to the "_" portion of the 197 original request (line breaks added for readability). Here is an 198 example: 200 HTTP/1.1 302 Found 201 Location: https://hosting.example.net/.well-known 202 /posh._xmpp-server._tcp.json 204 3. The initiating entity performs an HTTPS GET to the URL specified 205 in the 'Location' header. Here is an example: 207 GET /.well-known/posh._xmpp-server._tcp.json HTTP/1.1 208 Host: hosting.example.net 210 4. If the derived domain HTTPS server has a certificate, it MUST 211 respond with a success status code, with the message body as a 212 JSON Web Key Set (JWK Set) [JOSE-JWK], which itself contains at 213 least one JWK of type "PKIX" [JOSE-PKIX-KEY] that the XMPP server 214 at the derived domain will present during the TLS negotiation 215 phase of XMPP stream setup. Here is an example: 217 HTTP/1.1 200 OK 218 Content-Type: application/json 219 Content-Length: 806 221 { 222 "keys":[ 223 { 224 "kty":"PKIX", 225 "x5c":[ 226 "MIICPTCCAaYCCQDDVeBaBmWC_jANBgkqhkiG9w0BAQUFADBjMQswCQY 227 DVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn 228 ZlcjEXMBUGA1UEChMOaW0uZXhhbXBsZS5jb20xFzAVBgNVBAMTDmltL 229 mV4YW1wbGUuY29tMB4XDTEyMDYxMTIxNTQ0NFoXDTIyMDYwOTIxNTQ0 230 NFowYzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQY 231 DVQQHEwZEZW52ZXIxFzAVBgNVBAoTDmltLmV4YW1wbGUuY29tMRcwFQ 232 YDVQQDEw5pbS5leGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBj 233 QAwgYkCgYEA4hoKhi_B07eQH-1NB9gWiNFDT__AbTHQOEC0AOr4Gh_o 234 9PUp7kD0gklU4uv7rSAhAyCe4WaOiQ_HShzEryGfHiZmWht0BaYmj19 235 iuPWRecZOXWqKZji9NtAxn9l3kdon_YLJcrPGyNTGK66-ggNaqy8LkQ 236 QpI4rff60yHHZ_0XkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQDcwiu30 237 bSMlykWYz-tTDSlQ3wLSVB9RsR8jXmJvMo7y7icXwg54a9M3xipjZtr 238 fAhYM5I5iqUTQPki6s26n9SQpRm5bonEFDA3WGwrwma35biP9-NSBWz 239 SaDF8AztwFNKXXl6_U6hWwG05G_NdeS11gpww9NUDraJgVoDpRK04tg" 240 ] 241 } 242 ] 243 } 245 4.1. Permanent versus Temporary Redirects 247 Care needs to be taken with which redirect mechanism is used for 248 delegation. Clients might remember the redirected location in place 249 of the original, which can lead to verification mismatches when a 250 source domain is migrated to a different delegated domain. 252 To mitigate this concern, source domains SHOULD use only temporary 253 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 254 (Temporary Redirect). Clients MAY treat any redirect as temporary, 255 ignoring the specific semantics for 301 (Moved Permanently) or 308 256 (Permanent Redirect) [HTTP-STATUS-308]. 258 5. Order of Operations 260 The processes for the POSH prooftype MUST be complete before the TLS 261 handshake over the XMPP connection finishes, so that the client can 262 perform verification of reference identities. Ideally a TLS client 263 ought to perform the POSH processes in parallel with other XMPP 264 session establishment processes; this is sometimes called the "happy 265 eyeballs" approach, similar to [RFC6555] for IPv4 and IPv6. However, 266 a TLS client might delay as much of the XMPP session establishment as 267 it needs to in order to gather all of the POSH-based verification 268 material. For instance, a TLS client might not open the socket 269 connection until it retrieves the PKIX certificates. 271 6. Caching Results 273 Ideally, the initiating entity relies on the expiration time of the 274 certificate obtained via POSH, and not on HTTP caching mechanisms. 276 To that end, the HTTPS servers for source and derived domains SHOULD 277 specify a 'Cache-Control' header indicating a short duration (e.g., 278 max-age=60) or "no-cache" to indicate the response (redirect or 279 content) is not appropriate to cache at the HTTP level. 281 7. Alternates and Roll-over 283 To indicate alternate PKIX certificates, such as when an existing 284 certificate will soon expire, the returned JWK Set can contain 285 multiple "PKIX" JWK objects. The JWK Set SHOULD be ordered with the 286 most relevant certificate first as determined by the XMPP server 287 operator (e.g., the certificate soonest to expire), followed by the 288 next most relevant certificate (e.g., the renewed certificate). Here 289 is an example: 291 { 292 "keys":[ 293 { 294 "kty":"PKIX", 295 "x5c":[ 296 "MIICYTCCAcqgAwIBAgIJAK_Lh7cXMZvdMA0GCSqGSIb3DQEBBQUAME 297 8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEB 298 xMGRGVudmVyMRwwGgYDVQQDExNob3N0aW5nLmV4YW1wbGUubmV0MB4X 299 DTEzMDIwNzE4MjY0MFoXDTIzMDIwNTE4MjY0MFowTzELMAkGA1UEBhM 300 CVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxHD 301 AaBgNVBAMTE2hvc3RpbmcuZXhhbXBsZS5uZXQwgZ8wDQYJKoZIhvcNA 302 QEBBQADgY0AMIGJAoGBAOLjqQxacJ-DQNOuVxNzoBBRyLku7V_ZEpFY 303 8SHPyrK38I7Q3lWnEpAyUanpMClDMV0B_EJQDeueJgWkyrgd6bDZLvi 304 _UtGha9E4q-IpHO6cM_cSE9d_oZuCcdGV8HHjK9m1xHUEyeTGAm1tMA 305 m7j_BNFdhETkUqTfFPggFdMhAXAgMBAAGjRTBDMEEGA1UdEQQ6MDigI 306 QYIKwYBBQUHCAWgFQwTaG9zdGluZy5leGFtcGxlLm5ldIITaG9zdGlu 307 Zy5leGFtcGxlLm5ldDANBgkqhkiG9w0BAQUFAAOBgQAaz81gC5KqFQo 308 WGf8mJz_mYx2pW6i-QeYw-BqpdAgdkrRvOHlJ4pYRhkajKfdiauvHcM 309 ZDPWuuSm7jzIEOPqZdzYXkffgfr4br5UOAmYqpikpjlSsTLd5h_38p- 310 3lz-l502wcs1xveBTYTIT13MAI844IBCZF-xDl-wpJG3kkttA" 311 ] 312 } 313 { 314 "kty":"PKIX", 315 "x5c":[ 316 "MIIC-zCCAeOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBGMQswCQYDVQ 317 QGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlc 318 jETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMzAyMTIyMTI5MDBaFw0x 319 NDAyMTIyMTI5MDBaME8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2x 320 vcmFkbzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQDExNob3N0aW5nLm 321 V4YW1wbGUubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi4 322 6kMWnCfg0DTrlcTc6AQUci5Lu1f2RKRWPEhz8qyt_CO0N5VpxKQMlGp 323 6TApQzFdAfxCUA3rniYFpMq4Hemw2S74v1LRoWvROKviKRzunDP3EhP 324 Xf6GbgnHRlfBx4yvZtcR1BMnkxgJtbTAJu4_wTRXYRE5FKk3xT4IBXT 325 IQFwIDAQABo28wbTAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRgaaG6v 326 5py2KwjtX-ToLKTEIqeVTALBgNVHQ8EBAMCBeAwEQYJYIZIAYb4QgEB 327 BAQDAgZAMB4GCWCGSAGG-EIBDQQRFg94Y2EgY2VydGlmaWNhdGUwDQY 328 JKoZIhvcNAQEFBQADggEBAE6Vhvd0OuMHJjyi8F8NoFSCRYOJXOry5B 329 lmU6eVwEcUQSAkHaC4Q2isWCIES58Wm5P2VVQTYBUn58H7ZR9-7looj 330 YVykwEIQmE_aaVsMM-8AwTMJ7qj7aGhXFlKT2xwiPMVq9JF_Gv43qSy 331 V9GJ3Uw5Jz6AN4WawXmlIVD0eKhPoHSDO0wfnFc8KM8mHPu7JXqIriX 332 18w4jfj3ySuHIkXeOjdbDWqZWJ7akBVf8McbB05tXP5T7sDTV-t8qH5 333 6fdnSQC-qO-sQgmWlKLFtKybT6Fa6J7ChEd_sOJNqB9SoMar5sRYyfS 334 foV0D7m_IF1MI6X95rL1YnKIGxDYWBq4ck", 335 "MIIDeTCCAmGgAwIBAgIBATANBgkqhkiG9w0BAQUFADBGMQswCQYDVQ 336 QGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlc 337 jETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMzAyMTIyMTI4MDBaFw0y 338 MzAyMTIyMTI4MDBaMEYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2x 339 vcmFkbzEPMA0GA1UEBxMGRGVudmVyMRMwEQYDVQQDEwpFeGFtcGxlIE 340 NBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNQ30X7uX 341 Tg-4jKadtRO5uQEMRMnkZvDnptbWAtx0d1PsufQ2kfvog0gDhigjPEZ 342 DV9S-zm63Ia-eqJ3ROT9jDXjtF6s_IawITf5cPSNxn8qP8w-vbiy0rB 343 4W4Nk1Dwji7KJ_wKNo0mwOx_qWNjSk3yoaU4sUEuIypizgLxKAr25vV 344 vAJAxF6HAfdQoVAIdCZ_7qbBPI7aurdU_NdmbbKBK0lp8aV1MYLzz8D 345 I0hWcBQa2-gOSUcd_yT1az7UpMjGllbnVlUDxyJeCzbBaHny5NlWWHs 346 GnsbucbM-9yeAMbRes_z0KeHxcRtomd8bh7As12RIXKrk5GRoNVKAoi 347 wLQIDAQABo3IwcDAPBgNVHRMBAf8EBTADAQH_MB0GA1UdDgQWBBSyie 348 t77RfWpH3X8NMwGFVu2ldJPTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4Q 349 gEBBAQDAgAHMB4GCWCGSAGG-EIBDQQRFg94Y2EgY2VydGlmaWNhdGUw 350 DQYJKoZIhvcNAQEFBQADggEBAIE-gvYX-2MOAmL3qOraIYUb1eDeUyC 351 rxroqrI1xX3jDapMPltCxuZr8VkLljHaNpe7sLJlFWSaQHkZe4snxWL 352 SdINLrgFhxskclAlSLutPVTA4xPwo60t0hBJE0NJ8kC8gVvvlWXWAiI 353 IVszG3vLBcfxZeuOS4JsVwGbTt5uKsVIJ2VkRiBG4ey5lsS5O8u0vRf 354 ei7HFr1NzZ8y5BHoix9VLN2--n11SNicwDOo2V618B8GQnPqM2dsaDa 355 A1wIrMZeEyoRtIN25jcW-as4sS9dPJ1ueNIzrSuzlXtKYGjflaTcEfD 356 -_kImTw9tHzS57iBXHqgQTQo61pYzAZMlk9wA" 357 ] 358 } 359 ] 360 } 362 8. Security Considerations 364 This document supplements but does not supersede the security 365 considerations provided in [RFC2616], [RFC2818], [RFC6120], and 366 [RFC6125]. 368 Specifically, communication via HTTPS depends on checking the 369 identity of the HTTP server in accordance with [RFC2818]. 371 9. IANA Considerations 373 9.1. The "posh._xmpp-client._tcp.json" Well-Known URI 375 This specification registers the "posh._xmpp-client._tcp.json" well- 376 known URI in the Well-Known URI Registry as defined by [RFC5785]. 378 URI suffix: posh._xmpp-client._tcp.json 380 Change controller: IETF 382 Specification document(s): [[ this document ]] 384 9.2. The "posh._xmpp-server._tcp.json" Well-Known URI 386 This specification registers the "posh._xmpp-server._tcp.json" well- 387 known URI in the Well-Known URI Registry as defined by [RFC5785]. 389 URI suffix: posh._xmpp-server._tcp.json 391 Change controller: IETF 393 Specification document(s): [[ this document ]] 395 10. References 397 10.1. Normative References 399 [JOSE-JWK] 400 Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 401 key-08 (work in progress), December 2012. 403 [JOSE-PKIX-KEY] 404 Miller, M., "JSON Web Key (JWK) for PKIX Certificates", 405 draft-miller-jose-pkix-key-01 (work in progress), February 406 2013. 408 [XMPP-DNA] 409 Saint-Andre, P. and M. Miller, "Domain Name Associations 410 (DNA) in the Extensible Messaging and Presence Protocol 411 (XMPP)", draft-saintandre-xmpp-dna-01 (work in progress), 412 February 2013. 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 418 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 419 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 421 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 423 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 424 Housley, R., and W. Polk, "Internet X.509 Public Key 425 Infrastructure Certificate and Certificate Revocation List 426 (CRL) Profile", RFC 5280, May 2008. 428 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 429 Uniform Resource Identifiers (URIs)", RFC 5785, April 430 2010. 432 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 433 Protocol (XMPP): Core", RFC 6120, March 2011. 435 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 436 Verification of Domain-Based Application Service Identity 437 within Internet Public Key Infrastructure Using X.509 438 (PKIX) Certificates in the Context of Transport Layer 439 Security (TLS)", RFC 6125, March 2011. 441 10.2. Informative References 443 [HTTP-STATUS-308] 444 Reschke, J., "The Hypertext Transfer Protocol (HTTP) 445 Status Code 308 (Permanent Redirect)", draft-reschke-http- 446 status-308-07 (work in progress), March 2012. 448 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 449 Rose, "DNS Security Introduction and Requirements", RFC 450 4033, May 2005. 452 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 453 of Named Entities (DANE) Transport Layer Security (TLS) 454 Protocol: TLSA", RFC 6698, August 2012. 456 10.3. Informative References 458 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 459 Dual-Stack Hosts", RFC 6555, April 2012. 461 Authors' Addresses 462 Matthew Miller 463 Cisco Systems, Inc. 464 1899 Wynkoop Street, Suite 600 465 Denver, CO 80202 466 USA 468 Email: mamille2@cisco.com 470 Peter Saint-Andre 471 Cisco Systems, Inc. 472 1899 Wynkoop Street, Suite 600 473 Denver, CO 80202 474 USA 476 Email: psaintan@cisco.com