draft-ietf-sidr-res-certs-19.txt   draft-ietf-sidr-res-certs-20.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: Standards Track R. Loomans Intended status: Standards Track R. Loomans
Expires: April 17, 2011 APNIC Expires: May 12, 2011 APNIC
October 14, 2010 November 8, 2010
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-19 draft-ietf-sidr-res-certs-20
Abstract Abstract
This document defines a standard profile for X.509 certificates for This document defines a standard profile for X.509 certificates for
the purposes of supporting validation of assertions of "right-of-use" the purposes of supporting validation of assertions of "right-of-use"
of Resources (INRs). The certificates issued under this profile are of Resources (INRs). The certificates issued under this profile are
used to convey the Issuer's authorisation of the Subject to be used to convey the Issuer's authorisation of the Subject to be
regarded as the current holder of a "right-of-use" of the INRs that regarded as the current holder of a "right-of-use" of the INRs that
are described in the certificate. This document contains the are described in the certificate. This document contains the
normative specification of Certificate and Certificate Revocation normative specification of Certificate and Certificate Revocation
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 17, 2011. This Internet-Draft will expire on May 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Describing Resources in Certificates . . . . . . . . . . . . . 5 2. Describing Resources in Certificates . . . . . . . . . . . . . 5
3. End-Entity (EE) Certificates and Signing Functions in the 3. End-Entity (EE) Certificates and Signing Functions in the
RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Single-Use EE Certificates . . . . . . . . . . . . . . . . 6
3.2. Multi-Use EE Certificates . . . . . . . . . . . . . . . . 6
4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6 4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 7 4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6
4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7
4.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 4.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8
4.9. Resource Certificate Extensions . . . . . . . . . . . . . 8 4.9. Resource Certificate Extensions . . . . . . . . . . . . . 8
4.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8 4.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8
4.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9 4.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 8
4.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 9 4.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 9
4.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 4.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9
4.9.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9 4.9.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9
4.9.6. CRL Distribution Points . . . . . . . . . . . . . . . 9 4.9.6. CRL Distribution Points . . . . . . . . . . . . . . . 9
4.9.7. Authority Information Access . . . . . . . . . . . . . 10 4.9.7. Authority Information Access . . . . . . . . . . . . . 10
4.9.8. Subject Information Access . . . . . . . . . . . . . . 11 4.9.8. Subject Information Access . . . . . . . . . . . . . . 11
4.9.9. Certificate Policies . . . . . . . . . . . . . . . . . 12 4.9.9. Certificate Policies . . . . . . . . . . . . . . . . . 12
4.9.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12 4.9.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12
4.9.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 13 4.9.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12
5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13 5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13
6. Resource Certificate Requests . . . . . . . . . . . . . . . . 14 6. Resource Certificate Requests . . . . . . . . . . . . . . . . 13
6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14 6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. PKCS#10 Resource Certificate Request Template 6.1.1. PKCS#10 Resource Certificate Request Template
Fields . . . . . . . . . . . . . . . . . . . . . . . . 14 Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. CRMF Resource Certificate Request Template Fields . . 15 6.2.1. CRMF Resource Certificate Request Template Fields . . 15
6.2.2. Resource Certificate Request Control Fields . . . . . 16 6.2.2. Resource Certificate Request Control Fields . . . . . 16
6.3. Certificate Extension Attributes in Certificate 6.3. Certificate Extension Attributes in Certificate
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 16 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Resource Certificate Validation . . . . . . . . . . . . . . . 17 7. Resource Certificate Validation . . . . . . . . . . . . . . . 17
7.1. Resource Extension Validation . . . . . . . . . . . . . . 17 7.1. Resource Extension Validation . . . . . . . . . . . . . . 17
7.2. Resource Certification Path Validation . . . . . . . . . . 18 7.2. Resource Certification Path Validation . . . . . . . . . . 18
8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Example Resource Certificate . . . . . . . . . . . . 25 Appendix A. Example Resource Certificate . . . . . . . . . . . . 24
Appendix B. Example Certificate Revocation List . . . . . . . . . 27 Appendix B. Example Certificate Revocation List . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document defines a standard profile for X.509 certificates This document defines a standard profile for X.509 certificates
[X.509] for use in the context of certification of Internet Number [X.509] for use in the context of certification of Internet Number
Resources (INRs), i.e., IP Addresses and Autonomous System (AS) Resources (INRs), i.e., IP Addresses and Autonomous System (AS)
Numbers. Such certificates are termed "Resource Certificates". A Numbers. Such certificates are termed "Resource Certificates". A
Resource Certificate is a certificate that conforms to the PKIX Resource Certificate is a certificate that conforms to the PKIX
skipping to change at page 5, line 33 skipping to change at page 5, line 33
Delegation or the Autonomous System Identifier Delegation Delegation or the Autonomous System Identifier Delegation
extension, or both. extension, or both.
o These extensions MUST be marked as CRITICAL. o These extensions MUST be marked as CRITICAL.
o The sorted canonical format describing INRs, with maximal spanning o The sorted canonical format describing INRs, with maximal spanning
ranges and maximal spanning prefix masks, as defined in [RFC3779], ranges and maximal spanning prefix masks, as defined in [RFC3779],
MUST be used for the resource extension field, except where the MUST be used for the resource extension field, except where the
"inherit" construct is used instead. "inherit" construct is used instead.
When validating a Resource Certificate, a RP MUST verify that the When validating a Resource Certificate, an RP MUST verify that the
INRs described in the Issuer's Resource Certificate encompass the INRs described in the Issuer's Resource Certificate encompass the
INRs of the Resource Certificate being validated. In this context INRs of the Resource Certificate being validated. In this context
"encompass" allows for the Issuer's INRs to be the same as, or a "encompass" allows for the Issuer's INRs to be the same as, or a
strict superset of the Subject's INRs. strict superset of the Subject's INRs.
3. End-Entity (EE) Certificates and Signing Functions in the RPKI 3. End-Entity (EE) Certificates and Signing Functions in the RPKI
As noted in [ID.sidr-arch], the primary function of End-Entity (EE) As noted in [ID.sidr-arch], the primary function of End-Entity (EE)
certificates in the RPKI is the verification of signed objects that certificates in the RPKI is the verification of signed objects that
relate to the usage of the INRs described in the certificate, e.g., relate to the usage of the INRs described in the certificate, e.g.,
Route Origin Authorizations (ROAs) and manifests. There are two Route Origin Authorizations (ROAs) and manifests.
types of EE certificates defined within the RPKI framework: single-
use and multi-use.
3.1. Single-Use EE Certificates
The private key associated with a "single-use" EE certificate is used The private key associated with an EE certificate is used to sign a
to sign a single RPKI signed object, i.e., the single-use EE single RPKI signed object, i.e., the EE certificate is used to
certificate is used to validate only one object. The certificate is validate only one object. The EE certificate is embedded in the
embedded in the object as part of a Cryptographic Message Syntax object as part of a Cryptographic Message Syntax (CMS) signed data
(CMS) signed data structure [ID.sidr-signed-object].Because of the structure [ID.sidr-signed-object]. Because of the one-to-one
one-to-one relationship between the single-use EE certificate and the relationship between the EE certificate and the signed object,
signed object, revocation of the certificate effectively revokes the revocation of the certificate effectively revokes the corresponding
corresponding signed object. signed object.
3.2. Multi-Use EE Certificates A EE certificate may be used to validate a sequence of signed
objects, were each signed object in the sequence overwrites the
previous instance of the signed object in the repository publication
point, such that only one instance of the signed object is published
at any point in time (e.g., an EE certificate MAY be used to sign a
sequence of manifests [ID.sidr-rpki-manifests]). Such EE
certificates are termed "sequential use" EE certificates.
If the private key associated with an EE certificate is intended to EE certificates used to validate only one instance of a signed
be used to validate more than one RPKI signed object, then the object, and are not used thereafter, or in any other validation
certificate is termed a "multi-use" EE certificate. All objects that context, are termed "one-time-use" EE certificates.
can be verified under a multi-use EE certificate are revoked when the
certificate is revoked.
4. Resource Certificates 4. Resource Certificates
A Resource Certificate is a valid X.509 public key certificate, A Resource Certificate is a valid X.509 public key certificate,
consistent with the PKIX profile [RFC5280], containing the fields consistent with the PKIX profile [RFC5280], containing the fields
listed in this section. Only the differences from [RFC5280] are listed in this section. Only the differences from [RFC5280] are
noted below. noted below.
Unless specifically noted as being OPTIONAL, all the fields listed Unless specifically noted as being OPTIONAL, all the fields listed
here MUST be present, and any other field MUST NOT appear in a here MUST be present, and any other field MUST NOT appear in a
skipping to change at page 7, line 25 skipping to change at page 7, line 20
and MAY contain one instance of the Serial Number attribute. If both and MAY contain one instance of the Serial Number attribute. If both
attributes are present, it is RECOMMENDED that they appear as a set. attributes are present, it is RECOMMENDED that they appear as a set.
The Common Name attribute MUST be encoded as a printable string. The Common Name attribute MUST be encoded as a printable string.
Issuer names are not intended to be descriptive of the identity of Issuer names are not intended to be descriptive of the identity of
Issuer. Issuer.
The RPKI does not rely on Issuer names being globally unique, for The RPKI does not rely on Issuer names being globally unique, for
reasons of security. However, it is RECOMMENDED that Issuer names be reasons of security. However, it is RECOMMENDED that Issuer names be
generated in a fashion that minimizes the likelihood of collisions. generated in a fashion that minimizes the likelihood of collisions.
See Section 8 for (non-normative) suggested name generation See Section 8 for (non-normative) suggested name generation
mechanisms that fulfil this recommendation. mechanisms that fulfill this recommendation.
4.5. Subject 4.5. Subject
The value of this field is a valid X.501 distinguished name, and is The value of this field is a valid X.501 distinguished name, and is
subject to the same constraints as the Issuer name. subject to the same constraints as the Issuer name.
In the RPKI the Subject name is determined by the Issuer, not In the RPKI the Subject name is determined by the Issuer, not
proposed by the subject [ID.sidr-repos-struct]. Each distinct proposed by the subject [ID.sidr-repos-struct]. Each distinct
subordinate CA and EE certified by the Issuer MUST be identified subordinate CA and EE certified by the Issuer MUST be identified
using a Subject name that is unique per Issuer. In this context using a Subject name that is unique per Issuer. In this context
"distinct" is defined as an entity and a given public key. An Issuer "distinct" is defined as an entity and a given public key. An Issuer
SHOULD use a different Subject name if the Subject's key pair has SHOULD use a different Subject name if the Subject's key pair has
changed (i.e., when the CA issues a certificate as part of rekeying changed (i.e., when the CA issues a certificate as part of re-keying
the Subject.) Subject names are not intended to be descriptive of the Subject.) Subject names are not intended to be descriptive of
the identity of Subject. the identity of Subject.
4.6. Valid From 4.6. Valid From
The "Valid From" time SHOULD be no earlier than the time of The "Valid From" time SHOULD be no earlier than the time of
certificate generation. certificate generation.
In the RPKI it is valid for a certificate to have a value for this In the RPKI it is valid for a certificate to have a value for this
field that pre-dates the same field value in any superior field that pre-dates the same field value in any superior
certificate. Relying Parties SHOULD NOT attempt to infer from this certificate. Relying Parties SHOULD NOT attempt to infer from this
time information that a certificate was valid at a time in the past, time information that a certificate was valid at a time in the past,
or will be valid at a time in the future, as the scope of a relying or will be valid at a time in the future, as the scope of an RP's
party's test of validity of a certificate refers specifically to test of validity of a certificate refers specifically to validity at
validity at the current time. the current time.
4.7. Valid To 4.7. Valid To
The Valid To time represents the anticipated lifetime of the current The Valid To time represents the anticipated lifetime of the current
resource allocation or assignment arrangement between the Issuer and resource allocation or assignment arrangement between the Issuer and
the Subject. the Subject.
It is valid for a certificate to have a value for this field that It is valid for a certificate to have a value for this field that
post-dates the same field value in any superior certificate. The post-dates the same field value in any superior certificate. The
same caveats apply to RP's assumptions relating to the certificate's same caveats apply to RP's assumptions relating to the certificate's
skipping to change at page 9, line 17 skipping to change at page 9, line 12
This extension MUST appear in all Resource Certificates. This This extension MUST appear in all Resource Certificates. This
extension is non-critical. extension is non-critical.
The Key Identifier used for resource certificates is the 160-bit The Key Identifier used for resource certificates is the 160-bit
SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
Subject Public Key, as described in Section 4.2.1.2 of [RFC5280]. Subject Public Key, as described in Section 4.2.1.2 of [RFC5280].
4.9.3. Authority Key Identifier 4.9.3. Authority Key Identifier
This extension MUST appear in all Resource Certificates, with the This extension MUST appear in all Resource Certificates, with the
exception of a CA who issues a "self-signed" certificate. The exception of a CA who issues a "self-signed" certificate. In a self-
authorityCertIssuer and authorityCertSerialNumber fields MUST NOT be signed certificate, a CA MAY include this extension, and set it equal
present. This extension is non-critical. to the Subject Key Identifier. The authorityCertIssuer and
authorityCertSerialNumber fields MUST NOT be present. This extension
is non-critical.
The Key Identifier used for resource certificates is the 160-bit The Key Identifier used for resource certificates is the 160-bit
SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
Issuer's public key, as described in Section 4.2.1.1 of [RFC5280]. Issuer's public key, as described in Section 4.2.1.1 of [RFC5280].
4.9.4. Key Usage 4.9.4. Key Usage
This extension is a critical extension and MUST be present. This extension is a critical extension and MUST be present.
In certificates issued to Certification Authorities only the In certificates issued to Certification Authorities only the
skipping to change at page 11, line 14 skipping to change at page 11, line 11
subordinate to the re-issued (CA) certificate can maintain a constant subordinate to the re-issued (CA) certificate can maintain a constant
Authority Information Access (AIA) extension pointer and thus need Authority Information Access (AIA) extension pointer and thus need
not be re-issued when the parent certificate is re-issued. not be re-issued when the parent certificate is re-issued.
4.9.8. Subject Information Access 4.9.8. Subject Information Access
In the context of the RPKI, this extension (SIA) identifies the In the context of the RPKI, this extension (SIA) identifies the
publication point of products signed by the Subject of the publication point of products signed by the Subject of the
certificate. certificate.
4.9.8.1. SIA for CAs 4.9.8.1. SIA for CA Certificates
This extension MUST be present, and is non-critical. This extension MUST be present, and is non-critical.
This extension MUST have an instance of an accessMethod of id-ad- This extension MUST have an instance of an accessMethod of id-ad-
caRepository, with an accessLocation form of a URI that MUST specify caRepository, with an accessLocation form of a URI that MUST specify
an RSYNC URI [RFC5781]. This URI points to the directory containing an RSYNC URI [RFC5781]. This URI points to the directory containing
all material issued by this CA. i.e., all valid CA certificates, all published material issued by this CA. i.e., all valid CA
multi-use EE certificates, the current CRL, manifest and signed certificates, published EE certificates, the current CRL, manifest
objects signed by single-use EE certificates that have been issued by and signed objects validated via EE certificates that have been
this CA [ID.sidr-repos-struct]. Other accessDescription elements issued by this CA [ID.sidr-repos-struct]. Other accessDescription
with an accessMethod of id-ad-caRepository MAY be present. In such elements with an accessMethod of id-ad-caRepository MAY be present.
cases, the accessLocation values describe alternate supported URI In such cases, the accessLocation values describe alternate supported
access mechanisms for the same directory. The ordering of URIs in URI access mechanisms for the same directory. The ordering of URIs
this accessDescription sequence reflect the CA's relative preferences in this accessDescription sequence reflect the CA's relative
for access methods to be used by relying parties, with he first preferences for access methods to be used by RPs, with he first
element of the sequence being the most preferred by the CA. element of the sequence being the most preferred by the CA.
This extension MUST have an instance of an AccessDescription with an This extension MUST have an instance of an AccessDescription with an
accessMethod of id-ad-rpkiManifest, accessMethod of id-ad-rpkiManifest,
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }
with an RSYNC URI [RFC5781] form of accessLocation. The URI points with an RSYNC URI [RFC5781] form of accessLocation. The URI points
to the CA's manifest of published objects [ID.sidr-rpki-manifests] as to the CA's manifest of published objects [ID.sidr-rpki-manifests] as
an object URL. Other accessDescription elements MAY exist for the an object URL. Other accessDescription elements MAY exist for the
id-ad-rpkiManifest accessMethod, where the accessLocation value id-ad-rpkiManifest accessMethod, where the accessLocation value
indicates alternate access mechanisms for the same manifest object. indicates alternate access mechanisms for the same manifest object.
4.9.8.2. SIA for Multi-use EEs 4.9.8.2. SIA for EE Certificates
This extension MUST be present, and is non-critical.
This extension MUST have an instance of an accessMethod of id-ad-
signedObjectRepository,
id-ad-signedObjectRepository OBJECT IDENTIFIER ::= { id-ad 9 }
with an accessLocation form of a URI that MUST specify an RSYNC URI
[RFC5781]. This URI points to the directory containing all signed
objects that are verified using this EE certificate
[ID.sidr-repos-struct]. Other accessDescription elements MAY exist
for the id-ad-signedObjectRepository accessMethod, where the
accessLocation value indicates alternate supported access mechanisms
for the same directory, ordered in terms of the EE's relative
preference for supported access mechanisms.
This extension MUST have an instance of an AccessDescription with an
accessMethod of id-ad-rpkiManifest, with the same specification as
the CA's manifest.
4.9.8.3. SIA for Single-use EEs
This extension MUST be present, and is non-critical. This extension MUST be present, and is non-critical.
This extension MUST have an instance of an accessMethod of id-ad- This extension MUST have an instance of an accessMethod of id-ad-
signedObject, signedObject,
id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }
with an accessLocation form of a URI that MUST include a RSYNC URI with an accessLocation form of a URI that MUST include an RSYNC URI
[RFC5781]. This URI points to the signed object that is verified [RFC5781]. This URI points to the signed object that is verified
using this EE certificate [ID.sidr-repos-struct]. Other using this EE certificate [ID.sidr-repos-struct]. Other
accessDescription elements may exist for the id-ad-signedObject accessDescription elements may exist for the id-ad-signedObject
accessMethod, where the accessLocation value indicates alternate URI accessMethod, where the accessLocation value indicates alternate URI
access mechanisms for the same object, ordered in terms of the EE's access mechanisms for the same object, ordered in terms of the EE's
relative preference for supported access mechanisms. relative preference for supported access mechanisms.
Other AccessMethods MUST NOT be used for a single-use EE's SIA. Other AccessMethods MUST NOT be used for an EE certificates's SIA.
4.9.9. Certificate Policies 4.9.9. Certificate Policies
This extension MUST be present, and MUST be marked critical. It MUST This extension MUST be present, and MUST be marked critical. It MUST
include exactly one policy, as specified in the RPKI CP [ID.sidr-cp] include exactly one policy, as specified in the RPKI CP [ID.sidr-cp]
4.9.10. IP Resources 4.9.10. IP Resources
Either the IP Resources extension, or the AS Resources extension, or Either the IP Resources extension, or the AS Resources extension, or
both, MUST be present in all RPKI certificates, and if present, MUST both, MUST be present in all RPKI certificates, and if present, MUST
skipping to change at page 14, line 17 skipping to change at page 13, line 42
NOT be present. No CRL entry extensions are supported in this NOT be present. No CRL entry extensions are supported in this
profile, and CRL entry extensions MUST NOT be present in a CRL. profile, and CRL entry extensions MUST NOT be present in a CRL.
6. Resource Certificate Requests 6. Resource Certificate Requests
A resource certificate request MAY use either of PKCS#10 or A resource certificate request MAY use either of PKCS#10 or
Certificate Request Message Format (CRMF). A CA MUST support Certificate Request Message Format (CRMF). A CA MUST support
certificate issuance in PKCS#10 and a CA MAY support CRMF requests. certificate issuance in PKCS#10 and a CA MAY support CRMF requests.
Note that there is no certificate response defined in this profile. Note that there is no certificate response defined in this profile.
For CA certificate and multi-use EE certificate requests, the CA For CA certificate requests, the CA places the Resource Certificate
places the Resource Certificate in the repository, as per in the repository, as per [ID.sidr-cp]. No response is defined for
[ID.sidr-cp]. No response is defined for single-use EE Certificate EE Certificate requests.
requests.
6.1. PCKS#10 Profile 6.1. PCKS#10 Profile
This profile refines the specification in [RFC2986], as it relates to This profile refines the specification in [RFC2986], as it relates to
Resource Certificates. A Certificate Request Message object, Resource Certificates. A Certificate Request Message object,
formatted according to PKCS#10, is passed to a CA as the initial step formatted according to PKCS#10, is passed to a CA as the initial step
in issuing a certificate. in issuing a certificate.
With the exception of the SubjectPublicKeyinfo and the SIA extension With the exception of the SubjectPublicKeyinfo and the SIA extension
request, the CA is permitted to alter any field in the request when request, the CA is permitted to alter any field in the request when
skipping to change at page 20, line 14 skipping to change at page 19, line 37
A certificate validation algorithm MAY perform these tests in any A certificate validation algorithm MAY perform these tests in any
chosen order. chosen order.
Certificates and CRLs used in this process MAY be found in a locally Certificates and CRLs used in this process MAY be found in a locally
maintained cache, maintained by a regular synchronisation across the maintained cache, maintained by a regular synchronisation across the
distributed publication repository structure [ID.sidr-repos-struct]. distributed publication repository structure [ID.sidr-repos-struct].
There exists the possibility of encountering certificate paths that There exists the possibility of encountering certificate paths that
are arbitrarily long, or attempting to generate paths with loops as are arbitrarily long, or attempting to generate paths with loops as
means of creating a potential DOS attack on a RP. A RP executing means of creating a potential DOS attack on an RP. A RP executing
this procedure MAY apply further heuristics to guide halting the this procedure MAY apply further heuristics to guide halting the
certification path validation process in order to avoid some of the certification path validation process in order to avoid some of the
issues associated with attempts to validate such malformed issues associated with attempts to validate such malformed
certification path structures. Implementations of Resource certification path structures. Implementations of Resource
Certificate validation MAY halt with a validation failure if the Certificate validation MAY halt with a validation failure if the
certification path length exceeds a locally defined configuration certification path length exceeds a locally defined configuration
parameter. parameter.
8. Design Notes 8. Design Notes
skipping to change at page 23, line 7 skipping to change at page 22, line 27
A Resource Certificate PKI cannot in and of itself resolve any forms A Resource Certificate PKI cannot in and of itself resolve any forms
of ambiguity relating to uniqueness of assertions of rights of use in of ambiguity relating to uniqueness of assertions of rights of use in
the event that two or more valid certificates encompass the same the event that two or more valid certificates encompass the same
resource. If the issuance of resource certificates is aligned to the resource. If the issuance of resource certificates is aligned to the
status of resource allocations and assignments then the information status of resource allocations and assignments then the information
conveyed in a certificate is no better than the information in the conveyed in a certificate is no better than the information in the
allocation and assignment databases. allocation and assignment databases.
This profile requires that the key used to sign an issued certificate This profile requires that the key used to sign an issued certificate
is the same key used to sign the CRL that can revoke the certificate, is the same key used to sign the CRL that can revoke the certificate,
implying that the certificate path used to validate a signature on a implying that the certification path used to validate the signature
certificates is the same as that used to validate a signatures the on a certificate is the same as that used to validate the signature
CRL that revokes the certificate. It is noted that this is a higher of the CRL that can revoke the certificate. It is noted that this is
constraint than required in X.509 PKIs, and there may be a risk in a higher constraint than required in X.509 PKIs, and there may be a
using a path validation implementation that is capable of using risk in using a path validation implementation that is capable of
separate validation paths for a certificate and the corresponding using separate validation paths for a certificate and the
CRL. If there are subject name collisions in the RPKI as a result of corresponding CRL. If there are subject name collisions in the RPKI
CAs not following the guidelines provided here relating to ensuring as a result of CAs not following the guidelines provided here
sufficient entropy in constructing subject names, and this is relating to ensuring sufficient entropy in constructing subject
combined with the situation that an RP uses an implementation of names, and this is combined with the situation that an RP uses an
validation path construction that is not in conformance with this implementation of validation path construction that is not in
RPKI profile, then it is possible that the subject name collisions conformance with this RPKI profile, then it is possible that the
can cause an RP to conclude that an otherwise valid certificate has subject name collisions can cause an RP to conclude that an otherwise
been revoked. valid certificate has been revoked.
10. IANA Considerations 10. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA [Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this document.] considerations stated in this document.]
11. Acknowledgements 11. Acknowledgements
The authors would like to particularly acknowledge the valued The authors would like to particularly acknowledge the valued
contribution from Stephen Kent in reviewing this document and contribution from Stephen Kent in reviewing this document and
skipping to change at page 24, line 40 skipping to change at page 24, line 18
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", Work in progress: Internet Secure Internet Routing", Work in progress: Internet
Drafts draft-ietf-sidr-arch-04.txt, November 2008. Drafts draft-ietf-sidr-arch-04.txt, November 2008.
[ID.sidr-keyroll] [ID.sidr-keyroll]
Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in
progress), October 2010. progress), October 2010.
[ID.sidr-repos-struct] [ID.sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaleson, "A Profile for Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-04.txt (work in progress), draft-ietf-sidr-repos-struct-04.txt (work in progress),
May 2010. May 2010.
[ID.sidr-rpki-manifests] [ID.sidr-rpki-manifests]
Austein, R., Huston, G., Kent, S., and M. Lepinski, Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure", "Manifests for the Resource Public Key Infrastructure",
Work in progress: Internet Work in progress: Internet
Drafts draft-ietf-sidr-rpki-manifests-04.txt, Drafts draft-ietf-sidr-rpki-manifests-04.txt,
October 2008. October 2008.
 End of changes. 30 change blocks. 
97 lines changed or deleted 75 lines changed or added

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