draft-ietf-sidrops-https-tal-03.txt   draft-ietf-sidrops-https-tal-04.txt 
Network Working Group G. Huston Network Working Group G. Huston
Internet-Draft APNIC Internet-Draft APNIC
Obsoletes: 7730 (if approved) S. Weiler Obsoletes: 7730 (if approved) S. Weiler
Intended status: Standards Track W3C/MIT Intended status: Standards Track W3C/MIT
Expires: December 10, 2018 G. Michaelson Expires: January 27, 2019 G. Michaelson
APNIC APNIC
S. Kent S. Kent
Unaffiliated Unaffiliated
T. Bruijnzeels T. Bruijnzeels
NLnet Labs NLnet Labs
June 8, 2018 July 26, 2018
Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
draft-ietf-sidrops-https-tal-03 draft-ietf-sidrops-https-tal-04
Abstract Abstract
This document defines a Trust Anchor Locator (TAL) for the Resource This document defines a Trust Anchor Locator (TAL) for the Resource
Public Key Infrastructure (RPKI). This document obsoletes RFC 7730 Public Key Infrastructure (RPKI). This document obsoletes RFC 7730
by adding support for HTTPS URIs in a TAL. by adding support for HTTPS URIs in a TAL.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 10, 2018. This Internet-Draft will expire on January 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 42 skipping to change at page 3, line 42
1. a URI section, 1. a URI section,
2. a "<CRLF>" or "<LF>" line break, 2. a "<CRLF>" or "<LF>" line break,
3. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded 3. a subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded
in Base64 (see Section 4 of [RFC4648]). To avoid long lines, in Base64 (see Section 4 of [RFC4648]). To avoid long lines,
"<CRLF>" or "<LF>" line breaks MAY be inserted into the "<CRLF>" or "<LF>" line breaks MAY be inserted into the
Base64-encoded string. Base64-encoded string.
where the URI section is comprised of one of more of the ordered where the URI section is comprised or one of more of the ordered
sequence of: sequence of:
1.1. an rsync URI [RFC5781], or an HTTPS URI [RFC7230] 1.1. either an rsync URI [RFC5781], or an HTTPS URI [RFC7230]
1.2. a "<CRLF>" or "<LF>" line break. 1.2. a "<CRLF>" or "<LF>" line break.
2.2. TAL and Trust Anchor Certificate Considerations 2.2. TAL and Trust Anchor Certificate Considerations
Each URI in the TAL MUST reference a single object. It MUST NOT Each URI in the TAL MUST reference a single object. It MUST NOT
reference a directory or any other form of collection of objects. reference a directory or any other form of collection of objects.
The referenced object MUST be a self-signed CA certificate that The referenced object MUST be a self-signed CA certificate that
conforms to the RPKI certificate profile [RFC6487]. This certificate conforms to the RPKI certificate profile [RFC6487]. This certificate
skipping to change at page 6, line 33 skipping to change at page 6, line 33
If the connection to the preferred URI fails, or the retrieved CA If the connection to the preferred URI fails, or the retrieved CA
certificate public key does not match the TAL public key, the RP certificate public key does not match the TAL public key, the RP
SHOULD retrieve the CA certificate from the next URI, according to SHOULD retrieve the CA certificate from the next URI, according to
the local preference ranking of URIs. the local preference ranking of URIs.
4. HTTPS Considerations 4. HTTPS Considerations
Note that a Man in the Middle (MITM) cannot produce a CA certificate Note that a Man in the Middle (MITM) cannot produce a CA certificate
that would be considered valid according to the process described in that would be considered valid according to the process described in
Section 3. However, a MITM can perform withhold or replay attacks Section 3. However, a MITM attack can be performed to prevent the
targeting a Relying Party and keep the Relying Party from learning Relying Party from learning about an updated CA certificate. Because
about an update CA certificate. Because of this, Relying Parties of this, Relying Parties SHOULD do TLS certificate and host name
SHOULD do TLS certificate and host name validation when they fetch a validation when they fetch a CA certificate using an HTTPS URI on a
CA certificate using an HTTPS URI on a TAL. TAL.
Relying Party tools SHOULD log any TLS certificate or host name Relying Party tools SHOULD log any TLS certificate or host name
validation issues found, so that an operator can investigate the validation issues found, so that an operator can investigate the
cause. However, such validation issues are often due to cause. However, such validation issues are often due to
configuration errors or a lack of a common TLS trust anchor. In configuration errors or a lack of a common TLS trust anchor. In
these cases, it is better if the Relying Party retrieves the CA these cases, it is better if the Relying Party retrieves the CA
certificate regardless and performs validation on it. Therefore, the certificate regardless and performs validation on it. Therefore, the
Relying Party MUST continue to retrieve the data in case of errors. Relying Party MUST continue to retrieve the data in case of errors.
It is RECOMMENDED that Relying Parties and Repository Servers follow It is RECOMMENDED that Relying Parties and Repository Servers follow
 End of changes. 7 change blocks. 
11 lines changed or deleted 11 lines changed or added

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