XMPP                                                           M. Miller
Internet-Draft                                            P. Saint-Andre
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: August 26, 2013                               February 22, 2013


 Using PKIX over Secure HTTP (POSH) as a Prooftype for XMPP Domain Name
                              Associations
                  draft-miller-xmpp-posh-prooftype-03

Abstract

   This document defines a prooftype involving PKIX over Secure HTTP
   (POSH) for associating a domain name with an XML stream in the
   Extensible Messaging and Presence Protocol (XMPP).  It also defines a
   method involving HTTPS redirects (appropriate for use with the POSH
   prooftype) for securely delegating a source domain to a derived
   domain in XMPP.

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 August 26, 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



Miller & Saint-Andre    Expires August 26, 2013                 [Page 1]


Internet-Draft            XMPP POSH Prooftype              February 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Prooftype . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Secure Delegation . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Permanent versus Temporary Redirects  . . . . . . . . . .   6
   5.  Order of Operations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Caching Results . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Alternates and Roll-over  . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  The "posh._xmpp-client._tcp.json" Well-Known URI  . . . .   9
     9.2.  The "posh._xmpp-server._tcp.json" Well-Known URI  . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
     10.3.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The [XMPP-DNA] specification defines a framework for secure
   delegation and strong domain name associations (DNA) in the
   Extensible Messaging and Presence Protocol (XMPP).  This document
   defines a DNA prooftype using PKIX certificates obtained over secure
   HTTP ("POSH"), as well as a secure delegation method, based on HTTPS
   redirects, that is appropriate for use with the POSH prooftype.

   The rationale for POSH is driven by current operational realities.
   It is effectively impossible for a hosting service to provide and
   maintain PKIX certificates [RFC5280] that include the appropriate
   identifiers [RFC6125] for each hosted domain.  It is true that DNS-
   based technologies are emerging for secure delegation, in the form of
   DNS Security ([RFC4033] and [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 (e.g.,
   ".COM", ".NET", ".EDU").  Because the XMPP community wishes to deploy
   secure delegation and strong domain name associations as widely and
   as quickly as possible, this document specifies how to use secure
   HTTP ([RFC2616] and [RFC2818]) and PKIX certificates [RFC5280] to
   verify that a domain is delegated to a hosting provider and also
   establish a strong assocation between a domain name and an XML
   stream.




Miller & Saint-Andre    Expires August 26, 2013                 [Page 2]


Internet-Draft            XMPP POSH Prooftype              February 2013


2.  Terminology

   This document inherits XMPP terminology from [RFC6120] and security
   terminology from [RFC5280].  The terms "source domain", "derived
   domain", "reference identifier", and "presented identifier" are used
   as defined in the "CertID" specification [RFC6125].

   This document is applicable to connections made from an XMPP client
   to an XMPP server ("_xmpp-client._tcp") or between XMPP servers
   ("_xmpp-server._tcp").  In both cases, 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.

   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].

3.  Prooftype

   POSH stands for PKIX Over Secure HTTP: the server's proof consist of
   a PKIX certificate [RFC5280], the certificate is checked according to
   the rules from [RFC6120] and [RFC6125], the client obtains its
   verification material by retrieving the certificate over HTTPS
   ([RFC2616] and [RFC2818]) from a well-known URI [RFC5785], and secure
   DNS is not necessary since the HTTPS retrieval mechanism relies on
   the chain of trust based on the public key infrastructure.

   The process for retrieving a PKIX certificate over secure HTTP is as
   follows.

   1.  The initiating entity performs an HTTPS GET at the source domain
       to the path "/.well-known/posh._<service>._tcp.json"; where
       "_<service>" MUST be either "_xmpp-client" for XMPP client-to-
       server connections or "_xmpp-server" for XMPP server-to-server
       connections.  Here is an example:

   HTTP GET /.well-known/posh._xmpp-server._tcp.json HTTP/1.1
   Host: im.example.com



   2.  If the source domain HTTPS server has a certificate for the
       requested path, it MUST respond with a success status code, with
       the message body as a JSON Web Key Set (JWK Set) [JOSE-JWK],
       which itself contains at least one JWK of type "PKIX"
       [JOSE-PKIX-KEY] that the XMPP server at the source domain will



Miller & Saint-Andre    Expires August 26, 2013                 [Page 3]


Internet-Draft            XMPP POSH Prooftype              February 2013


       present during the TLS negotiation phase of XMPP stream setup
       (linebreaks and whitespace added for readability).  Here is an
       example:

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 806

   {
     "keys":[
       {
         "kty":"PKIX",
         "x5c":[
           "MIICPTCCAaYCCQDDVeBaBmWC_jANBgkqhkiG9w0BAQUFADBjMQswCQY
            DVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
            ZlcjEXMBUGA1UEChMOaW0uZXhhbXBsZS5jb20xFzAVBgNVBAMTDmltL
            mV4YW1wbGUuY29tMB4XDTEyMDYxMTIxNTQ0NFoXDTIyMDYwOTIxNTQ0
            NFowYzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQY
            DVQQHEwZEZW52ZXIxFzAVBgNVBAoTDmltLmV4YW1wbGUuY29tMRcwFQ
            YDVQQDEw5pbS5leGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBj
            QAwgYkCgYEA4hoKhi_B07eQH-1NB9gWiNFDT__AbTHQOEC0AOr4Gh_o
            9PUp7kD0gklU4uv7rSAhAyCe4WaOiQ_HShzEryGfHiZmWht0BaYmj19
            iuPWRecZOXWqKZji9NtAxn9l3kdon_YLJcrPGyNTGK66-ggNaqy8LkQ
            QpI4rff60yHHZ_0XkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQDcwiu30
            bSMlykWYz-tTDSlQ3wLSVB9RsR8jXmJvMo7y7icXwg54a9M3xipjZtr
            fAhYM5I5iqUTQPki6s26n9SQpRm5bonEFDA3WGwrwma35biP9-NSBWz
            SaDF8AztwFNKXXl6_U6hWwG05G_NdeS11gpww9NUDraJgVoDpRK04tg"
         ]
       }
     ]
   }



4.  Secure Delegation

   When PKIX Over Secure HTTP (POSH) is the DNA prooftype, it is
   possible to use HTTPS redirects in determining if a domain is
   securely delegated, as follows:

   1.  The initiating entity performs an HTTPS GET at the source domain
       to the path "/.well-known/posh._<service>._tcp.json"; where
       "_<service>" MUST be either "_xmpp-client" for XMPP client-to-
       server connections or "_xmpp-server" for XMPP server-to-server
       connections.  Here is an example:






Miller & Saint-Andre    Expires August 26, 2013                 [Page 4]


Internet-Draft            XMPP POSH Prooftype              February 2013


   GET /.well-known/posh._xmpp-server._tcp.json HTTP/1.1
   Host: im.example.com



   2.  If the source domain HTTPS server has delegated to a derived
       domain, it MUST respond with one of the redirect mechanisms
       provided by HTTP (e.g., using the 302, 303, 307, or 308
       response).  The 'Location' header MUST specify an HTTPS URL,
       where the hostname and port is the derived domain HTTPS server,
       and the path MUST match the pattern "_<service>._tcp.json"; where
       "_<service>" MUST be identical to the "_<service>" portion of the
       original request (line breaks added for readability).  Here is an
       example:

   HTTP/1.1 302 Found
   Location: https://hosting.example.net/.well-known
             /posh._xmpp-server._tcp.json



   3.  The initiating entity performs an HTTPS GET to the URL specified
       in the 'Location' header.  Here is an example:

   GET /.well-known/posh._xmpp-server._tcp.json HTTP/1.1
   Host: hosting.example.net



   4.  If the derived domain HTTPS server has a certificate, it MUST
       respond with a success status code, with the message body as a
       JSON Web Key Set (JWK Set) [JOSE-JWK], which itself contains at
       least one JWK of type "PKIX" [JOSE-PKIX-KEY] that the XMPP server
       at the derived domain will present during the TLS negotiation
       phase of XMPP stream setup.  Here is an example:

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 806

   {
     "keys":[
       {
         "kty":"PKIX",
         "x5c":[
           "MIICPTCCAaYCCQDDVeBaBmWC_jANBgkqhkiG9w0BAQUFADBjMQswCQY
            DVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbn
            ZlcjEXMBUGA1UEChMOaW0uZXhhbXBsZS5jb20xFzAVBgNVBAMTDmltL



Miller & Saint-Andre    Expires August 26, 2013                 [Page 5]


Internet-Draft            XMPP POSH Prooftype              February 2013


            mV4YW1wbGUuY29tMB4XDTEyMDYxMTIxNTQ0NFoXDTIyMDYwOTIxNTQ0
            NFowYzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQY
            DVQQHEwZEZW52ZXIxFzAVBgNVBAoTDmltLmV4YW1wbGUuY29tMRcwFQ
            YDVQQDEw5pbS5leGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBj
            QAwgYkCgYEA4hoKhi_B07eQH-1NB9gWiNFDT__AbTHQOEC0AOr4Gh_o
            9PUp7kD0gklU4uv7rSAhAyCe4WaOiQ_HShzEryGfHiZmWht0BaYmj19
            iuPWRecZOXWqKZji9NtAxn9l3kdon_YLJcrPGyNTGK66-ggNaqy8LkQ
            QpI4rff60yHHZ_0XkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQDcwiu30
            bSMlykWYz-tTDSlQ3wLSVB9RsR8jXmJvMo7y7icXwg54a9M3xipjZtr
            fAhYM5I5iqUTQPki6s26n9SQpRm5bonEFDA3WGwrwma35biP9-NSBWz
            SaDF8AztwFNKXXl6_U6hWwG05G_NdeS11gpww9NUDraJgVoDpRK04tg"
         ]
       }
     ]
   }



4.1.  Permanent versus Temporary Redirects

   Care needs to be taken with which 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.

   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) or 308
   (Permanent Redirect) [HTTP-STATUS-308].

5.  Order of Operations

   The processes for the POSH prooftype MUST be complete before the TLS
   handshake over the XMPP connection finishes, so that the client can
   perform verification of reference identities.  Ideally a TLS client
   ought to perform the POSH processes in parallel with other XMPP
   session establishment processes; this is sometimes called the "happy
   eyeballs" approach, similar to [RFC6555] for IPv4 and IPv6.  However,
   a TLS client might delay as much of the XMPP session establishment as
   it needs to 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.

6.  Caching Results

   Ideally, the initiating entity relies on the expiration time of the
   certificate obtained via POSH, and not on HTTP caching mechanisms.



Miller & Saint-Andre    Expires August 26, 2013                 [Page 6]


Internet-Draft            XMPP POSH Prooftype              February 2013


   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 the response (redirect or
   content) is not appropriate to cache at the HTTP level.

7.  Alternates and Roll-over

   To indicate alternate PKIX certificates, such as when an existing
   certificate will soon expire, the returned JWK Set can contain
   multiple "PKIX" JWK objects.  The JWK Set SHOULD be ordered with the
   most relevant certificate first as determined by the XMPP server
   operator (e.g., the certificate soonest to expire), followed by the
   next most relevant certificate (e.g., the renewed certificate).  Here
   is an example:

   {
     "keys":[
       {
         "kty":"PKIX",
         "x5c":[
           "MIICYTCCAcqgAwIBAgIJAK_Lh7cXMZvdMA0GCSqGSIb3DQEBBQUAME
           8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEB
           xMGRGVudmVyMRwwGgYDVQQDExNob3N0aW5nLmV4YW1wbGUubmV0MB4X
           DTEzMDIwNzE4MjY0MFoXDTIzMDIwNTE4MjY0MFowTzELMAkGA1UEBhM
           CVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxHD
           AaBgNVBAMTE2hvc3RpbmcuZXhhbXBsZS5uZXQwgZ8wDQYJKoZIhvcNA
           QEBBQADgY0AMIGJAoGBAOLjqQxacJ-DQNOuVxNzoBBRyLku7V_ZEpFY
           8SHPyrK38I7Q3lWnEpAyUanpMClDMV0B_EJQDeueJgWkyrgd6bDZLvi
           _UtGha9E4q-IpHO6cM_cSE9d_oZuCcdGV8HHjK9m1xHUEyeTGAm1tMA
           m7j_BNFdhETkUqTfFPggFdMhAXAgMBAAGjRTBDMEEGA1UdEQQ6MDigI
           QYIKwYBBQUHCAWgFQwTaG9zdGluZy5leGFtcGxlLm5ldIITaG9zdGlu
           Zy5leGFtcGxlLm5ldDANBgkqhkiG9w0BAQUFAAOBgQAaz81gC5KqFQo
           WGf8mJz_mYx2pW6i-QeYw-BqpdAgdkrRvOHlJ4pYRhkajKfdiauvHcM
           ZDPWuuSm7jzIEOPqZdzYXkffgfr4br5UOAmYqpikpjlSsTLd5h_38p-
           3lz-l502wcs1xveBTYTIT13MAI844IBCZF-xDl-wpJG3kkttA"
         ]
       }
       {
         "kty":"PKIX",
         "x5c":[
           "MIIC-zCCAeOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBGMQswCQYDVQ
           QGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlc
           jETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMzAyMTIyMTI5MDBaFw0x
           NDAyMTIyMTI5MDBaME8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2x
           vcmFkbzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQDExNob3N0aW5nLm
           V4YW1wbGUubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi4
           6kMWnCfg0DTrlcTc6AQUci5Lu1f2RKRWPEhz8qyt_CO0N5VpxKQMlGp
           6TApQzFdAfxCUA3rniYFpMq4Hemw2S74v1LRoWvROKviKRzunDP3EhP



Miller & Saint-Andre    Expires August 26, 2013                 [Page 7]


Internet-Draft            XMPP POSH Prooftype              February 2013


           Xf6GbgnHRlfBx4yvZtcR1BMnkxgJtbTAJu4_wTRXYRE5FKk3xT4IBXT
           IQFwIDAQABo28wbTAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRgaaG6v
           5py2KwjtX-ToLKTEIqeVTALBgNVHQ8EBAMCBeAwEQYJYIZIAYb4QgEB
           BAQDAgZAMB4GCWCGSAGG-EIBDQQRFg94Y2EgY2VydGlmaWNhdGUwDQY
           JKoZIhvcNAQEFBQADggEBAE6Vhvd0OuMHJjyi8F8NoFSCRYOJXOry5B
           lmU6eVwEcUQSAkHaC4Q2isWCIES58Wm5P2VVQTYBUn58H7ZR9-7looj
           YVykwEIQmE_aaVsMM-8AwTMJ7qj7aGhXFlKT2xwiPMVq9JF_Gv43qSy
           V9GJ3Uw5Jz6AN4WawXmlIVD0eKhPoHSDO0wfnFc8KM8mHPu7JXqIriX
           18w4jfj3ySuHIkXeOjdbDWqZWJ7akBVf8McbB05tXP5T7sDTV-t8qH5
           6fdnSQC-qO-sQgmWlKLFtKybT6Fa6J7ChEd_sOJNqB9SoMar5sRYyfS
           foV0D7m_IF1MI6X95rL1YnKIGxDYWBq4ck",
           "MIIDeTCCAmGgAwIBAgIBATANBgkqhkiG9w0BAQUFADBGMQswCQYDVQ
           QGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlc
           jETMBEGA1UEAxMKRXhhbXBsZSBDQTAeFw0xMzAyMTIyMTI4MDBaFw0y
           MzAyMTIyMTI4MDBaMEYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2x
           vcmFkbzEPMA0GA1UEBxMGRGVudmVyMRMwEQYDVQQDEwpFeGFtcGxlIE
           NBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNQ30X7uX
           Tg-4jKadtRO5uQEMRMnkZvDnptbWAtx0d1PsufQ2kfvog0gDhigjPEZ
           DV9S-zm63Ia-eqJ3ROT9jDXjtF6s_IawITf5cPSNxn8qP8w-vbiy0rB
           4W4Nk1Dwji7KJ_wKNo0mwOx_qWNjSk3yoaU4sUEuIypizgLxKAr25vV
           vAJAxF6HAfdQoVAIdCZ_7qbBPI7aurdU_NdmbbKBK0lp8aV1MYLzz8D
           I0hWcBQa2-gOSUcd_yT1az7UpMjGllbnVlUDxyJeCzbBaHny5NlWWHs
           GnsbucbM-9yeAMbRes_z0KeHxcRtomd8bh7As12RIXKrk5GRoNVKAoi
           wLQIDAQABo3IwcDAPBgNVHRMBAf8EBTADAQH_MB0GA1UdDgQWBBSyie
           t77RfWpH3X8NMwGFVu2ldJPTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4Q
           gEBBAQDAgAHMB4GCWCGSAGG-EIBDQQRFg94Y2EgY2VydGlmaWNhdGUw
           DQYJKoZIhvcNAQEFBQADggEBAIE-gvYX-2MOAmL3qOraIYUb1eDeUyC
           rxroqrI1xX3jDapMPltCxuZr8VkLljHaNpe7sLJlFWSaQHkZe4snxWL
           SdINLrgFhxskclAlSLutPVTA4xPwo60t0hBJE0NJ8kC8gVvvlWXWAiI
           IVszG3vLBcfxZeuOS4JsVwGbTt5uKsVIJ2VkRiBG4ey5lsS5O8u0vRf
           ei7HFr1NzZ8y5BHoix9VLN2--n11SNicwDOo2V618B8GQnPqM2dsaDa
           A1wIrMZeEyoRtIN25jcW-as4sS9dPJ1ueNIzrSuzlXtKYGjflaTcEfD
           -_kImTw9tHzS57iBXHqgQTQo61pYzAZMlk9wA"
         ]
       }
     ]
   }


8.  Security Considerations

   This document supplements but does not supersede the security
   considerations provided in [RFC2616], [RFC2818], [RFC6120], and
   [RFC6125].

   Specifically, communication via HTTPS depends on checking the
   identity of the HTTP server in accordance with [RFC2818].




Miller & Saint-Andre    Expires August 26, 2013                 [Page 8]


Internet-Draft            XMPP POSH Prooftype              February 2013


9.  IANA Considerations

9.1.  The "posh._xmpp-client._tcp.json" Well-Known URI

   This specification registers the "posh._xmpp-client._tcp.json" well-
   known URI in the Well-Known URI Registry as defined by [RFC5785].

   URI suffix: posh._xmpp-client._tcp.json

   Change controller: IETF

   Specification document(s): [[ this document ]]

9.2.  The "posh._xmpp-server._tcp.json" Well-Known URI

   This specification registers the "posh._xmpp-server._tcp.json" well-
   known URI in the Well-Known URI Registry as defined by [RFC5785].

   URI suffix: posh._xmpp-server._tcp.json

   Change controller: IETF

   Specification document(s): [[ this document ]]

10.  References

10.1.  Normative References

   [JOSE-JWK]
              Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
              key-08 (work in progress), December 2012.

   [JOSE-PKIX-KEY]
              Miller, M., "JSON Web Key (JWK) for PKIX Certificates",
              draft-miller-jose-pkix-key-01 (work in progress), February
              2013.

   [XMPP-DNA]
              Saint-Andre, P. and M. Miller, "Domain Name Associations
              (DNA) in the Extensible Messaging and Presence Protocol
              (XMPP)", draft-saintandre-xmpp-dna-01 (work in progress),
              February 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.






Miller & Saint-Andre    Expires August 26, 2013                 [Page 9]


Internet-Draft            XMPP POSH Prooftype              February 2013


   [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.

   [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.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [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.

10.2.  Informative References

   [HTTP-STATUS-308]
              Reschke, J., "The Hypertext Transfer Protocol (HTTP)
              Status Code 308 (Permanent Redirect)", draft-reschke-http-
              status-308-07 (work in progress), March 2012.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, May 2005.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

10.3.  Informative References

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.

Authors' Addresses






Miller & Saint-Andre    Expires August 26, 2013                [Page 10]


Internet-Draft            XMPP POSH Prooftype              February 2013


   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 August 26, 2013                [Page 11]