RFC 7711

PKIX over Secure HTTP (POSH)

📅 published November 2015, from ietf

RFC 7711: PKIX over Secure HTTP (POSH) 🦋

Okay bestie, this one is from November 2015 and it's on the Standards Track 💅. It's written by M. Miller from Cisco Systems, Inc. and P. Saint-Andre from &yet 🫶. The ISSN is 2070-1721. The title block doesn't list any Obsoletes or Updates entries, so this RFC doesn't replace or modify any earlier ones 🌸.

Abstract ✨

Okay so here's the tea 🍵. Getting proper PKIX certificates for Transport Layer Security (TLS) is genuinely hard in multi-tenanted hosting setups 😭. Because of that, a lot of domains end up running their apps with certificates that name the hosting provider instead of the actual domain. That means end users and peer services have to accept a certificate with the wrong identifier, and security takes a hit 💀. This document introduces methods that make it easier to get certificates for proper server identity checking in non-HTTP application protocols 🎀. The methods were built for the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, but other non-HTTP application protocols might be able to use them too 🌈.

Status of This Memo 🧚

This is an Internet Standards Track document 💜.

It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7711 🔗.

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, which you can find at http://trustee.ietf.org/license-info as of the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 🙈. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜.

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

1. Introduction 🍓

Let's start with a thought experiment 🧠.

Picture yourself on the operations team at a hosting company. You run instances of the made-up "Secure Protocol for Internet Content Exchange" (SPICE) service for ten thousand different customer organizations 😳. Every customer wants their instance to show up under their own domain name (say, bar.example.com) and not under the hosting company's domain name (say, hosting.example.net) 💅.

To secure each customer's SPICE instance with Transport Layer Security (TLS) [RFC5246], you'd need PKIX certificates [RFC5280] that carry identifiers like bar.example.com, as the "CertID" specification [RFC6125] explains. But you literally can't get or deploy those certificates, and here's why 😭:

  • Certification authorities won't issue them to you, because you work for the hosting company and not for the customer organization.
  • Customers won't get those certificates and hand them (plus the private keys) over to you, since their legal department is nervous about liability.
  • You don't want to install those certificates (plus the private keys) on your servers either, because your legal department is nervous about liability too.
  • Even if legal is chill with it, you'd still be managing one certificate per customer across the whole infrastructure, which is a massive admin headache.

So you've been relying on a backup plan: a certificate that names hosting.example.net. But customers and end users keep complaining about warning messages in their user agents 🙈. There's also the security problem with taking a "leap of faith" and accepting the identity mismatch between the source domain (bar.example.com) and the delegated domain (hosting.example.net) [RFC6125]. Honestly, that's both insecure and unsustainable 💀.

You looked into DNS Security [RFC4033] and DNS-Based Authentication of Named Entities (DANE) [RFC6698] as a fix. The problem is that your customers and your ops team say it'll be years before everyone can deploy DNSSEC and DANE. Tooling needs updating, some top-level domains are slow to roll out DNSSEC, and so on ⏳. Meanwhile, the product managers want something they can ship faster to close the gap in proper server identity checking for hosted customers 🚀.

One approach your team considered: each customer posts the public key or certificate for its SPICE service at a special HTTPS URI on its own website. The example given is https://bar.example.com/.well-known/posh/spice.json ✨. The key could be one you generate for the customer, but since the customer serves it over HTTPS, any user agent can grab that key and compare it with the key you present during the TLS negotiation for the SPICE service 🔍. As a bonus, the customer never has to hand you a private key 🎀. Or the customer can redirect requests for that special HTTPS URI to an HTTPS URI on your website, which makes it crystal clear that they've delegated the SPICE service to you 💜.

That approach is called POSH ("PKIX over Secure HTTP"), and the rest of this document explains how it works 🦋. It was developed for XMPP as a prooftype for Domain Name Associations (DNA) [RFC7712], but any non-HTTP application protocol might be able to use it 🌈.

2. Terminology 📚

This document inherits its 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] ✨.

This document also uses these terms 🫶:

  • POSH client: A client that uses the application service and uses POSH to get the material it needs to verify the service's identity.
  • POSH server: A server that hosts the application service and uses POSH to provide the material that verifies its identity.

3. Obtaining Verification Material 🔐

Server identity checking (see [RFC6125]) has three different parts 🧩:

  1. A proof of the POSH server's identity. In PKIX, this is a PKIX end-entity certificate [RFC5280].
  2. Rules for checking that certificate. These vary by application protocol, although [RFC6125] tries to harmonize them.
  3. The material a POSH client uses to verify the POSH server's identity or check its proof. In PKIX, this means chaining the end-entity certificate back to a trusted root and running all the validity checks described in [RFC5280], [RFC6125], and the relevant application protocol specification.

When POSH is in play, the first two parts stay the same 💖. The POSH server still proves its identity by presenting a PKIX certificate [RFC5280], and that certificate is checked against the rules in the right application protocol spec (for XMPP, that's [RFC6120]) ✅. What changes is how the POSH client gets the material to verify the server's proof. It retrieves a JSON document [RFC7159] full of hashes of the PKIX certificate. It does this over HTTPS ([RFC7230] and [RFC2818]), from a well-known URI [RFC5785] at the source domain 🌸.

Here's the important part 🚨: POSH servers MUST use HTTPS. That means the POSH client MUST verify the certificate of the HTTPS service at the source domain before it can securely "bootstrap" into POSH. Specifically, the rules of [RFC2818] apply to this bootstrapping step, which gives a secure starting point for every POSH operation after it 🔥.

Here's how a PKIX certificate gets retrieved over secure HTTP 👑:

  1. The POSH client sends an HTTPS GET request at the source domain to the path /.well-known/posh/{servicedesc}.json. What goes in {servicedesc} depends on the application, so check Section 8 of this document for details. For example, if the application protocol is the made-up SPICE service, {servicedesc} could be spice. So if an application client wanted to use POSH to verify an application server for the source domain bar.example.com, the HTTPS GET request would look like this 💅:
GET /.well-known/posh/spice.json HTTP/1.1
Host: bar.example.com
  1. The source domain's HTTPS server responds in one of three ways 🎀:
    • If it has 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 found, it responds as detailed in Section 3.2.
    • If it has neither the PKIX certificate information nor a reference to it for the requested path, it responds with an HTTP 404 Not Found status code [RFC7231] 🙈.

3.1. Source Domain Possesses PKIX Certificate Information 🎀

okay so bestie, if the source domain's HTTPS server actually has the certificate info, it answers the HTTPS GET with a success status code and a JSON body [RFC7159]. This is the "fingerprints document" 💖, and it's a JSON object with these members:

  • A "fingerprints" member, whose value is a JSON array of fingerprint descriptors. The array MUST include at least one fingerprint descriptor. 🍓
  • An "expires" member, whose value is a JSON number saying how many seconds the POSH client ought to wait before it treats the keying material as stale (more on that in Section 6) ⏳

The JSON document returned MUST NOT contain a "url" member, as described in Section 3.2. no exceptions, periodt 💅

Each fingerprint descriptor is its own JSON object. Each member name is the textual name of a hash function (from [HASH-NAMES]), and its value is the base64-encoded fingerprint hash made with that function. The encoding follows Section 4 of [RFC4648], and the padding bits are set to zero 🧚

The fingerprint hash for a given algorithm comes from running that hash function over the DER encoding of the PKIX X.509 certificate. (This means that if the certificate expires or gets revoked, the fingerprint is going to be out of date 💀)

Here's an example. The "sha-256" and "sha-512" fingerprints come from running SHA-256 and SHA-512 over the DER encoding of the PKIX certificate, like this. The whitespace in the response below is only there so it's easier to read. It isn't counted 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 about when the keying material expires. It MUST be a non-negative integer. If "expires" is 0 (zero), a POSH client MUST consider the verification material invalid. Section 6 explains how to reconcile this "expires" member with the reference's "expires" member 🦋

If there are alternate PKIX certificates (like when an existing one is about to expire 👀), the fingerprints member MAY contain multiple fingerprint descriptors. The fingerprints SHOULD be ordered with the most relevant certificate first, as decided by the application service operator (for example, the renewed certificate). The next most relevant one comes after that (for example, the certificate that expires soonest). Here's an example. 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 one of these fingerprints is acceptable ✨

Moving from one hosting provider to another is best handled by updating the relevant SRV records 🫶 It's not mainly about updating the POSH documents themselves 🙈

3.2. Source Domain References PKIX Certificate 🔥

If the source domain's HTTPS server has a reference to the certificate info, it answers the HTTPS GET with a success status code and a JSON body. This is a "reference document" 🦋, a JSON object with these members:

  • A "url" member, whose value is a JSON string giving the HTTPS URI where POSH clients can get the actual certificate info. The URI can be a well-known POSH URI (described in Section 8), but it doesn't have to be. (Historically, the member name is "url", not "uri" 📚)
  • An "expires" member, whose value is a JSON number saying how many seconds the POSH client ought to consider the delegation stale (more in Section 6) ⏳

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
}

To process a reference response, the client makes an HTTPS GET request for the URI in the "url" member value. The HTTPS server for that URI answers with a JSON document containing fingerprints, as described in Section 3.1. The document retrieved from the location in the "url" member MUST NOT itself be a reference document (meaning it can't contain a "url" member instead of a "fingerprints" member), so we don't end up with circular delegations 🔁🚫

Note: See Section 10 for discussion about HTTPS redirects. 👀

The "expires" value is a hint about when the source domain's delegation of service to the delegated domain expires. It MUST be a non-negative integer. If the "expires" member is 0 (zero), a POSH client MUST consider the delegation invalid. Section 6 has guidelines for reconciling this "expires" member with the "expires" member of the fingerprints document 💜

3.3. Performing Verification 🕵️‍♀️

The POSH client compares the PKIX info presented by the POSH server against each fingerprint descriptor object in the POSH fingerprints document. It keeps going until it finds a match using the hash functions the client supports, or until the POSH verification material runs out 🏃‍♀️ If none of the fingerprint descriptor objects match the POSH server's PKIX info, the POSH client SHOULD reject the connection. (However, the POSH client might still accept the connection if other verification methods succeed, 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 the client got, no matter how that material was obtained 🔐

5. Order of Operations ⏰

So for the POSH client to verify reference identifiers without potentially compromising data, POSH operations MUST be complete before any application-layer data is exchanged for the source domain. 🙅‍♀️ When the POSH client starts an application-layer connection, it SHOULD do all its POSH retrievals before starting that connection. (Obviously this isn't possible when the POSH client receives a connection instead of starting one 🙃) For application protocols that use DNS SRV (including TLSA lookups alongside SRV records as described in [RFC7673]), the POSH operations ideally ought to happen in parallel with resolving the SRV records and the addresses of any targets. It's kind of like the "Happy Eyeballs" approach for IPv4 and IPv6 [RFC6555] 🏎️

Here's the possession flow diagram 📊

 POSH                      Source                      POSH
Client                     Domain                     Server
------                     ------                     ------
  |                          |                          |
  |      POSH Request        |                          |
  |------------------------->|                          |
  |                          |                          |
  | Return POSH fingerprints |                          |
  |<-------------------------|                          |
  |                                                     |
  |                  Service TLS Handshake              |
  |<===================================================>|
  |                                                     |
  |                     Service Data                    |
  |<===================================================>|
  |                                                     |

            Figure 1: Order of Events for Possession Flow

And now 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) forever 🙅‍♀️ If the source domain returns a reference, the POSH client MUST use the lower of the two "expires" values when deciding how long to cache results. (So if the reference "expires" value is lower than the fingerprints "expires" value, go with the reference "expires" value 💅) Once the POSH client considers the results stale, it has to do the whole POSH operation again, starting with the HTTPS GET request to the source domain. The POSH client MAY use a lower value than any given in the "expires" member(s), or not cache results at all 🌸

Everything above about "expires" values in POSH documents applies here too. And obviously, a POSH client MUST NOT consider an expired PKIX certificate to be valid, per [RFC5280] 🔥

The POSH client SHOULD NOT rely on HTTP caching mechanisms. Instead, it uses the expiration hints 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 with a very short duration (for example, max-age=60) or "no-cache", to show that the response (redirect, reference, or fingerprints) isn't appropriate to cache at the HTTP layer 💖

7. Guidance for Server Operators ✨

okay so POSH is basically made to take the stress out of securing app services, especially when one provider is hosting a bunch of different domains 🫶 The best part is that the operator doesn't need a certificate for every single hosted domain. They only need one for their hosting service 🎀 (and yes, that cert still has to be valid under [RFC5280] and carry the right identifiers per [RFC6125] and whatever the application protocol spec says 🤓).

BUT (and this is a big but) the operator has to team up with each customer so the right POSH documents get served over HTTPS at a well-known URI on each customer's domain, which is the source domain 🌸 That's what links the source domain to the operator's hosting service, the delegated domain. Since the whole POSH "chain" depends on that document being hosted correctly, any mistake at the source domain can cause authentication problems, certificate warnings, and other operational messes 😭

Also, if the POSH document is a reference document instead of a fingerprints document, life gets way easier 💅 The operator doesn't have to send customers fresh POSH documents every time the delegated domain's certificate expires or gets replaced. Iconic 🦋

8. Guidance for Protocol Authors 🧚

protocols that use POSH are expected to register with the "POSH Service Names" registry from Section 9.2 📝

if a POSH-using protocol relies on DNS SRV records [RFC2782], the service name SHOULD be the same as the DNS SRV "Service" 💖 for 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. so one example of the resulting well-known URI would be https://example.com/.well-known/posh/xmpp-server.json ✨

for other POSH-using protocols, the service name MAY be any unique string or identifier for the protocol 🌈 it could be a service name registered with IANA under [RFC6335], or it could just 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]. here's the completed template, bestie 💜

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 set up the "POSH Service Names" registry inside the "Uniform Resource Identifier (URI) Schemes" group of registries 🗂️

the IANA registration policy [RFC5226] is Expert Review or IETF Review. this was picked over the more relaxed First Come First Served policy so POSH services get defined in ways that match this spec 🔒 One or more Designated Experts are to be appointed by the IESG or their delegate.

registration requests go to the posh@ietf.org mailing list for review and comment, with a clear subject (for example, "Request for POSH service name: example") 📬

before 14 days have passed, the Designated Expert(s) will either approve or deny the request, and they'll tell both the review list and IANA 🫶 if they deny it, the denial should include an explanation and, if it applies, suggestions for how to make the request work. if a request is still undecided after 21 days, it can be brought to the IESG's attention by using the iesg@iesg.org mailing list 🙏

9.2.1. Registration Template

here's the template for a new service name 💅

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 doc supplements the security considerations in the specs for application protocols that choose to use POSH (like [RFC6120] and [RFC6125] for XMPP) but it does NOT replace them 🙅‍♀️ the security of requests and responses sent over HTTPS depends on checking the identity of the HTTP server per [RFC2818], and on following the most modern TLS best practices from [RFC7525] 🔐 POSH can also get extra protection from other HTTP-hardening stuff like HTTP Strict Transport Security (HSTS) [RFC6797] and key pinning [RFC7469], especially if the POSH client shares some info with a common HTTPS implementation (like a platform-default web browser) 🌐

note well: POSH is how a POSH client gets the public key of a POSH server it might connect to for an application protocol like IMAP or XMPP. POSH does NOT let a hosted domain send private keys to a hosting service over HTTPS 🔑 And POSH also does NOT let a POSH server do certificate enrollment with a certification authority over HTTPS, the way [RFC7030] Enrollment over Secure Transport does.

a web server at the source domain might redirect an HTTPS request to another HTTPS URI. the location 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 temporary, ignoring the specific semantics of 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 a big deal for keeping things secure when someone attacks the fingerprints in the verification material 🛡️ POSH verification material is relatively short-lived compared to long-lived credentials like PKIX end-entity certificates (at least as they're typically deployed), so entities that deploy POSH are advised to swap out POSH documents if the hash functions turn out to be subject to practical attacks [RFC4270] 💀

11. References 📚

11.1. Normative References

all the normative references, with every detail kept 🫶

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

[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 📚✨

these are the extra-credit reads, bestie. They're here for background, so you don't need them to get the main spec 🧚

Acknowledgements ✨

Huge 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/
📦 where this page comes from