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/ |