< draft-ietf-sidr-res-certs-09.txt   draft-ietf-sidr-res-certs-10.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: May 17, 2008 APNIC Expires: December 19, 2008 APNIC
November 14, 2007 June 17, 2008
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-09.txt draft-ietf-sidr-res-certs-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 17, 2008. This Internet-Draft will expire on December 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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-to-use" the purposes of supporting validation of assertions of "right-to-use"
of an Internet Number Resource (IP Addresses and Autonomous System of an Internet Number Resource (IP Addresses and Autonomous System
Numbers). This profile is used to convey the issuer's authorization Numbers). This profile is used to convey the issuer's authorization
of the subject to be regarded as the current holder of a "right-of- of the subject to be regarded as the current holder of a "right-of-
use" of the IP addresses and AS numbers that are described in the use" of the IP addresses and AS numbers that are described in the
issued certificate. issued certificate.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2. Describing Resources in Certificates . . . . . . . . . . . . . 5 2. Describing Resources in Certificates . . . . . . . . . . . . . 5
3. Resource Certificate Fields . . . . . . . . . . . . . . . . . 6 3. Resource Certificate Fields . . . . . . . . . . . . . . . . . 6
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Serial number . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6 3.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6
3.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Valid From . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7. Valid To . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8 3.8. Subject Public Key Info . . . . . . . . . . . . . . . . . 8
3.9. Resource Certificate Version 3 Extension Fields . . . . . 9 3.9. Resource Certificate Version 3 Extension Fields . . . . . 8
3.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 9 3.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 9
3.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9 3.9.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9
3.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 10 3.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 9
3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 10 3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 10
3.9.5. CRL Distribution Points . . . . . . . . . . . . . . . 10 3.9.5. CRL Distribution Points . . . . . . . . . . . . . . . 10
3.9.6. Authority Information Access . . . . . . . . . . . . . 11 3.9.6. Authority Information Access . . . . . . . . . . . . . 11
3.9.7. Subject Information Access . . . . . . . . . . . . . . 12 3.9.7. Subject Information Access . . . . . . . . . . . . . . 11
3.9.8. Certificate Policies . . . . . . . . . . . . . . . . . 13 3.9.8. Certificate Policies . . . . . . . . . . . . . . . . . 13
3.9.9. IP Resources . . . . . . . . . . . . . . . . . . . . . 13 3.9.9. IP Resources . . . . . . . . . . . . . . . . . . . . . 13
3.9.10. AS Resources . . . . . . . . . . . . . . . . . . . . . 13 3.9.10. AS Resources . . . . . . . . . . . . . . . . . . . . . 13
4. Resource Certificate Revocation List Profile . . . . . . . . . 14 4. Resource Certificate Revocation List Profile . . . . . . . . . 14
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 15
4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 15 4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 15
4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 15 4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 15
4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 15 4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 15
4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 15 4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 15
4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 15 4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 15
4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 16 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 16
5. Manifest Profile . . . . . . . . . . . . . . . . . . . . . . . 16 5. Resource Certificate Request Profile . . . . . . . . . . . . . 16
6. Resource Certificate Request Profile . . . . . . . . . . . . . 16 5.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 16
6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. PKCS#10 Resource Certificate Request Template
6.1.1. PKCS#10 Resource Certificate Request Template
Fields . . . . . . . . . . . . . . . . . . . . . . . . 16 Fields . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. CRMF Resource Certificate Request Template Fields . . 18 5.2.1. CRMF Resource Certificate Request Template Fields . . 18
6.2.2. Resource Certificate Request Control Fields . . . . . 19 5.2.2. Resource Certificate Request Control Fields . . . . . 19
6.3. Certificate Extension Attributes in Certificate 5.3. Certificate Extension Attributes in Certificate
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Resource Certificate Validation . . . . . . . . . . . . . . . 21 6. Resource Certificate Validation . . . . . . . . . . . . . . . 21
7.1. Trust Anchors for Resource Certificates . . . . . . . . . 21 6.1. Trust Anchors for Resource Certificates . . . . . . . . . 21
7.2. Resource Extension Validation . . . . . . . . . . . . . . 22 6.2. Resource Extension Validation . . . . . . . . . . . . . . 22
7.3. Resource Certificate Path Validation . . . . . . . . . . . 23 6.3. Resource Certificate Path Validation . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Example Resource Certificate . . . . . . . . . . . . 26 Appendix A. Example Resource Certificate . . . . . . . . . . . . 26
Appendix B. Example Certificate Revocation List . . . . . . . . . 27 Appendix B. Example Certificate Revocation List . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
This document defines a standard profile for X.509 certificates for This document defines a standard profile for X.509 certificates for
use in the context of certification of IP Addresses and AS Numbers. use in the context of certification of IP Addresses and AS Numbers.
Such certificates are termed here "Resource Certificates." Resource Such certificates are termed here "Resource Certificates." Resource
Certificates are X.509 certificates that conform to the PKIX profile Certificates are X.509 certificates that conform to the PKIX profile
[RFC3280], and also conform to the constraints specified in this [RFC3280], and also conform to the constraints specified in this
profile. Resource Certificates attest that the issuer has granted profile. Resource Certificates attest that the issuer has granted
the subject a "right-to-use" for a listed set of IP addresses and the subject a "right-to-use" for a listed set of IP addresses and
skipping to change at page 7, line 38 skipping to change at page 7, line 38
each distinct entity certified by the issuer MUST be identified using each distinct entity certified by the issuer MUST be identified using
a subject name that is unique per issuer. a subject name that is unique per issuer.
This field MUST be non-empty. This field MUST be non-empty.
3.6. Valid From 3.6. Valid From
The starting time at which point the certificate is valid. In this The starting time at which point the certificate is valid. In this
profile the "Valid From" time SHOULD be no earlier than the time of profile the "Valid From" time SHOULD be no earlier than the time of
certificate generation. As per Section 4.1.2.5 of [RFC3280], certificate generation. As per Section 4.1.2.5 of [RFC3280],
Certificate Authorities (CAs) conforming to this profile MUST always Certification Authorities (CAs) conforming to this profile MUST
encode the certificate's "Valid From" date through the year 2049 as always encode the certificate's "Valid From" date through the year
UTCTime, and dates in 2050 or later MUST be encoded as 2049 as UTCTime, and dates in 2050 or later MUST be encoded as
GeneralizedTime. These two time formats are defined in [RFC3280]. GeneralizedTime. These two time formats are defined in [RFC3280].
In this profile, it is valid for a certificate to have a value for In this profile, it is valid for a certificate to have a value for
this field that pre-dates the same field value in any superior this field that pre-dates the same field value in any superior
certificate. However, it is not valid to infer from this information certificate. However, it is not valid to infer from this information
that a certificate was, or will be, valid at any particular time that a certificate was, or will be, valid at any particular time
other than the current time. other than the current time.
3.7. Valid To 3.7. Valid To
skipping to change at page 8, line 17 skipping to change at page 8, line 17
"Valid To" date through the year 2049 as UTCTime, and dates in 2050 "Valid To" date through the year 2049 as UTCTime, and dates in 2050
or later MUST be encoded as GeneralizedTime. These two time formats or later MUST be encoded as GeneralizedTime. These two time formats
are defined in [RFC3280]. are defined in [RFC3280].
In this profile, it is valid for a certificate to have a value for In this profile, it is valid for a certificate to have a value for
this field that post-dates the same field value in any superior this field that post-dates the same field value in any superior
certificate. However, it is not valid to infer from this information certificate. However, it is not valid to infer from this information
that a certificate was, or will be, valid at any particular time that a certificate was, or will be, valid at any particular time
other than the current time. other than the current time.
Certificate Authorities typically are advised against issuing a CAs are typically advised against issuing a certificate with a
certificate with a validity interval that exceeds the validity validity interval that exceeds the validity interval of the CA's
interval of the CA certificate that will be used to validate the certificate that will be used to validate the issued certificate.
issued certificate. However, in the context of this profile, it is However, in the context of this profile, it is anticipated that a CA
anticipated that a CA may have valid grounds to issue a certificate may have valid grounds to issue a certificate with a validity
with a validity interval that exceeds the validity interval of the interval that exceeds the validity interval of the CA's certificate.
CA's certificate.
3.8. Subject Public Key Info 3.8. Subject Public Key Info
This field specifies the subject's public key and the algorithm with This field specifies the subject's public key and the algorithm with
which the key is used. The public key algorithm MUST be RSA, and, which the key is used. The public key algorithm MUST be RSA, and,
accordingly, the OID for the public key algorithm is accordingly, the OID for the public key algorithm is
1.2.840.113549.1.1.1. The key size MUST be a minimum size of 1024 1.2.840.113549.1.1.1. The key size MUST be a minimum size of 1024
bits. In the context of certifying resources it is recommended that bits. In the context of certifying resources it is recommended that
the key size of keys that are intended to be used at the apex of a the key size of keys that are intended to be used at the apex of a
certificate issuance hierarchy, and their immediate subordinates, certificate issuance hierarchy, and their immediate subordinates,
skipping to change at page 12, line 48 skipping to change at page 12, line 39
with the matching private key in a repository, the directory where with the matching private key in a repository, the directory where
these signed objects is published is referenced the id-ad- these signed objects is published is referenced the id-ad-
signedObjectRepository OID. signedObjectRepository OID.
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-signedObjectRepository OBJECT IDENTIFIER ::= { id-ad 9 } id-ad-signedObjectRepository OBJECT IDENTIFIER ::= { id-ad 9 }
When the subject is an End Entity, and it publishes a single object When the subject is an End Entity, and it publishes a single object
signed with the matching private key, the location where this signed signed with the matching private key, the location where this signed
objects is published is referenced the id-ad-signedObject OID. object is published is referenced the id-ad-signedObject OID.
id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }
This profile allows the use of repository publication manifests to This profile requires the use of repository publication manifests
list all signed objects that are deposited in the repository [ID.SIDR-MANIFESTS] to list all signed objects that are deposited in
publication point assocaited with a CA or an EE. The publication the repository publication point assocaited with a CA or an EE. The
point of the manifest for a CA or EE is placed in the SIA extension publication point of the manifest for a CA or EE is placed in the SIA
of the CA or EE certificate. This profile uses a URI form of extension of the CA or EE certificate. This profile uses a URI form
manifest identification for the accessLocation. The preferred URI of manifest identification for the accessLocation. The preferred URI
access mechanisms is "rsync", and an RSYNC URI MUST be specified. access mechanisms is "rsync", and an RSYNC URI MUST be specified.
Other accessDescription fields may exist with this id-ad-Manifest Other accessDescription fields may exist with this id-ad-Manifest
accessMethod, where the accessLocation value indicates alternate URI accessMethod, where the accessLocation value indicates alternate URI
access mechanisms for the same manifest object. access mechanisms for the same manifest object.
id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }
CA certificates MUST include in the SIA an accessMethod OID of id-ad-
rpkiManifest, where the associated accessLocation refers to the
subject's published manifest object as an object URL.
When an EE certificate is intended for use in verifying multiple
objects, EE certificate MUST include in the SIA an access method OID
of id-ad-rpkiManifest, where the associated access location refers to
the publication point of the objects that are verified using this EE
certificate.
When an EE certificate is used to sign a single object, the EE
certificate MUST include in the SIA an access method OID of id-ad-
signedObject, where the associated access location refers to the
publication point of the single object that is verified using this EE
certificate.
3.9.8. Certificate Policies 3.9.8. Certificate Policies
This extension MUST reference the Resource Certificate Policy, using This extension MUST reference the Resource Certificate Policy, using
the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field
MUST be present and MUST contain only this value for Resource MUST be present and MUST contain only this value for Resource
Certificates. Certificates.
PolicyQualifiers MUST NOT be used in this profile. PolicyQualifiers MUST NOT be used in this profile.
This extension MUST be present and it is critical. This extension MUST be present and it is critical.
skipping to change at page 16, line 20 skipping to change at page 16, line 20
4.7.2. CRL Number 4.7.2. CRL Number
The CRL Number extension conveys a monotonically increasing sequence The CRL Number extension conveys a monotonically increasing sequence
number of positive integers for a given CA and scope. This extension number of positive integers for a given CA and scope. This extension
allows users to easily determine when a particular CRL supersedes allows users to easily determine when a particular CRL supersedes
another CRL. The highest CRL Number value supersedes all other CRLs another CRL. The highest CRL Number value supersedes all other CRLs
issued by the CA with the same scope. issued by the CA with the same scope.
This extension is non-critical. This extension is non-critical.
5. Manifest Profile 5. Resource Certificate Request Profile
6. Resource Certificate Request Profile
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 Issuer MUST support Certificate Request Message Format (CRMF). A CA Issuer MUST support
PKCS#10 and a CA Issuer may, with mutual consent of the subject, PKCS#10 and a CA Issuer may, with mutual consent of the subject,
support CRMF. support CRMF.
6.1. PCKS#10 Profile 5.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 Certificate Authority formatted according to PKCS#10, is passed to a CA as the initial step
as the initial step in issuing a certificate. in issuing a certificate.
This request may be conveyed to the CA via a Registration Authority This request may be conveyed to the CA via a Registration Authority
(RA), acting under the direction of a Subject. (RA), acting under the direction of a Subject.
With the exception of the public key related fields, the CA is With the exception of the public key related fields, the CA is
permitted to alter any requested field when issuing a corresponding permitted to alter any requested field when issuing a corresponding
certificate. certificate.
6.1.1. PKCS#10 Resource Certificate Request Template Fields 5.1.1. PKCS#10 Resource Certificate Request Template Fields
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that may appear in a CertificationRequestInfo: that may appear in a CertificationRequestInfo:
Version Version
This field is mandatory and MUST have the value 0. This field is mandatory and MUST have the value 0.
Subject Subject
This field is optional. If present, the value of this field This field is optional. If present, the value of this field
SHOULD be empty, in which case the issuer MUST generate a subject SHOULD be empty, in which case the issuer MUST generate a subject
skipping to change at page 17, line 33 skipping to change at page 17, line 30
key. For the RSA public-key algorithm the bit string contains the key. For the RSA public-key algorithm the bit string contains the
DER encoding of a value of PKCS #1 type RSAPublicKey. DER encoding of a value of PKCS #1 type RSAPublicKey.
Attributes Attributes
[RFC2986] defines the attributes field as key-value pairs where [RFC2986] defines the attributes field as key-value pairs where
the key is an OID and the value's structure depends on the key. the key is an OID and the value's structure depends on the key.
The only attribute used in this profile is the ExtensionRequest The only attribute used in this profile is the ExtensionRequest
attribute as defined in [RFC2985]. This attribute contains X509v3 attribute as defined in [RFC2985]. This attribute contains X509v3
Certificate Extensions. The profile for extensions in certificate Certificate Extensions. The profile for extensions in certificate
requests is specified in Section 6.3. requests is specified in Section 5.3.
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that MAY appear in a CertificationRequest Object: that MAY appear in a CertificationRequest Object:
signatureAlgorithm signatureAlgorithm
This profile specifies a minimum of SHA-256 with RSA This profile specifies a minimum of SHA-256 with RSA
(sha256WithRSAEncryption), and allows for the use of SHA-384 or (sha256WithRSAEncryption), and allows for the use of SHA-384 or
SHA-512. Accordingly, the value for this field MUST be one of the SHA-512. Accordingly, the value for this field MUST be one of the
OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 }
[RFC4055]. [RFC4055].
It is noted that larger key sizes are computationally expensive It is noted that larger key sizes are computationally expensive
for both the CA and relying parties, indicating that care should for both the CA and relying parties, indicating that care should
be taken when deciding to use larger than the minimum key size. be taken when deciding to use larger than the minimum key size.
6.2. CRMF Profile 5.2. CRMF Profile
This profile refines the Certificate Request Message Format (CRMF) This profile refines the Certificate Request Message Format (CRMF)
specification in [RFC4211], as it relates to Resource Certificates. specification in [RFC4211], as it relates to Resource Certificates.
A Certificate Request Message object, formatted according to the A Certificate Request Message object, formatted according to the
CRMF, is passed to a Certificate Authority as the initial step in CRMF, is passed to a CA as the initial step in issuing a certificate.
issuing a certificate.
This request MAY be conveyed to the CA via a Registration Authority This request MAY be conveyed to the CA via a Registration Authority
(RA), acting under the direction of a subject. (RA), acting under the direction of a subject.
With the exception of the public key related fields, the CA is With the exception of the public key related fields, the CA is
permitted to alter any requested field when issuing a corresponding permitted to alter any requested field when issuing a corresponding
certificate. certificate.
6.2.1. CRMF Resource Certificate Request Template Fields 5.2.1. CRMF Resource Certificate Request Template Fields
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that may appear in a Certificate Request Template: that may appear in a Certificate Request Template:
Version Version
This field MAY be absent, or MAY specify the request of a Version This field MAY be absent, or MAY specify the request of a Version
3 Certificate. It SHOULD be omitted. 3 Certificate. It SHOULD be omitted.
SerialNumber SerialNumber
As per [RFC4211], this field is assigned by the CA and MUST be As per [RFC4211], this field is assigned by the CA and MUST be
skipping to change at page 19, line 11 skipping to change at page 19, line 8
subject name, but the CA is NOT bound to honour this suggestion, subject name, but the CA is NOT bound to honour this suggestion,
as the subject name MUST be unique per issuer in certificates as the subject name MUST be unique per issuer in certificates
issued by this issuer. issued by this issuer.
PublicKey PublicKey
This field MUST be present. This field MUST be present.
extensions extensions
This attribute contains X509v3 Certificate Extensions. The This attribute contains X509v3 Certificate Extensions. The
profile for extensions in certificate requests is specified in profile for extensions in certificate requests is specified in
Section 6.3. Section 5.3.
6.2.2. Resource Certificate Request Control Fields 5.2.2. Resource Certificate Request Control Fields
The following control fields are supported in this profile: The following control fields are supported in this profile:
Authenticator Control Authenticator Control
It is noted that the intended model of authentication of the It is noted that the intended model of authentication of the
subject is a long term one, and the advice as offered in [RFC4211] subject is a long term one, and the advice as offered in [RFC4211]
is that the Authenticator Control field be used. is that the Authenticator Control field be used.
6.3. Certificate Extension Attributes in Certificate Requests 5.3. Certificate Extension Attributes in Certificate Requests
The following extensions MAY appear in a PKCS#10 or CRMF Certificate The following extensions MAY appear in a PKCS#10 or CRMF Certificate
Request. Any other extensions MUST NOT appear in a Certificate Request. Any other extensions MUST NOT appear in a Certificate
Request. This profile places the following additional constraints on Request. This profile places the following additional constraints on
these extensions.: these extensions.:
BasicConstraints BasicConstraints
If this is omitted then the CA will issue an end entity If this is omitted then the CA will issue an end entity
certificate with the BasicConstraints extension not present in the certificate with the BasicConstraints extension not present in the
issued certificate. issued certificate.
skipping to change at page 20, line 22 skipping to change at page 20, line 18
SubjectType sub field, when specified. SubjectType sub field, when specified.
SubjectInformationAccess SubjectInformationAccess
This field MUST be present when the subject is a CA, and the field This field MUST be present when the subject is a CA, and the field
value SHOULD be honoured by the CA. If the CA is not able to value SHOULD be honoured by the CA. If the CA is not able to
honor the requested field value, then the CA MUST reject the honor the requested field value, then the CA MUST reject the
Certificate Request. Certificate Request.
This field (SIA) identifies the location of information and This field (SIA) identifies the location of information and
services relating to the subject of the certificate in which the services relating to the subject of the certificate in which the
SIA extension appears. Where the Subject is a CA in this profile, SIA extension appears.
this information and service collection will include all current
valid certificates that have been issued by this subject that are Where the subject is a CA in this profile, this information and
signed with the subject's corresponding private key. service collection will include all current valid certificates
that have been issued by this subject that are signed with the
subject's corresponding private key.
This profile uses a URI form of location identification. An RSYNC This profile uses a URI form of location identification. An RSYNC
URI MUST be specified, with an access method value of id-ad- URI MUST be specified, with an access method value of id-ad-
caRepository when the subject of the certificate is a CA. The caRepository when the subject of the certificate is a CA. The
RSYNC URI MUST reference an object collection rather than an RSYNC URI MUST reference an object collection rather than an
individual object and MUST use a trailing '/' in the URI. Other individual object and MUST use a trailing '/' in the URI. Other
access method URIs that reference the same location MAY also be access method URIs that reference the same location MAY also be
included in the value sequence of this extension. The ordering of included in the value sequence of this extension. The ordering of
URIs in this sequence reflect the subject's relative preferences URIs in this sequence reflect the subject's relative preferences
for access methods, with the first method in the sequence being for access methods, with the first method in the sequence being
the most preferred by the Subject. the most preferred by the Subject.
A request for a CA certificate MUST include in the SIA of the
request the id-ad-caRepository access method, and also MUST
include in the SIA of the request the accessMethod OID of id-ad-
rpkiManifest, where the associated accessLocation refers to the
subject's published manifest object as an object URL.
When an EE certificate is intended for use in verifying multiple
objects, the certificate request for the EE certificate MUST
include in the SIA of the request an access method OID of id-ad-
signedObjectRepository, and also MUST include in the SIA of the
request an access method OID of id-ad-rpkiManifest, where the
associated access location refers to the publication point of the
objects that are verified using this EE certificate.
When an EE certificate is used to sign a single object, the
certificate request for the EE certificate MUST include in the SIA
of the request an access method OID of id-ad-signedObject, where
the associated access location refers to the publication point of
the single object that is verified using this EE certificate, and
MUST NOT include an id-ad-rpkiManifest access method OID in the
SIA of the request.
CRLDistributionPoints CRLDistributionPoints
This field is assigned by the CA and MUST be omitted in this This field is assigned by the CA and MUST be omitted in this
profile. profile.
AuthorityInformationAccess AuthorityInformationAccess
This field is assigned by the CA and MUST be omitted in this This field is assigned by the CA and MUST be omitted in this
profile. profile.
CertificatePolicies CertificatePolicies
This field is assigned by the CA and MUST be omitted in this This field is assigned by the CA and MUST be omitted in this
profile. profile.
With the exceptions of the publicKey field and the With the exceptions of the publicKey field and the
SubjectInformationAccess field, the CA is permitted to alter any SubjectInformationAccess field, the CA is permitted to alter any
requested field. requested field.
7. Resource Certificate Validation 6. Resource Certificate Validation
This section describes the Resource Certificate validation procedure. This section describes the Resource Certificate validation procedure.
This refines the generic procedure described in section 6 of This refines the generic procedure described in section 6 of
[RFC3280]: [RFC3280]:
To meet this goal, the path validation process verifies, among other To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions: certificates) satisfies the following conditions:
1. for all x in {1, ..., n-1}, the subject of certificate x is the 1. for all x in {1, ..., n-1}, the subject of certificate x is the
issuer of certificate x+1; issuer of certificate x+1;
2. certificate 1 is issued by a trust anchor; 2. certificate 1 is issued by a trust anchor;
3. certificate n is the certificate to be validated; and 3. certificate n is the certificate to be validated; and
4. for all x in {1, ..., n}, the certificate is valid. 4. for all x in {1, ..., n}, the certificate is valid.
7.1. Trust Anchors for Resource Certificates 6.1. Trust Anchors for Resource Certificates
The trust model that may be used in the resource certificate The trust model that may be used in the resource certificate
framework in the context of validation of assertions of public number framework in the context of validation of assertions of public number
resources in public-use contexts is one that readily maps to a top- resources in public-use contexts is one that readily maps to a top-
down delegated CA model that mirrors the delegation of resources from down delegated CA model that mirrors the delegation of resources from
a registry distribution point to the entities that are the direct a registry distribution point to the entities that are the direct
recipients of these resources. Within this trust model these recipients of these resources. Within this trust model these
recipient entities may, in turn, operate a registry and perform recipient entities may, in turn, operate a registry and perform
further allocations or assignments. This is a strict hierarchy, in further allocations or assignments. This is a strict hierarchy, in
that any number resource and a corresponding recipient entity has that any number resource and a corresponding recipient entity has
skipping to change at page 21, line 49 skipping to change at page 22, line 19
or indirect subordinate recipient entity of the recipient entity in or indirect subordinate recipient entity of the recipient entity in
question (i.e. no loops in the model). question (i.e. no loops in the model).
The more general consideration is that selection of a trust anchor CA The more general consideration is that selection of a trust anchor CA
is a task undertaken by relying parties. The structure of the is a task undertaken by relying parties. The structure of the
resource certificate profile admits potentially the same variety of resource certificate profile admits potentially the same variety of
trust models as the PKIX profile. There is only one additional trust models as the PKIX profile. There is only one additional
caveat on the general applicability of trust models and PKIX caveat on the general applicability of trust models and PKIX
frameworks, namely that in forming a validation path to a trust frameworks, namely that in forming a validation path to a trust
anchor CA, the sequence of certificates MUST preserve the resource anchor CA, the sequence of certificates MUST preserve the resource
extension validation property, as described in Section 7.2, and the extension validation property, as described in Section 6.2, and the
validation of the first certificate in the validation path not only validation of the first certificate in the validation path not only
involves the verification that the certificate was issued by a trust involves the verification that the certificate was issued by a trust
anchor CA, but also that the resource set described in the anchor CA, but also that the resource set described in the
certificate MUST be encompassed by the trust anchor CA's resource certificate MUST be encompassed by the trust anchor CA's resource
set, as described in Section 7.2. set, as described in Section 6.2.
The trust anchor information, describing a CA that serves as a trust The trust anchor information, describing a CA that serves as a trust
anchor, includes the following: anchor, includes the following:
1. the trusted issuer name, 1. the trusted issuer name,
2. the trusted public key algorithm, 2. the trusted public key algorithm,
3. the trusted public key, 3. the trusted public key,
4. optionally, the trusted public key parameters associated with the 4. optionally, the trusted public key parameters associated with the
public key, and public key, and
5. a resource set, consisting of a set of IPv4 resources, IPv6 5. a resource set, consisting of a set of IPv4 resources, IPv6
resources and AS number resources. resources and AS number resources.
The trust anchor information may be provided to the path processing The trust anchor information may be provided to the path processing
procedure in the form of a self-signed certificate. procedure in the form of a self-signed certificate.
7.2. Resource Extension Validation 6.2. Resource Extension Validation
The IP resource extension definition [RFC3779] defines a critical The IP resource extension definition [RFC3779] defines a critical
extensions for Internet number resources. These are ASN.1 encoded extensions for Internet number resources. These are ASN.1 encoded
representations of the IPv4 and IPv6 address range (either as a representations of the IPv4 and IPv6 address range (either as a
prefix/length, or start-end pair) and the AS number set. prefix/length, or start-end pair) and the AS number set.
Valid Resource Certificates MUST have a valid IP address and/or AS Valid Resource Certificates MUST have a valid IP address and/or AS
number resource extension. In order to validate a Resource number resource extension. In order to validate a Resource
Certificate the resource extension must also be validated. This Certificate the resource extension must also be validated. This
validation process relies on definitions of comparison of resource validation process relies on definitions of comparison of resource
skipping to change at page 23, line 12 skipping to change at page 23, line 30
Validation of a certificate's resource extension in the context of an Validation of a certificate's resource extension in the context of an
ordered certificate sequence of {1,2, ... , n} where '1'is issued by ordered certificate sequence of {1,2, ... , n} where '1'is issued by
a trust anchor and 'n' is the target certificate, and where the a trust anchor and 'n' is the target certificate, and where the
subject of certificate 'x' is the issuer of certificate 'x' + 1, subject of certificate 'x' is the issuer of certificate 'x' + 1,
implies that the resources described in certificate 'x' "encompass" implies that the resources described in certificate 'x' "encompass"
the resources described in certificate 'x' + 1, and the resources the resources described in certificate 'x' + 1, and the resources
described in the trust anchor information "encompass" the resources described in the trust anchor information "encompass" the resources
described in certificate 1. described in certificate 1.
7.3. Resource Certificate Path Validation 6.3. Resource Certificate Path Validation
Validation of signed resource data using a target resource Validation of signed resource data using a target resource
certificate consists of assembling an ordered sequence (or certificate consists of assembling an ordered sequence (or
'Certificate Path') of certificates ({1,2,...n} where '1' is a 'Certificate Path') of certificates ({1,2,...n} where '1' is a
certificate that has been issued by a trust anchor, and 'n' is the certificate that has been issued by a trust anchor, and 'n' is the
target certificate) verifying that all of the following conditions target certificate) verifying that all of the following conditions
hold: hold:
1. The certificate can be verified using the Issuer's public key and 1. The certificate can be verified using the Issuer's public key and
the signature algorithm the signature algorithm
skipping to change at page 24, line 24 skipping to change at page 24, line 42
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 certificate validator. means of creating a potential DOS attack on a certificate validator.
Some further heuristics may be required to halt the certificate path Some further heuristics may be required to halt the certificate path
validation process in order to avoid some of the issues associated validation process in order to avoid some of the issues associated
with attempts to validate such structures. It is suggested that with attempts to validate such structures. It is suggested that
implementations of Resource Certificate validation MAY halt with a implementations of Resource Certificate validation MAY halt with a
validation failure if the certificate path length exceeds a pre- validation failure if the certificate path length exceeds a pre-
determined configuration parameter. determined configuration parameter.
8. Security Considerations 7. Security Considerations
The Security Considerations of [RFC3280] and [RFC3779]apply to The Security Considerations of [RFC3280] and [RFC3779]apply to
Resource Certificates as defined by this profile, and their use. Resource Certificates as defined by this profile, and their use.
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.
9. IANA Considerations 8. 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 version of the document.] considerations stated in this version of the document.]
10. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge the valued contributions from The authors would like to acknowledge the valued contributions from
Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo
Patara and Rob Austein in the preparation and subsequent review of Patara and Rob Austein in the preparation and subsequent review of
this document. The document also reflects review comments received this document. The document also reflects review comments received
from Sean Turner. from Sean Turner.
11. References 10. References
11.1. Normative References 10.1. Normative References
[ID.SIDR-MANIFESTS]
Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure",
Work in progress: Internet
Drafts draft-ietf-sidr-rpki-manifests-00.txt,
January 2008.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
BCP 12, RFC 2050, November 1996. BCP 12, RFC 2050, November 1996.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
skipping to change at page 25, line 37 skipping to change at page 26, line 14
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005. June 2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211,
September 2005. September 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
11.2. Informative References 10.2. Informative References
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
November 2000. November 2000.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
November 2000. November 2000.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
skipping to change at page 29, line 9 skipping to change at page 30, line 9
09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da: 09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da:
02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d: 02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d:
59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f: 59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f:
34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02: 34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02:
d9 d9
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
33 Park Rd.
Milton, QLD 4064
Australia
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
George Michaelson George Michaelson
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
33 Park Rd.
Milton, QLD 4064
Australia
Email: ggm@apnic.net Email: ggm@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Robert Loomans Robert Loomans
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
33 Park Rd.
Milton, QLD 4064
Australia
Email: robertl@apnic.net Email: robertl@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 45 change blocks. 
78 lines changed or deleted 126 lines changed or added

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