draft-ietf-xmpp-posh-03.txt   draft-ietf-xmpp-posh-04.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: July 30, 2015 &yet Expires: August 27, 2015 &yet
January 26, 2015 February 23, 2015
PKIX over Secure HTTP (POSH) PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-03 draft-ietf-xmpp-posh-04
Abstract Abstract
Experience has shown that it is extremely difficult to deploy proper Experience has shown that it is extremely difficult to deploy proper
PKIX certificates for TLS in multi-tenanted environments. As a PKIX certificates for TLS in multi-tenanted environments. As a
result, domains hosted in such environments often deploy applications result, domains hosted in such environments often deploy applications
using certificates that identify the hosting service, not the hosted using 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 obvious a certificate with an improper identifier, resulting in obvious
security implications. This document defines two methods that make security implications. This document defines two methods that make
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 July 30, 2015. This Internet-Draft will expire on August 27, 2015.
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 Materials . . . . . . . . . . . . . . 4 3. Obtaining Verification Materials . . . . . . . . . . . . . . 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 . . . . . . . . 6 3.2. Source Domain References PKIX Certificate . . . . . . . . 7
3.3. Performing Verification . . . . . . . . . . . . . . . . . 7 3.3. Performing Verification . . . . . . . . . . . . . . . . . 8
4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8
5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8
6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 9 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10
7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10 7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Guidelines for Protocols that Use POSH . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 the "foo" service (or email or instant messaging or that provides the "SPICE" service (or email or instant messaging or
social networking service) for ten thousand different customer social networking service) for ten thousand different customer
organizations. Each customer wants their service to be identified by organizations. Each customer wants their service to be identified by
the customer's domain name (e.g., bar.example.com), not the hosting the customer's domain name (e.g., bar.example.com), not the hosting
company's domain name (e.g., hosting.example.net). company's domain name (e.g., hosting.example.net).
In order to properly secure each customer's "foo" service via In order to properly secure each customer's "SPICE" service via
Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX
certificates [RFC5280] containing identifiers such as certificates [RFC5280] containing identifiers such as
bar.example.com, as explained in the "CertID" specification bar.example.com, as explained in the "CertID" specification
[RFC6125]. Unfortunately, you can't obtain such certificates [RFC6125]. Unfortunately, you can't obtain such certificates
because: because:
o Certification authorities won't issue such certificates to you o Certification authorities won't issue such certificates to you
because you work for the hosting company, not the customer because you work for the hosting company, not the customer
organization. organization.
skipping to change at page 3, line 42 skipping to change at page 3, line 42
Based Authentication of Named Entities (DANE) [RFC6698] to solve the Based Authentication of Named Entities (DANE) [RFC6698] to solve the
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 the "foo" customer to provide the public key / certificate for the "SPICE"
service at a special HTTPS URL on their website service at a special HTTPS URL on their website
("https://bar.example.com/.well-known/posh.foo.json" is one ("https://bar.example.com/.well-known/posh.spice.json" is one
possibility). This could be a public key that you generate for the possibility). This could be a public key that you generate for the
customer, but because the customer hosts it via HTTPS, any user agent 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 can find that public key and check it against the public key you
provide during TLS negotiation for the "foo" service (as one added provide during TLS negotiation for the "SPICE" service (as one added
benefit, the customer never needs to hand you a private key). benefit, the customer never needs to hand you a private key).
Alternatively, the customer can redirect requests for that special Alternatively, the customer can redirect requests for that special
HTTPS URL to an HTTPS URL at your own website, thus making it HTTPS URL to an HTTPS URL at your own website, thus making it
explicit that they have delegated the "foo" service to you. 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
This document inherits security terminology from [RFC5280]. The This document inherits security terminology from [RFC5280]. The
terms "Source Domain", "Delegated Domain", "Derived Domain", and terms "Source Domain", "Delegated Domain", "Derived Domain", and
"Reference Identifier" are used as defined in the "CertID" "Reference Identifier" are used as defined in the "CertID"
specification [RFC6125]. specification [RFC6125].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the following terms:
POSH client: The client utilizing the application service (e.g., an
XMPP client). It relies on the protocol defined herein to verify
the POSH server's identity.
POSH server: The server hosting the application service (e.g., an
XMPP server). It expects clients to rely on the protocol defined
herein to verify its identity.
3. Obtaining Verification Materials 3. Obtaining Verification Materials
Server identity checking (see [RFC6125]) involves three different Server identity checking (see [RFC6125]) involves three different
aspects: aspects:
1. A proof of the POSH server's identity (in PKIX, this takes the 1. A proof of the POSH server's identity (in PKIX, this takes the
form of a PKIX end-entity certificate [RFC5280]). form of a PKIX end-entity certificate [RFC5280]).
2. Rules for checking the certificate (which vary by application 2. Rules for checking the certificate (which vary by application
protocol, although [RFC6125] attempts to harmonize those rules). protocol, although [RFC6125] attempts to harmonize those rules).
skipping to change at page 5, line 4 skipping to change at page 5, line 16
server proves it identity by presenting a PKIX certificate [RFC5280] server proves it identity by presenting a PKIX certificate [RFC5280]
and the certificate is checked according to the rules defined in the and the certificate is checked according to the rules defined in the
appropriate application protocol specification (such as [RFC6120] for appropriate application protocol specification (such as [RFC6120] for
XMPP). However, the POSH client obtains the materials it will use to XMPP). However, the POSH client obtains the materials it will use to
verify the server's proof by retrieving a JSON document [RFC7159] verify the server's proof by retrieving a JSON document [RFC7159]
containing hashes of the PKIX certificate over HTTPS ([RFC7230] and containing hashes of the PKIX certificate over HTTPS ([RFC7230] and
[RFC2818]) from a well-known URI [RFC5785] at the Source Domain. [RFC2818]) from a well-known URI [RFC5785] at the Source Domain.
(This means that the POSH client needs to verify the certificate of (This means that the POSH client needs to verify the certificate of
the HTTPS service at the Source Domain in order to securely the HTTPS service at the Source Domain in order to securely
"bootstrap" into the use of POSH; specifically, the rules of "bootstrap" into the use of POSH; specifically, the rules of
[RFC2818] apply to this "bootstrapping" step to provide a secure [RFC2818] apply to this "bootstrapping" step to provide a secure
basis for all subsequent POSH processing.) basis for all subsequent POSH processing.)
The process for retrieving a PKIX certificate over secure HTTP is as The process for retrieving a PKIX certificate over secure HTTP is as
follows. follows.
1. The POSH client performs an HTTPS GET request at the Source 1. The POSH client performs an HTTPS GET request at the Source
Domain to the path "/.well-known/posh.{servicedesc}.json". The Domain to the path "/.well-known/posh.{servicedesc}.json". The
value of "{servicedesc}" is application-specific; see Section 8 value of "{servicedesc}" is application-specific; see Section 9
of this document for more details. For example, if the of this document for more details. For example, if the
application protocol is some hypothetical "foo" service, then application protocol is some hypothetical "SPICE" service, then
"{servicedesc}" could be "foo"; thus if an application client "{servicedesc}" could be "spice"; thus if an application client
were to use POSH to verify an application server for the Source were to use POSH to verify an application server for the Source
Domain "bar.example.com", the HTTPS GET request would be as Domain "bar.example.com", the HTTPS GET request would be as
follows: follows:
GET /.well-known/posh.foo.json HTTP/1.1 GET /.well-known/posh.spice.json HTTP/1.1
Host: bar.example.com Host: bar.example.com
2. The Source Domain HTTPS server responds in one of three ways: 2. The Source Domain HTTPS server responds in one of three ways:
* If it possesses PKIX certificate information for the requested * If it possesses PKIX certificate information for the requested
path, it responds as detailed in Section 3.1. path, it responds as detailed in Section 3.1.
* If it has a reference to where the PKIX certificate * If it has a reference to where the PKIX certificate
information can be obtained, it responds as detailed in information can be obtained, it responds as detailed in
Section 3.2. Section 3.2.
skipping to change at page 6, line 5 skipping to change at page 6, line 15
the document is a JSON object which MUST have the following: the document is a JSON object which MUST have the following:
o A "fingerprints" field whose value is a JSON array of fingerprint o A "fingerprints" field whose value is a JSON array of fingerprint
descriptors. descriptors.
o An "expires" field whose value is a JSON number specifying the o An "expires" field whose value is a JSON number specifying the
number of seconds after which the POSH client ought to consider number of seconds after which the POSH client ought to consider
the key information to be stale (further explained under the key information to be stale (further explained under
Section 6). Section 6).
The JSON document returned MUST NOT contain a "url" field as
described in Section 3.2.
Each included fingerprint descriptor is a JSON object, where each Each included fingerprint descriptor is a JSON object, where each
member name is the textual name of a hash function (as listed in member name is the textual name of a hash function (as listed in
[HASH-NAMES]) and its associated value is the base 64 encoded [HASH-NAMES]) and its associated value is the base 64 encoded
fingerprint hash generated using the named hash function (where the fingerprint hash generated using the named hash function (where the
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). Each fingerprint descriptor where the padding bits are set to zero). Each fingerprint descriptor
MUST possess at least one named hash function. MUST possess at least one named hash function.
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
skipping to change at page 7, line 20 skipping to change at page 7, line 32
number of seconds after which the POSH client ought to consider number of seconds after which the POSH client ought to consider
the delegation to be stale (further explained under Section 6). the delegation to be stale (further explained under Section 6).
Example Reference Response Example Reference Response
HTTP/1.1 200 Ok HTTP/1.1 200 Ok
Content-Type: application/json Content-Type: application/json
Content-Length: 79 Content-Length: 79
{ {
"url":"https://hosting.example.net/.well-known/posh.foo.json", "url":"https://hosting.example.net/.well-known/posh.spice.json",
"expires":86400 "expires":86400
} }
The client performs an HTTPS GET request for the URL specified in the The client performs an HTTPS GET request for the URL specified in the
"url" field value. The HTTPS server for the URL to which the client "url" field value. The HTTPS server for the URL to which the client
has been redirected responds to the request with a JSON document has been redirected responds to the request with a JSON document
containing fingerprints as described in Section 3.1. The content containing fingerprints as described in Section 3.1. The content
retrieved from the "url" location MUST NOT itself be a reference retrieved from the "url" location MUST NOT itself be a reference
(i.e., containing a "url" field instead of a "fingerprints" field), (i.e., containing a "url" field instead of a "fingerprints" field),
in order to prevent circular delegations. in order to prevent circular delegations.
Note: The JSON document returned by the Source Domain HTTPS server Note: See Section 10 for discussion about HTTPS redirects.
MUST contain either a reference or a fingerprints document, but
MUST NOT contain both.
Note: See Section 9 for discussion about HTTPS redirects.
The "expires" value is a hint regarding the expiration of the Source 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 Domain's delegation of service to the Delegated Domain. It MUST be a
non-negative integer. If no "expires" field is included or its value non-negative integer. If no "expires" field is included or its value
is equal to 0, a POSH client SHOULD consider the delegation invalid. is equal to 0, a POSH client SHOULD consider the delegation invalid.
See Section 6 for guidelines about reconciling this "expires" field See Section 6 for guidelines about reconciling this "expires" field
with the "expires" field of the fingerprints document. with the "expires" field of the fingerprints document.
3.3. Performing Verification 3.3. Performing Verification
skipping to change at page 10, line 33 skipping to change at page 11, line 5
"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=" "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
} }
], ],
"expires": 806400 "expires": 806400
} }
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
files themselves. files themselves.
8. IANA Considerations 8. Guidelines for Protocols that Use POSH
This document registers a well-known URI [RFC5785] for protocols that
use POSH. The completed template follows.
URI suffix: posh.
Change controller: IETF
Specification document: [[ this document ]]
Related information: Because the "posh." string is merely a Protocols that use POSH will need to register well-known URIs wth the
prefix, protocols that use POSH need to register particular IANA in accordance with [RFC5785] (the IANA registration policy
URIs that are prefixed with the "posh." string. [RFC5226] for well-known URIs is Specification Required).
Note that the registered URI is "posh." (with a trailing dot). This For the sake of consistency, it would be best if the URIs registered
is merely a prefix to be placed at the front of well-known URIs by such protocols match the URI template [RFC6570] path "/.well-
[RFC5785] registered by protocols that use POSH, which themselves are known/posh.{servicedesc}.json"; that is, begin with "posh." and end
responsible for the relevant registrations with the IANA. The URIs with ".json" (indicating a media type of application/json [RFC7159]).
registered by such protocols SHOULD match the URI template [RFC6570]
path "/.well-known/posh.{servicedesc}.json"; that is, begin with
"posh." and end with ".json" (indicating a media type of application/
json [RFC7159]).
For POSH-using protocols that rely on DNS SRV records [RFC2782], the For POSH-using protocols that rely on DNS SRV records [RFC2782], it
"{servicedesc}" part of the well-known URI SHOULD be would be best if the "{servicedesc}" part of the well-known URI is
"{service}.{proto}", where the "{service}" is the DNS SRV "Service" "{service}.{proto}", where the "{service}" is the DNS SRV "Service"
prepended by the underscore character "_" and the "{proto}" is the prepended by the underscore character "_" and the "{proto}" is the
DNS SRV "Proto" also prepended by the underscore character "_". As DNS SRV "Proto" also prepended by the underscore character "_". As
an example, the well-known URI for XMPP server-to-server connections an example, the well-known URI for XMPP server-to-server connections
would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
a service name of "xmpp-server" and uses TCP as the underlying a service name of "xmpp-server" and uses TCP as the underlying
transport protocol. transport protocol.
For other POSH-using protocols, the "{servicedesc}" part of the well- For other POSH-using protocols, the "{servicedesc}" part of the well-
known URI can be any unique string or identifier for the protocol, known URI can be any unique string or identifier for the protocol,
which might be a service name registered with the IANA in accordance which might be a service name registered with the IANA in accordance
with [RFC6335] or which might be an unregistered name. As an with [RFC6335] or which might be an unregistered name. As an
example, the well-known URI for the mythical "foo" service could be example, the well-known URI for a hypothetical "SPICE" application
"posh.foo.json". could be "posh.spice.json".
Note: As explained in [RFC5785], the IANA registration policy 9. IANA Considerations
[RFC5226] for well-known URIs is Specification Required.
9. Security Considerations This document requests no actions of IANA. [Note to RFC Editor:
please remove this section before publication.]
10. Security Considerations
This document supplements but does not supersede the security This document supplements but does not supersede the security
considerations provided in specifications for application protocols considerations provided in specifications for application protocols
that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP).
Specifically, the security of requests and responses sent via HTTPS Specifically, the security of requests and responses sent via HTTPS
depends on checking the identity of the HTTP server in accordance depends on checking the identity of the HTTP server in accordance
with [RFC2818]. Additionally, the security of POSH can benefit from with [RFC2818]. Additionally, the security of POSH can benefit from
other HTTP hardening protocols, such as HSTS [RFC6797] and key other HTTP hardening protocols, such as HSTS [RFC6797] and key
pinning [I-D.ietf-websec-key-pinning], especially if the POSH client pinning [I-D.ietf-websec-key-pinning], especially if the POSH client
shares some information with a common HTTPS implementation (e.g., shares some information with a common HTTPS implementation (e.g.,
skipping to change at page 12, line 12 skipping to change at page 12, line 17
certificate enrollment with a certification authority via HTTPS, as certificate enrollment with a certification authority via HTTPS, as
is done in Enrollment over Secure Transport [RFC7030]. is done in Enrollment over Secure Transport [RFC7030].
A web server at the Source Domain might redirect an HTTPS request to A web server at the Source Domain might redirect an HTTPS request to
another URL. The location provided in the redirect response MUST another URL. The location provided in the redirect response MUST
specify an HTTPS URL. Source domains SHOULD use only temporary specify an HTTPS URL. Source domains SHOULD use only temporary
redirect mechanisms, such as HTTP status codes 302 (Found) and 307 redirect mechanisms, such as HTTP status codes 302 (Found) and 307
(Temporary Redirect). Clients MAY treat any redirect as temporary, (Temporary Redirect). Clients MAY treat any redirect as temporary,
ignoring the specific semantics for 301 (Moved Permanently) and 308 ignoring the specific semantics for 301 (Moved Permanently) and 308
(Permanent Redirect) [RFC7238]. To protect against circular (Permanent Redirect) [RFC7238]. To protect against circular
references, clients MUST NOT follow an infinite number of redirects. references, it is RECOMMENDED that POSH clients follow no more than
It is RECOMMENDED that clients follow no more than 10 redirects, 10 redirects, although applications or implementations can require
although applications or implementations can require that fewer that fewer redirects be followed.
redirects be followed.
Hash function agility is an important quality to ensure secure Hash function agility is an important quality to ensure secure
operations in the face of attacks against the fingerprints obtained operations in the face of attacks against the fingerprints obtained
within verification materials. Because POSH verification materials within verification materials. Because POSH verification materials
are relatively short-lived compared to long-lived credentials such as are 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 files if the entities that deploy POSH are advised to swap out POSH files if the
hash functions in use are found to be subject to realistic attacks. hash functions in use are found to be subject to realistic attacks.
10. References 11. References
10.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, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 13, line 18 skipping to change at page 13, line 18
(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, March 2011.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014. 2014.
10.2. Informative References 11.2. Informative References
[I-D.ietf-dane-srv] [I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA Records Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", draft-ietf-dane-srv-06 (work in with SRV Records", draft-ietf-dane-srv-11 (work in
progress), June 2014. progress), February 2015.
[I-D.ietf-websec-key-pinning] [I-D.ietf-websec-key-pinning]
Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", draft-ietf-websec-key-pinning-14 Extension for HTTP", draft-ietf-websec-key-pinning-21
(work in progress), June 2014. (work in progress), October 2014.
[I-D.ietf-xmpp-dna] [I-D.ietf-xmpp-dna]
Saint-Andre, P. and M. Miller, "Domain Name Associations Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
(DNA) in the Extensible Messaging and Presence Protocol Associations (DNA) in the Extensible Messaging and
(XMPP)", draft-ietf-xmpp-dna-05 (work in progress), Presence Protocol (XMPP)", draft-ietf-xmpp-dna-09 (work in
February 2014. progress), February 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. February 2000.
[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, March 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
 End of changes. 34 change blocks. 
72 lines changed or deleted 69 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/