draft-ietf-sidr-rfc6490-bis-03.txt   draft-ietf-sidr-rfc6490-bis-04.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft APNIC Internet-Draft APNIC
Obsoletes: 6490 (if approved) S. Weiler Obsoletes: 6490 (if approved) S. Weiler
Intended status: Standards Track Parsons Intended status: Standards Track Parsons
Expires: September 30, 2015 G. Michaelson Expires: November 16, 2015 G. Michaelson
APNIC APNIC
S. Kent S. Kent
BBN BBN
March 29, 2015 May 15, 2015
Resource Certificate PKI (RPKI) Trust Anchor Locator Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
draft-ietf-sidr-rfc6490-bis-03 draft-ietf-sidr-rfc6490-bis-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
Certificate Public Key Infrastructure (RPKI). This document Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by
obsoletes RFC 6490 by adding support for multiple URIs in a TAL. adding support for multiple 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 30, 2015. This Internet-Draft will expire on November 16, 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 3, line 8 skipping to change at page 3, line 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
This document defines a Trust Anchor Locator (TAL) for the Resource This document defines a Trust Anchor Locator (TAL) for the Resource
Certificate Public Key Infrastructure (RPKI) [RFC6480]. This format Public Key Infrastructure (RPKI) [RFC6480]. This format may be used
may be used to distribute trust anchor material using a mix of out- to distribute trust anchor material using a mix of out-of-band and
of-band and online means. Procedures used by Relying Parties (RPs) online means. Procedures used by Relying Parties (RPs) to verify
to verify RPKI signed objects SHOULD support this format to RPKI signed objects SHOULD support this format to facilitate
facilitate interoperability between creators of trust anchor material interoperability between creators of trust anchor material and RPs.
and RPs. This document obsoletes RFC 6490 by adding support for This document obsoletes RFC 6490 by adding support for multiple URIs
multiple URIs in a TAL. in a TAL.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Trust Anchor Locator 2. Trust Anchor Locator
2.1. Trust Anchor Locator Format 2.1. Trust Anchor Locator Format
This document does not propose a new format for trust anchor This document does not propose a new format for trust anchor
material. A trust anchor in the RPKI is represented by a self-signed material. A trust anchor in the RPKI is represented by a self-signed
X.509 Certificate Authority (CA), a format commonly used in PKIs and X.509 Certification Authority (CA) certificate, a format commonly
widely supported by RP software. This document specifies a format used in PKIs and widely supported by RP software. This document
for data used to retrieve and verify the authenticity of a trust specifies a format for data used to retrieve and verify the
anchor in a very simple fashion. That data is referred to as the authenticity of a trust anchor in a very simple fashion. That data
TAL. is referred to as the TAL.
The motivation for defining the TAL is to enable selected data in the The motivation for defining the TAL is to enable selected data in the
trust anchor to change, without needing to effect re-distribution of trust anchor to change, without needing to effect redistribution of
the trust anchor per se. In the RPKI, certificates contain the trust anchor per se. In the RPKI, certificates contain
extensions that represent Internet Number Resources (INRs) [RFC3779]. extensions that represent Internet Number Resources (INRs) [RFC3779].
The set of INRs associated with an entity acting as a trust anchor is The set of INRs associated with an entity acting as a trust anchor is
likely to change over time. Thus, if one were to use the common PKI likely to change over time. Thus, if one were to use the common PKI
convention of distributing a trust anchor to RPs in a secure fashion, convention of distributing a trust anchor to RPs in a secure fashion
this procedure would need to be repeated whenever the INR set for the then this procedure would need to be repeated whenever the INR set
entity acting as a trust anchor changed. By distributing the TAL (in for the entity acting as a trust anchor changed. By distributing the
a secure fashion), instead of the trust anchor, this problem is TAL (in a secure fashion), instead of distributing the trust anchor,
avoided, i.e., the TAL is constant so long as the TA's public key and this problem is avoided, i.e., the TAL is constant so long as the
its location does not change. trust anchor's public key and its location do not change.
The TAL is analogous to the TrustAnchorInfo data structure [RFC5914] The TAL is analogous to the TrustAnchorInfo data structure [RFC5914]
adopted as a PKIX standard. That standard could be used to represent adopted as a PKIX standard. That standard could be used to represent
the TAL, if one defined an rsync URI extension for that data the TAL, if one defined an rsync URI extension for that data
structure. However, the TAL format was adopted by RPKI implementors structure. However, the TAL format was adopted by RPKI implementors
prior to the PKIX trust anchor work, and the RPKI implementer prior to the PKIX trust anchor work, and the RPKI implementer
community has elected to utilize the TAL format, rather than define community has elected to utilize the TAL format, rather than define
the requisite extension. The community also prefers the simplicity the requisite extension. The community also prefers the simplicity
of the ASCII encoding of the TAL, vs. the binary (ASN.1) encoding for of the ASCII encoding of the TAL, versus the binary (ASN.1) encoding
TrustAnchorInfo. for TrustAnchorInfo.
The TAL is an ordered sequence of: The TAL is an ordered sequence of:
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], 3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
encoded in Base64 (see Section 4 of [RFC4648]. encoded in Base64 (see Section 4 of [RFC4648].
skipping to change at page 4, line 36 skipping to change at page 4, line 36
Each rsync URI in the TAL MUST reference a single object. It MUST Each rsync URI in the TAL MUST reference a single object. It MUST
NOT reference a directory or any other form of collection of objects. NOT 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
is the trust anchor in certification path discovery [RFC4158] and is the trust anchor in certification path discovery [RFC4158] and
validation [RFC5280][RFC3779]. validation [RFC5280][RFC3779].
The validity interval of this trust anchor SHOULD reflect the The validity interval of this trust anchor SHOULD reflect the
anticipated period of stability the particular set of Internet Number anticipated period of stability of the particular set of INRs that
Resources (INRs) that are associated with the putative TA. are associated with the putative trust anchor.
The INR extension(s) of this trust anchor MUST contain a non-empty The INR extension(s) of this trust anchor MUST contain a non-empty
set of number resources. It MUST NOT use the "inherit" form of the set of number resources. It MUST NOT use the "inherit" form of the
INR extension(s). The INR set described in this certificate is the INR extension(s). The INR set described in this certificate is the
set of number resources for which the issuing entity is offering set of number resources for which the issuing entity is offering
itself as a putative trust anchor in the RPKI [RFC6480]. itself as a putative trust anchor in the RPKI [RFC6480].
The public key used to verify the trust anchor MUST be the same as The public key used to verify the trust anchor MUST be the same as
the subjectPublicKeyInfo in the CA certificate and in the TAL. the subjectPublicKeyInfo in the CA certificate and in the TAL.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
for any reason other than a key change. for any reason other than a key change.
Because the public key in the TAL and the trust anchor MUST be Because the public key in the TAL and the trust anchor MUST be
stable, this motivates operation of that CA in an off-line mode. stable, this motivates operation of that CA in an off-line mode.
Thus the entity that issues the trust anchor SHOULD issue a Thus the entity that issues the trust anchor SHOULD issue a
subordinate CA certificate that contains the same INRs (via the use subordinate CA certificate that contains the same INRs (via the use
of the "inherit" option in the INR extensions of the subordinate of the "inherit" option in the INR extensions of the subordinate
certificate). This allows the entity that issues the trust anchor to certificate). This allows the entity that issues the trust anchor to
keep the corresponding private key of this certificate off-line, keep the corresponding private key of this certificate off-line,
while issuing all relevant child certificates under the immediate while issuing all relevant child certificates under the immediate
subordinate CA. This measure also allows the CRL issued by that subordinate CA. This measure also allows the Certificate Revocation
entity to be used to revoke the subordinate (CA) certificate in the List (CRL) issued by that entity to be used to revoke the subordinate
event of suspected key compromise of this potentially more vulnerable CA certificate in the event of suspected key compromise of this
online operational key pair. potentially more vulnerable online operational key pair.
The trust anchor MUST be published at a stable URI. When the trust The trust anchor MUST be published at a stable URI. When the trust
anchor is re-issued for any reason, the replacement CA certificate anchor is reissued for any reason, the replacement CA certificate
MUST be accessible using the same URI. MUST be accessible using the same URI.
Because the trust anchor is a self-signed certificate, there is no Because the trust anchor is a self-signed certificate, there is no
corresponding Certificate Revocation List that can be used to revoke corresponding CRL that can be used to revoke it, nor is there a
it, nor is there a manifest [RFC6486] that lists this certificate. manifest [RFC6486] that lists this certificate.
If an entity wishes to withdraw a self-signed CA certificate as a If an entity wishes to withdraw a self-signed CA certificate as a
putative Trust Anchor, for any reason, including key rollover, the putative trust anchor, for any reason, including key rollover, the
entity MUST remove the object from the location referenced in the entity MUST remove the object from the location referenced in the
TAL. TAL.
Where the TAL contains two or more rsync URIs, then the same self- Where the TAL contains two or more rsync URIs, then the same self-
signed CA certificate MUST be found at each referenced location. In signed CA certificate MUST be found at each referenced location. In
order to operational increase resilience, it is RECOMMENDED that the order to operational increase resilience, it is RECOMMENDED that the
domain name parts of each of these URIs resolve to distinct IP domain name parts of each of these URIs resolve to distinct IP
addresses that are used by a diverse set of repository publication addresses that are used by a diverse set of repository publication
points, and these IP addresses be included in distinct Route points, and these IP addresses be included in distinct Route
Origination Authorizations (ROAs) objects signed by different CAs. Origination Authorizations (ROAs) objects signed by different CAs.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB
3. Relying Party Use 3. Relying Party Use
In order to use the TAL to retrieve and validate a (putative) TA, an In order to use the TAL to retrieve and validate a (putative) trust
RP SHOULD: anchor, an RP SHOULD:
1. Retrieve the object referenced by (one of) the URI(s) contained 1. Retrieve the object referenced by (one of) the URI(s) contained
in the TAL. in the TAL.
2. Confirm that the retrieved object is a current, self-signed RPKI 2. Confirm that the retrieved object is a current, self-signed RPKI
CA certificate that conforms to the profile as specified in CA certificate that conforms to the profile as specified in
[RFC6487]. [RFC6487].
3. Confirm that the public key in the TAL matches the public key in 3. Confirm that the public key in the TAL matches the public key in
the retrieved object. the retrieved object.
4. Perform other checks, as deemed appropriate (locally), to ensure 4. Perform other checks, as deemed appropriate (locally), to ensure
that the RP is willing to accept the entity publishing this self- that the RP is willing to accept the entity publishing this self-
signed CA certificate to be a trust anchor, relating to the signed CA certificate to be a trust anchor. These test apply to
validity of attestations made in the context of the RPKI the validity of attestations made in the context of the RPKI
(relating to all resources described in the INR extension of this relating to all resources described in the INR extension of this
certificate). certificate.
An RP SHOULD perform these functions for each instance of TAL that it An RP SHOULD perform these functions for each instance of TAL that it
is holding for this purpose every time the RP performs a re- is holding for this purpose every time the RP performs a re-
synchronization across the local repository cache. In any case, an synchronization across the local repository cache. In any case, an
RP also SHOULD perform these functions prior to the expiration of the RP also SHOULD perform these functions prior to the expiration of the
locally cached copy of the retrieved trust anchor referenced by the locally cached copy of the retrieved trust anchor referenced by the
TAL. TAL.
In the case where a TAL contains multiple URIs, an RP MAY use a In the case where a TAL contains multiple URIs, an RP MAY use a
locally defined preference rule to select the URI to retrieve the locally defined preference rule to select the URI to retrieve the
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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. Security Considerations 4. Security Considerations
Compromise of a trust anchor private key permits unauthorized parties Compromise of a trust anchor private key permits unauthorized parties
to masquerade as a trust anchor, with potentially severe to masquerade as a trust anchor, with potentially severe
consequences. Reliance on an inappropriate or incorrect trust anchor consequences. Reliance on an inappropriate or incorrect trust anchor
has similar potentially severe consequences. has similar potentially severe consequences.
This trust anchor locator does not directly provide a list of This TAL does not directly provide a list of resources covered by the
resources covered by the referenced self-signed CA certificate. referenced self-signed CA certificate. Instead, the RP is referred
Instead, the RP is referred to the trust anchor itself and the INR to the trust anchor itself and the INR extension(s) within this
extension(s) within this certificate. This provides necessary certificate. This provides necessary operational flexibility, but it
operational flexibility, but it also allows the certificate issuer to also allows the certificate issuer to claim to be authoritative for
claim to be authoritative for any resource. Relying parties should any resource. Relying parties should either have great confidence in
either have great confidence in the issuers of such certificates that the issuers of such certificates that they are configuring as trust
they are configuring as trust anchors, or they should issue their own anchors, or they should issue their own self-signed certificate as a
self-signed certificate as a trust anchor and, in doing so, impose trust anchor and, in doing so, impose constraints on the subordinate
constraints on the subordinate certificates. certificates.
5. IANA Considerations 5. IANA Considerations
[This document specifies no IANA actions.] [This document specifies no IANA actions.]
6. Acknowledgments 6. Acknowledgments
This approach to TA material was originally described by Robert This approach to trust anchor material was originally described by
Kisteleki. Robert Kisteleki.
The authors acknowledge the contributions of Rob Austein and Randy The authors acknowledge the contributions of Rob Austein and Randy
Bush, who assisted with earlier versions of this document and with Bush, who assisted with drafting this document and with helpful
helpful review comments. review comments.
The authors acknowledge with work of Roque Gagliano, Terry Manderson The authors acknowledge with work of Roque Gagliano, Terry Manderson
and Carlos Martinez Cagnazzo in developing the ideas behind the and Carlos Martinez Cagnazzo in developing the ideas behind the
inclusion of multiple URIs in the TAL. inclusion of multiple URIs in the TAL.
7. References 7. References
7.1. Normative References 7.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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
URI: http://www.apnic.net URI: http://www.apnic.net
Samuel Weiler Samuel Weiler
Parsons Parsons
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, Maryland 21046 Columbia, Maryland 21046
USA USA
Email: weiler@tislabs.com Email: weiler@tislabs.com
George Michaelson George Michaelson
Asia Pacific Network Information Centre APNIC
Email: ggm@apnic.net Email: ggm@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
USA USA
 End of changes. 21 change blocks. 
59 lines changed or deleted 59 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/