GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7711

Internet Engineering Task Force (IETF) M. Miller Request for Comments: 7711 Cisco Systems, Inc. Category: Standards Track P. Saint-Andre ISSN: 2070-1721 &yet

                                                         November 2015
                    PKIX over Secure HTTP (POSH)

Abstract

 Experience has shown that it is difficult to deploy proper PKIX
 certificates for Transport Layer Security (TLS) in multi-tenanted
 environments.  As a result, domains hosted in such environments often
 deploy applications 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 degraded security.  This document defines methods that
 make it easier to deploy certificates for proper server identity
 checking in non-HTTP application protocols.  Although these methods
 were developed for use in the Extensible Messaging and Presence
 Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they
 might also be usable in other non-HTTP application protocols.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7711.

Miller & Saint-Andre Standards Track [Page 1] RFC 7711 POSH November 2015

Copyright Notice

 Copyright (c) 2015 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 ....................................................3
 2. Terminology .....................................................4
 3. Obtaining Verification Material .................................5
    3.1. Source Domain Possesses PKIX Certificate Information .......6
    3.2. Source Domain References PKIX Certificate ..................8
    3.3. Performing Verification ....................................9
 4. Secure Delegation ...............................................9
 5. Order of Operations ............................................10
 6. Caching Results ................................................11
 7. Guidance for Server Operators ..................................12
 8. Guidance for Protocol Authors ..................................12
 9. IANA Considerations ............................................13
    9.1. Well-Known URI ............................................13
    9.2. POSH Service Names ........................................13
 10. Security Considerations .......................................14
 11. References ....................................................15
    11.1. Normative References .....................................15
    11.2. Informative References ...................................16
 Acknowledgements ..................................................18
 Authors' Addresses ................................................18

Miller & Saint-Andre Standards Track [Page 2] RFC 7711 POSH November 2015

1. Introduction

 We begin with a thought experiment.
 Imagine that you work on the operations team of a hosting company
 that provides instances of the hypothetical "Secure Protocol for
 Internet Content Exchange" (SPICE) service for ten thousand different
 customer organizations.  Each customer wants their instance to be
 identified by the customer's domain name (e.g., bar.example.com), not
 the hosting company's domain name (e.g., hosting.example.net).
 In order to properly secure each customer's SPICE instance via
 Transport Layer Security (TLS) [RFC5246], you need to obtain and
 deploy PKIX certificates [RFC5280] containing identifiers such as
 bar.example.com, as explained in the "CertID" specification
 [RFC6125].  Unfortunately, you can't obtain and deploy 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 because your legal department is
    worried about liability, too.
 o  Even if your legal department is happy, this still means managing
    one certificate for each customer across the infrastructure,
    contributing to a large administrative load.
 Given your inability to obtain and deploy public keys / certificates
 containing the right identifiers, your back-up approach has always
 been 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 (bar.example.com) and the
 delegated domain (hosting.example.net) [RFC6125].
 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 it will be several years before they will be able to

Miller & Saint-Andre Standards Track [Page 3] RFC 7711 POSH November 2015

 deploy DNSSEC and DANE for all of your customers (because of tooling
 updates, slow deployment of DNSSEC at some top-level domains, etc.).
 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 that your team has investigated is to ask each
 customer to provide the public key / certificate for its SPICE
 service at a special HTTPS URI on their website
 ("https://bar.example.com/.well-known/posh/spice.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 SPICE service (as one added
 benefit, the customer never needs to hand you a private key).
 Alternatively, the customer can redirect requests for that special
 HTTPS URI to an HTTPS URI at your own website, thus making it
 explicit that they have delegated the SPICE service to you.
 The approach sketched out above, called POSH ("PKIX over Secure
 HTTP"), is explained in the remainder of this document.  Although
 this approach was developed for use in the Extensible Messaging and
 Presence Protocol (XMPP) as a prooftype for Domain Name Associations
 (DNA) [RFC7712], it might be usable by any non-HTTP application
 protocol.

2. Terminology

 This document inherits security terminology from [RFC5280].  The
 terms "source domain", "delegated domain", "derived domain", and
 "reference 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].
 Additionally, this document uses the following terms:
 POSH client:  A client that uses the application service and that
    uses POSH to obtain material for verifying the service's identity.
 POSH server:  A server that hosts the application service and that
    uses POSH to provide material for verifying its identity.

Miller & Saint-Andre Standards Track [Page 4] RFC 7711 POSH November 2015

3. Obtaining Verification Material

 Server identity checking (see [RFC6125]) involves three different
 aspects:
 1.  A proof of the POSH server's identity (in PKIX, this takes the
     form of a PKIX end-entity certificate [RFC5280]).
 2.  Rules for checking the certificate (which vary by application
     protocol, although [RFC6125] attempts to harmonize those rules).
 3.  The material that a POSH client uses to verify the POSH server's
     identity or check the POSH 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 POSH
 server proves its 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 XMPP).  However, the POSH client obtains the
 material it will use to verify the server's proof by retrieving a
 JSON document [RFC7159] containing hashes of the PKIX certificate
 over HTTPS ([RFC7230] and [RFC2818]) from a well-known URI [RFC5785]
 at the source domain.  POSH servers MUST use HTTPS.  This means that
 the POSH client MUST verify the certificate of the HTTPS service at
 the source domain in order to securely "bootstrap" into the use of
 POSH; specifically, the rules of [RFC2818] apply to this
 "bootstrapping" step to provide a secure basis for all subsequent
 POSH operations.
 A PKIX certificate is retrieved over secure HTTP in the
 following way:
 1.  The POSH client performs an HTTPS GET request at the source
     domain to the path "/.well-known/posh/{servicedesc}.json".  The
     value of "{servicedesc}" is application-specific; see Section 8
     of this document for more details.  For example, if the
     application protocol is the hypothetical SPICE service, then
     "{servicedesc}" could be "spice"; thus, if an application client
     were to use POSH to verify an application server for the source
     domain "bar.example.com", the HTTPS GET request would be as
     follows:
     GET /.well-known/posh/spice.json HTTP/1.1
     Host: bar.example.com

Miller & Saint-Andre Standards Track [Page 5] RFC 7711 POSH November 2015

 2.  The source domain HTTPS server responds in one of three ways:
  • If it possesses PKIX certificate information for the requested

path, it responds as detailed in Section 3.1.

  • If it has a reference to where the PKIX certificate

information can be obtained, it responds as detailed in

        Section 3.2.
  • If it does not have any PKIX certificate information or a

reference to such information for the requested path, it

        responds with an HTTP 404 Not Found status code [RFC7231].

3.1. Source Domain Possesses PKIX Certificate Information

 If the source domain HTTPS server possesses the certificate
 information, it responds to the HTTPS GET request with a success
 status code and the message body set to a JSON document [RFC7159];
 the document is a "fingerprints document", i.e., a JSON object with
 the following members:
 o  A "fingerprints" member whose value is a JSON array of fingerprint
    descriptors (the member MUST include at least one fingerprint
    descriptor).
 o  An "expires" member whose value is a JSON number specifying the
    number of seconds after which the POSH client ought to consider
    the keying material to be stale (further explained under
    Section 6).
 The JSON document returned MUST NOT contain a "url" member, as
 described in Section 3.2.
 Each included fingerprint descriptor is a JSON object, where each
 member name is the textual name of a hash function (as listed in
 [HASH-NAMES]) and its associated value is the base64-encoded
 fingerprint hash generated using the named hash function (where the
 encoding adheres to the definition in Section 4 of [RFC4648] and
 where the padding bits are set to zero).
 The fingerprint hash for a given hash algorithm is generated by
 performing the named hash function over the DER encoding of the PKIX
 X.509 certificate.  (This implies that if the certificate expires or
 is revoked, the fingerprint value will be out of date.)

Miller & Saint-Andre Standards Track [Page 6] RFC 7711 POSH November 2015

 As an example of the fingerprint format, the "sha-256" and "sha-512"
 fingerprints are generated by performing the SHA-256 and SHA-512 hash
 functions, respectively, over the DER encoding of the PKIX
 certificate, as illustrated below.  Note that for readability
 whitespace has been added to the content portion of the HTTP response
 shown below but is not reflected in the Content-Length.
 Example Fingerprints Response
 HTTP/1.1 200 OK
 Content-Type: application/json
 Content-Length: 195
 {
   "fingerprints": [
     {
       "sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=",
       "sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXeJ
                   1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
     }
   ],
   "expires": 604800
 }
 The "expires" value is a hint regarding the expiration of the keying
 material.  It MUST be a non-negative integer.  If the "expires"
 member has a value of 0 (zero), a POSH client MUST consider the
 verification material to be invalid.  See Section 6 for how to
 reconcile this "expires" member with the reference's "expires"
 member.

Miller & Saint-Andre Standards Track [Page 7] RFC 7711 POSH November 2015

 To indicate alternate PKIX certificates (such as when an existing
 certificate will soon expire), the returned fingerprints member MAY
 contain multiple fingerprint descriptors.  The fingerprints 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 (note that whitespace is
 added for readability):
 {
   "fingerprints": [
     {
       "sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ",
       "sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXe
                   J1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
     },
     {
       "sha-256": "otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=",
       "sha-512": "MbBD+ausTGJisEXKSynROWrMfHP2xvBnmI79Pr/KXnDyLN
                   +13Jof8/Uq9fj5HZG8Rk1E2fclcivpGdijUsvHRg=="
     }
   ],
   "expires": 806400
 }
 Matching on any of these fingerprints is acceptable.
 Rolling over from one hosting provider to another is best handled by
 updating the relevant SRV records, not primarily by updating the POSH
 documents themselves.

3.2. Source Domain References PKIX Certificate

 If the source domain HTTPS server has a reference to the certificate
 information, it responds to the HTTPS GET request with a success
 status code and message body set to a JSON document.  The document is
 a "reference document", i.e., a JSON object with the following
 members:
 o  A "url" member whose value is a JSON string specifying the HTTPS
    URI where POSH clients can obtain the actual certificate
    information.  The URI can be a well-known POSH URI as described in
    Section 8, but it need not be.  (For historical reasons, the
    member name is "url", not "uri".)
 o  An "expires" member whose value is a JSON number specifying the
    number of seconds after which the POSH client ought to consider
    the delegation to be stale (further explained under Section 6).

Miller & Saint-Andre Standards Track [Page 8] RFC 7711 POSH November 2015

 Example Reference Response
 HTTP/1.1 200 OK
 Content-Type: application/json
 Content-Length: 82
 {
   "url":"https://hosting.example.net/.well-known/posh/spice.json",
   "expires":86400
 }
 In order to process a reference response, the client performs an
 HTTPS GET request for the URI specified in the "url" member value.
 The HTTPS server for the URI to which the client has been referred
 responds to the request with a JSON document containing fingerprints
 as described in Section 3.1.  The document retrieved from the
 location specified by the "url" member MUST NOT itself be a reference
 document (i.e., containing a "url" member instead of a "fingerprints"
 member), in order to prevent circular delegations.
    Note: See Section 10 for discussion about HTTPS redirects.
 The "expires" value is a hint regarding the expiration of the source
 domain's delegation of service to the delegated domain.  It MUST be a
 non-negative integer.  If the "expires" member has a value of 0
 (zero), a POSH client MUST consider the delegation invalid.  See
 Section 6 for guidelines about reconciling this "expires" member with
 the "expires" member of the fingerprints document.

3.3. Performing Verification

 The POSH client compares the PKIX information presented by the POSH
 server against each fingerprint descriptor object in the POSH
 fingerprints document, until a match is found using the hash
 functions that the client supports, or until the collection of POSH
 verification material is exhausted.  If none of the fingerprint
 descriptor objects match the POSH server PKIX information, the POSH
 client SHOULD reject the connection (however, the POSH client might
 still accept the connection if other verification methods are
 successful, such as DANE [RFC6698]).

4. Secure Delegation

 The delegation from the source domain to the delegated domain can be
 considered secure if the credentials offered by the POSH server match
 the verification material obtained by the client, regardless of how
 the material was obtained.

Miller & Saint-Andre Standards Track [Page 9] RFC 7711 POSH November 2015

5. Order of Operations

 In order for the POSH client to perform verification of reference
 identifiers without potentially compromising data, POSH operations
 MUST be complete before any application-layer data is exchanged for
 the source domain.  In cases where the POSH client initiates an
 application-layer connection, the client SHOULD perform all POSH
 retrievals before initiating a connection (naturally, this is not
 possible in cases where the POSH client receives instead of initiates
 an application-layer connection).  For application protocols that use
 DNS SRV (including queries for TLSA records in concert with SRV
 records as described in [RFC7673]), the POSH operations 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].
 The following diagram illustrates the possession flow:
  POSH                      Source                      POSH
 Client                     Domain                     Server
 ------                     ------                     ------
   |                          |                          |
   |      POSH Request        |                          |
   |------------------------->|                          |
   |                          |                          |
   | Return POSH fingerprints |                          |
   |<-------------------------|                          |
   |                                                     |
   |                  Service TLS Handshake              |
   |<===================================================>|
   |                                                     |
   |                     Service Data                    |
   |<===================================================>|
   |                                                     |
             Figure 1: Order of Events for Possession Flow

Miller & Saint-Andre Standards Track [Page 10] RFC 7711 POSH November 2015

 While the following diagram illustrates the reference flow:
  POSH              Source       Delegated              POSH
 Client             Domain         Domain              Server
 ------             ------         ------              ------
   |                  |              |                   |
   |  POSH Request    |              |                   |
   |----------------->|              |                   |
   |                  |              |                   |
   | Return POSH url  |              |                   |
   |<-----------------|              |                   |
   |                                 |                   |
   |            POSH Request         |                   |
   |-------------------------------->|                   |
   |                                 |                   |
   |     Return POSH fingerprints    |                   |
   |<--------------------------------|                   |
   |                                                     |
   |                 Service TLS Handshake               |
   |<===================================================>|
   |                                                     |
   |                     Service Data                    |
   |<===================================================>|
   |                                                     |
             Figure 2: Order of Events for Reference Flow

6. Caching Results

 The POSH client MUST NOT cache results (reference or fingerprints)
 indefinitely.  If the source domain returns a reference, the POSH
 client MUST use the lower of the two "expires" values when
 determining how long to cache results (i.e., if the reference
 "expires" value is lower than the fingerprints "expires" value, honor
 the reference "expires" value).  Once the POSH client considers the
 results stale, it needs to perform the entire POSH operation again,
 starting with the HTTPS GET request to the source domain.  The POSH
 client MAY use a lower value than any provided in the "expires"
 member(s), or not cache results at all.
 The foregoing considerations apply to the handling of the "expires"
 values in POSH documents; naturally, a POSH client MUST NOT consider
 an expired PKIX certificate to be valid, in accordance with
 [RFC5280].

Miller & Saint-Andre Standards Track [Page 11] RFC 7711 POSH November 2015

 The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead
 using the expiration hints provided in the POSH reference document or
 fingerprints document.  To that end, the HTTPS servers for source
 domains and derived domains SHOULD specify a 'Cache-Control' header
 indicating a very short duration (e.g., max-age=60) or "no-cache" to
 indicate that the response (redirect, reference, or fingerprints) is
 not appropriate to cache at the HTTP layer.

7. Guidance for Server Operators

 POSH is intended to ease the operational burden of securing
 application services, especially in multi-tenanted environments.  It
 does so by obviating the need to obtain certificates for hosted
 domains, so that an operator can obtain a certificate only for its
 hosting service (naturally, this certificate needs to be valid
 according to [RFC5280] and contain the proper identifier(s) in
 accordance with [RFC6125] and the relevant application protocol
 specification).
 However, in order to use POSH, an operator does need to coordinate
 with its customers so that the appropriate POSH documents are
 provided via HTTPS at a well-known URI at each customer's domain
 (i.e., at the source domain), thus ensuring delegation to the
 operator's hosting service (i.e., the delegated domain).  Because
 correct hosting of the POSH document at the source domain is
 essential for successful functioning of the POSH "chain", errors at
 the source domain will result in authentication problems, certificate
 warnings, and other operational issues.
 Furthermore, if the POSH document is a reference document instead of
 a fingerprints document, the operational burden is further decreased
 because the operator does not need to provision its customers with
 updated POSH documents when the certificate for the delegated domain
 expires or is replaced.

8. Guidance for Protocol Authors

 Protocols that use POSH are expected to register with the "POSH
 Service Names" registry defined under Section 9.2.
 For POSH-using protocols that rely on DNS SRV records [RFC2782], the
 service name SHOULD be the same as the DNS SRV "Service".  As an
 example, the POSH service name for XMPP server-to-server connections
 would be "xmpp-server" because [RFC6120] registers a DNS SRV
 "Service" of "xmpp-server".  One example of the resulting well-known
 URI would be "https://example.com/.well-known/posh/xmpp-server.json".

Miller & Saint-Andre Standards Track [Page 12] RFC 7711 POSH November 2015

 For other POSH-using protocols, the service name MAY be any unique
 string or identifier for the protocol; for example, it might be a
 service name registered with the IANA in accordance with [RFC6335],
 or it might be an unregistered name.  As an example, the well-known
 URI for the hypothetical SPICE application might be "spice".

9. IANA Considerations

9.1. Well-Known URI

 IANA has registered "posh" in the "Well-Known URIs" registry as
 defined by [RFC5785].  The completed template follows.
 URI suffix:  posh
 Change controller:  IETF
 Specification:  RFC 7711 (this document)
 Related information:  The suffix "posh" is expected to be followed by
    an additional path component consisting of a service name (say,
    "spice") and a file extension of ".json", resulting in a full path
    of, for instance, "/.well-known/posh/spice.json".  Registration of
    service names shall be requested by developers of the relevant
    application protocols.

9.2. POSH Service Names

 IANA has established the "POSH Service Names" registry within the
 "Uniform Resource Identifier (URI) Schemes" group of registries.
 The IANA registration policy [RFC5226] is Expert Review or IETF
 Review (this was chosen instead of the more liberal policy of First
 Come First Served to help ensure that POSH services are defined in
 ways that are consistent with this specification).  One or more
 Designated Experts are to be appointed by the IESG or their delegate.
 Registration requests are to be sent to the posh@ietf.org mailing
 list for review and comment, with an appropriate subject (e.g.,
 "Request for POSH service name: example").
 Before a period of 14 days has passed, the Designated Expert(s) will
 either approve or deny the registration request, communicating this
 decision both to the review list and to IANA.  Denials should include
 an explanation and, if applicable, suggestions as to how to make the
 request successful.  Registration requests that are undetermined for
 a period longer than 21 days can be brought to the IESG's attention
 (using the iesg@iesg.org mailing list) for resolution.

Miller & Saint-Andre Standards Track [Page 13] RFC 7711 POSH November 2015

9.2.1. Registration Template

 Service name:  The name requested, relative to "/.well-known/posh/";
    e.g., a service name of "example" would result in a well-known URI
    such as "https://example.com/.well-known/posh/example.json".
 Change controller:  For Standards Track RFCs, state "IETF".  In all
    other cases, provide the name and email address of the responsible
    party.  Other details (e.g., postal address or website URI) may
    also be included.
 Definition and usage:  A brief description that defines the service
    name and mentions where and how it is used (e.g., in the context
    of a particular application protocol).
 Specification:  Optionally, reference to a document that specifies
    the service or application protocol that uses the service name,
    preferably including a URI that can be used to retrieve a copy of
    the document.  An indication of the relevant sections may also be
    included but is not 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] as well as following the most modern best practices
 for TLS as specified in [RFC7525].  Additionally, the security of
 POSH can benefit from other HTTP-hardening protocols, such as HTTP
 Strict Transport Security (HSTS) [RFC6797] and key pinning [RFC7469],
 especially if the POSH client shares some information with a common
 HTTPS implementation (e.g., a platform-default web browser).
 Note well that POSH is used by a POSH client to obtain the public key
 of a POSH 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 POSH server to engage in
 certificate enrollment with a certification authority via HTTPS, as
 is done in Enrollment over Secure Transport [RFC7030].
 A web server at the source domain might redirect an HTTPS request to
 another HTTPS URI.  The location provided in the redirect response
 MUST specify an HTTPS URI.  Source domains SHOULD use only temporary
 redirect mechanisms, such as HTTP status codes 302 (Found) and 307
 (Temporary Redirect) [RFC7231].  Clients MAY treat any redirect as

Miller & Saint-Andre Standards Track [Page 14] RFC 7711 POSH November 2015

 temporary, ignoring the specific semantics for 301 (Moved
 Permanently) [RFC7231] and 308 (Permanent Redirect) [RFC7538].  To
 protect against circular references, it is RECOMMENDED that POSH
 clients follow no more than 10 redirects, although applications or
 implementations can require that fewer redirects be followed.
 Hash function agility is an important quality to ensure secure
 operations in the face of attacks against the fingerprints obtained
 within verification material.  Because POSH verification material is
 relatively short-lived compared to long-lived credentials such as
 PKIX end-entity certificates (at least as typically deployed),
 entities that deploy POSH are advised to swap out POSH documents if
 the hash functions are found to be subject to practical attacks
 [RFC4270].

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
            DOI 10.17487/RFC2818, May 2000,
            <http://www.rfc-editor.org/info/rfc2818>.
 [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
            Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
            <http://www.rfc-editor.org/info/rfc4648>.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246,
            DOI 10.17487/RFC5246, August 2008,
            <http://www.rfc-editor.org/info/rfc5246>.
 [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, DOI 10.17487/RFC5280, May 2008,
            <http://www.rfc-editor.org/info/rfc5280>.
 [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
            Uniform Resource Identifiers (URIs)", RFC 5785,
            DOI 10.17487/RFC5785, April 2010,
            <http://www.rfc-editor.org/info/rfc5785>.

Miller & Saint-Andre Standards Track [Page 15] RFC 7711 POSH November 2015

 [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, DOI 10.17487/RFC6125,
            March 2011, <http://www.rfc-editor.org/info/rfc6125>.
 [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
            Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
            March 2014, <http://www.rfc-editor.org/info/rfc7159>.
 [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
            Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
            RFC 7230, DOI 10.17487/RFC7230, June 2014,
            <http://www.rfc-editor.org/info/rfc7230>.
 [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
            Transfer Protocol (HTTP/1.1): Semantics and Content",
            RFC 7231, DOI 10.17487/RFC7231, June 2014,
            <http://www.rfc-editor.org/info/rfc7231>.
 [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
            "Recommendations for Secure Use of Transport Layer
            Security (TLS) and Datagram Transport Layer Security
            (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
            May 2015, <http://www.rfc-editor.org/info/rfc7525>.

11.2. Informative References

 [HASH-NAMES]
            "Hash Function Textual Names",
            <http://www.iana.org/assignments/
            hash-function-text-names>.
 [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
            specifying the location of services (DNS SRV)", RFC 2782,
            DOI 10.17487/RFC2782, February 2000,
            <http://www.rfc-editor.org/info/rfc2782>.
 [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "DNS Security Introduction and Requirements",
            RFC 4033, DOI 10.17487/RFC4033, March 2005,
            <http://www.rfc-editor.org/info/rfc4033>.
 [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
            Hashes in Internet Protocols", RFC 4270,
            DOI 10.17487/RFC4270, November 2005,
            <http://www.rfc-editor.org/info/rfc4270>.

Miller & Saint-Andre Standards Track [Page 16] RFC 7711 POSH November 2015

 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            DOI 10.17487/RFC5226, May 2008,
            <http://www.rfc-editor.org/info/rfc5226>.
 [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
            Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
            March 2011, <http://www.rfc-editor.org/info/rfc6120>.
 [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, DOI 10.17487/RFC6335, August 2011,
            <http://www.rfc-editor.org/info/rfc6335>.
 [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
            Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555,
            April 2012, <http://www.rfc-editor.org/info/rfc6555>.
 [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
            of Named Entities (DANE) Transport Layer Security (TLS)
            Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
            August 2012, <http://www.rfc-editor.org/info/rfc6698>.
 [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
            Transport Security (HSTS)", RFC 6797,
            DOI 10.17487/RFC6797, November 2012,
            <http://www.rfc-editor.org/info/rfc6797>.
 [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
            "Enrollment over Secure Transport", RFC 7030,
            DOI 10.17487/RFC7030, October 2013,
            <http://www.rfc-editor.org/info/rfc7030>.
 [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
            Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
            April 2015, <http://www.rfc-editor.org/info/rfc7469>.
 [RFC7538]  Reschke, J., "The Hypertext Transfer Protocol Status
            Code 308 (Permanent Redirect)", RFC 7538,
            DOI 10.17487/RFC7538, April 2015,
            <http://www.rfc-editor.org/info/rfc7538>.

Miller & Saint-Andre Standards Track [Page 17] RFC 7711 POSH November 2015

 [RFC7673]  Finch, T., Miller, M., and P. Saint-Andre, "Using
            DNS-Based Authentication of Named Entities (DANE) TLSA
            Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,
            October 2015, <http://www.rfc-editor.org/info/rfc7673>.
 [RFC7712]  Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
            Associations (DNA) in the Extensible Messaging and
            Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712,
            November 2015, <http://www.rfc-editor.org/info/rfc7712>.

Acknowledgements

 Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias
 Markmann for their implementation feedback, and to Dave Cridland,
 Chris Newton, Max Pritikin, and Joe Salowey for their input on the
 specification.
 During IESG review, Stephen Farrell, Barry Leiba, and Kathleen
 Moriarty provided helpful input that resulted in improvements in the
 document.
 Thanks also to Dave Cridland as document shepherd, Joe Hildebrand as
 working group chair, and Ben Campbell as area director.
 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
 employing him during his work on earlier draft versions of this
 document.

Authors' Addresses

 Matthew Miller
 Cisco Systems, Inc.
 1899 Wynkoop Street, Suite 600
 Denver, CO  80202
 United States
 Email: mamille2@cisco.com
 Peter Saint-Andre
 &yet
 Email: peter@andyet.com
 URI:   https://andyet.com/

Miller & Saint-Andre Standards Track [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7711.txt · Last modified: 2015/11/19 23:48 (external edit)