draft-ietf-xmpp-posh-05.txt   draft-ietf-xmpp-posh-06.txt 
XMPP Working Group M. Miller XMPP Working Group M. Miller
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track P. Saint-Andre Intended status: Standards Track P. Saint-Andre
Expires: March 2, 2016 &yet Expires: March 12, 2016 &yet
August 30, 2015 September 9, 2015
PKIX over Secure HTTP (POSH) PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-05 draft-ietf-xmpp-posh-06
Abstract Abstract
Experience has shown that it is difficult to deploy proper PKIX Experience has shown that it is difficult to deploy proper PKIX
certificates for TLS in multi-tenant environments. As a result, certificates for TLS in multi-tenant environments. As a result,
domains hosted in such environments often deploy applications using domains hosted in such environments often deploy applications using
certificates that identify the hosting service, not the hosted certificates that identify the hosting service, not the hosted
domain. Such deployments force end users and peer services to accept domain. Such deployments force end users and peer services to accept
a certificate with an improper identifier, resulting in degraded a certificate with an improper identifier, resulting in degraded
security. This document defines two methods that make it easier to security. This document defines two methods that make it easier to
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2, 2016. This Internet-Draft will expire on March 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Obtaining Verification Material . . . . . . . . . . . . . . . 4 3. Obtaining Verification Material . . . . . . . . . . . . . . . 4
3.1. Source Domain Possesses PKIX Certificate Information . . 5 3.1. Source Domain Possesses PKIX Certificate Information . . 5
3.2. Source Domain References PKIX Certificate . . . . . . . . 7 3.2. Source Domain References PKIX Certificate . . . . . . . . 8
3.3. Performing Verification . . . . . . . . . . . . . . . . . 8 3.3. Performing Verification . . . . . . . . . . . . . . . . . 9
4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 9
5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9
6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 11
7. Guidance for Server Operators . . . . . . . . . . . . . . . . 11 7. Guidance for Server Operators . . . . . . . . . . . . . . . . 11
8. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 11 8. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12 9.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12
9.2. POSH Service Names . . . . . . . . . . . . . . . . . . . 12 9.2. POSH Service Names . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
We begin with a thought experiment. We begin with a thought experiment.
Imagine that you work on the operations team of a hosting company Imagine that you work on the operations team of a hosting company
that provides instances of the hypothetical "Secure Protocol for that provides instances of the hypothetical "Secure Protocol for
Internet Content Exchange" (SPICE) service for ten thousand different Internet Content Exchange" (SPICE) service for ten thousand different
customer organizations. Each customer wants their instance to be customer organizations. Each customer wants their instance to be
identified by the customer's domain name (e.g., bar.example.com), not identified by the customer's domain name (e.g., bar.example.com), not
skipping to change at page 3, line 46 skipping to change at page 3, line 46
problem. However, your customers and your operations team have told problem. However, your customers and your operations team have told
you that it will be several years before they will be able to deploy you that it will be several years before they will be able to deploy
DNSSEC and DANE for all of your customers (because of tooling DNSSEC and DANE for all of your customers (because of tooling
updates, slow deployment of DNSSEC at some top-level domains, etc.). updates, slow deployment of DNSSEC at some top-level domains, etc.).
The product managers in your company are pushing you to find a method 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 that can be deployed more quickly to overcome the lack of proper
server identity checking for your hosted customers. server identity checking for your hosted customers.
One possible approach that your team has investigated is to ask each One possible approach that your team has investigated is to ask each
customer to provide the public key / certificate for its SPICE customer to provide the public key / certificate for its SPICE
service at a special HTTPS URI on their website ("https:// service at a special HTTPS URI on their website
bar.example.com/.well-known/posh/spice.json" is one possibility). ("https://bar.example.com/.well-known/posh/spice.json" is one
This could be a public key that you generate for the customer, but possibility). This could be a public key that you generate for the
because the customer hosts it via HTTPS, any user agent can find that customer, but because the customer hosts it via HTTPS, any user agent
public key and check it against the public key you provide during TLS can find that public key and check it against the public key you
negotiation for the SPICE service (as one added benefit, the customer provide during TLS negotiation for the SPICE service (as one added
never needs to hand you a private key). Alternatively, the customer benefit, the customer never needs to hand you a private key).
can redirect requests for that special HTTPS URI to an HTTPS URI at
your own website, thus making it explicit that they have delegated Alternatively, the customer can redirect requests for that special
the SPICE service to you. 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 The approach sketched out above, called POSH ("PKIX Over Secure
HTTP"), is explained in the remainder of this document. While this HTTP"), is explained in the remainder of this document. While this
approach was developed for use in the Extensible Messaging and approach was developed for use in the Extensible Messaging and
Presence Protocol (XMPP) as a prooftype for Domain Name Associations Presence Protocol (XMPP) as a prooftype for Domain Name Associations
(DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP
application protocol. application protocol.
2. Terminology 2. Terminology
skipping to change at page 6, line 33 skipping to change at page 6, line 33
encoding adheres to the definition in Section 4 of [RFC4648] and encoding adheres to the definition in Section 4 of [RFC4648] and
where the padding bits are set to zero). where the padding bits are set to zero).
The fingerprint hash for a given hash algorithm is generated by The fingerprint hash for a given hash algorithm is generated by
performing the named hash function over the DER encoding of the PKIX performing the named hash function over the DER encoding of the PKIX
X.509 certifiate. (This implies that if the certificate expires or X.509 certifiate. (This implies that if the certificate expires or
is revoked, the fingerprint value will be out of date.) is revoked, the fingerprint value will be out of date.)
As an example of the fingerprint format, a "sha-256" fingerprint is As an example of the fingerprint format, a "sha-256" fingerprint is
generated by performing the SHA-256 hash function over the DER generated by performing the SHA-256 hash function over the DER
encoding of the PKIX certificate, as illustrated below. encoding of the PKIX certificate, as illustrated below. Note that
whitespace is added to the content portion of the HTTP response for
readability, but is not reflected in the Content-Length.
Example Fingerprints Response Example Fingerprints Response
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Content-Length: 135 Content-Length: 195
{ {
"fingerprints": [ "fingerprints": [
{ {
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=" "sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXeJ
1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
} }
], ],
"expires": 604800 "expires": 604800
} }
The "expires" value is a hint regarding the expiration of the keying The "expires" value is a hint regarding the expiration of the keying
material. It MUST be a non-negative integer. If the "expires" material. It MUST be a non-negative integer. If the "expires"
member has value of 0 (zero), a POSH client MUST consider the member has value of 0 (zero), a POSH client MUST consider the
verification material to be invalid. See Section 6 for how to verification material to be invalid. See Section 6 for how to
reconcile this "expires" member with the reference's "expires" reconcile this "expires" member with the reference's "expires"
member. member.
To indicate alternate PKIX certificates (such as when an existing To indicate alternate PKIX certificates (such as when an existing
certificate will soon expire), the returned fingerprints member MAY certificate will soon expire), the returned fingerprints member MAY
contain multiple fingerprint descriptors. The fingerprints SHOULD be contain multiple fingerprint descriptors. The fingerprints SHOULD be
ordered with the most relevant certificate first as determined by the ordered with the most relevant certificate first as determined by the
application service operator (e.g., the renewed certificate), application service operator (e.g., the renewed certificate),
followed by the next most relevant certificate (e.g., the certificate followed by the next most relevant certificate (e.g., the certificate
soonest to expire). Here is an example: soonest to expire). Here is an example (note that whitespace is
added for readability):
{ {
"fingerprints": [ "fingerprints": [
{ {
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ" "sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXe
J1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
}, },
{ {
"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=" "sha-256": "otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=",
"sha-512": "MbBD+ausTGJisEXKSynROWrMfHP2xvBnmI79Pr/KXnDyLN
+13Jof8/Uq9fj5HZG8Rk1E2fclcivpGdijUsvHRg=="
} }
], ],
"expires": 806400 "expires": 806400
} }
Matching on any of these fingerprints is acceptable. Matching on any of these fingerprints is acceptable.
Rolling over from one hosting provider to another is best handled by Rolling over from one hosting provider to another is best handled by
updating the relevant SRV records, not primarily by updating the POSH updating the relevant SRV records, not primarily by updating the POSH
documents themselves. documents themselves.
3.2. Source Domain References PKIX Certificate 3.2. Source Domain References PKIX Certificate
If the Source Domain HTTPS server has a reference to the certificate If the Source Domain HTTPS server has a reference to the certificate
information, it responds to the HTTPS GET request with a success information, it responds to the HTTPS GET request with a success
skipping to change at page 14, line 23 skipping to change at page 15, line 6
relatively short-lived compared to long-lived credentials such as relatively short-lived compared to long-lived credentials such as
PKIX end-entity certificates (at least as typically deployed), PKIX end-entity certificates (at least as typically deployed),
entities that deploy POSH are advised to swap out POSH documents if entities that deploy POSH are advised to swap out POSH documents if
the hash functions are found to be subject to realistic attacks. the hash functions are found to be subject to realistic attacks.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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, May 2000. [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 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. 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 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (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., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (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 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April Uniform Resource Identifiers (URIs)", RFC 5785, DOI
2010. 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing", RFC
2014. 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014, 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
skipping to change at page 15, line 36 skipping to change at page 16, line 32
progress), April 2015. progress), April 2015.
[I-D.ietf-xmpp-dna] [I-D.ietf-xmpp-dna]
Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
Associations (DNA) in the Extensible Messaging and Associations (DNA) in the Extensible Messaging and
Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in
progress), March 2015. progress), March 2015.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. 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. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. 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 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. 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 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, DOI 10.17487/
RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>.
[RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
Secure Transport", RFC 7030, October 2013. "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 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, April 2015. 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 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, April 2015. 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
April 2015, <http://www.rfc-editor.org/info/rfc7538>.
[HASH-NAMES] [HASH-NAMES]
"Hash Function Textual Names", <http://www.iana.org/ "Hash Function Textual Names",
assignments/hash-function-text-names/ <http://www.iana.org/assignments/hash-function-text-names/
hash-function-text-names.xhtml>. hash-function-text-names.xhtml>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias
Markmann for their implementation feedback, and to Dave Cridland, Markmann for their implementation feedback, and to Dave Cridland,
Chris Newton, Max Pritikin, and Joe Salowey for their input on the Chris Newton, Max Pritikin, and Joe Salowey for their input on the
specification. specification.
During IESG review, Stephen Farrell, Barry Leiba, and Kathleen During IESG review, Stephen Farrell, Barry Leiba, and Kathleen
 End of changes. 37 change blocks. 
58 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/