diff options
Diffstat (limited to 'doc/rfc/rfc7711.txt')
| -rw-r--r-- | doc/rfc/rfc7711.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7711.txt b/doc/rfc/rfc7711.txt new file mode 100644 index 0000000..81e7323 --- /dev/null +++ b/doc/rfc/rfc7711.txt @@ -0,0 +1,1011 @@ + + + + + + +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] + |