< draft-ietf-sidr-res-certs-08.txt   draft-ietf-sidr-res-certs-09.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: January 29, 2008 APNIC Expires: May 17, 2008 APNIC
July 28, 2007 November 14, 2007
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-08.txt draft-ietf-sidr-res-certs-09.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 January 29, 2008. This Internet-Draft will expire on May 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
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 . . . . . 8 3.9. Resource Certificate Version 3 Extension Fields . . . . . 9
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 . . . . . . . . . . . . . . . 9 3.9.3. Authority Key Identifier . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . 11 3.9.7. Subject Information Access . . . . . . . . . . . . . . 12
3.9.8. Certificate Policies . . . . . . . . . . . . . . . . . 12 3.9.8. Certificate Policies . . . . . . . . . . . . . . . . . 13
3.9.9. IP Resources . . . . . . . . . . . . . . . . . . . . . 12 3.9.9. IP Resources . . . . . . . . . . . . . . . . . . . . . 13
3.9.10. AS Resources . . . . . . . . . . . . . . . . . . . . . 13 3.9.10. AS Resources . . . . . . . . . . . . . . . . . . . . . 13
4. Resource Certificate Revocation List Profile . . . . . . . . . 13 4. Resource Certificate Revocation List Profile . . . . . . . . . 14
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 15
4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 14 4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 15
4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 14 4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 15
4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 15 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 16
5. Resource Certificate Request Profile . . . . . . . . . . . . . 15 5. Manifest Profile . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 15 6. Resource Certificate Request Profile . . . . . . . . . . . . . 16
5.1.1. PKCS#10 Resource Certificate Request Template 6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. PKCS#10 Resource Certificate Request Template
Fields . . . . . . . . . . . . . . . . . . . . . . . . 16 Fields . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. CRMF Resource Certificate Request Template Fields . . 17 6.2.1. CRMF Resource Certificate Request Template Fields . . 18
5.2.2. Resource Certificate Request Control Fields . . . . . 18 6.2.2. Resource Certificate Request Control Fields . . . . . 19
5.3. Certificate Extension Attributes in Certificate 6.3. Certificate Extension Attributes in Certificate
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 18 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Resource Certificate Validation . . . . . . . . . . . . . . . 20 7. Resource Certificate Validation . . . . . . . . . . . . . . . 21
6.1. Trust Anchors for Resource Certificates . . . . . . . . . 20 7.1. Trust Anchors for Resource Certificates . . . . . . . . . 21
6.2. Resource Extension Validation . . . . . . . . . . . . . . 21 7.2. Resource Extension Validation . . . . . . . . . . . . . . 22
6.3. Resource Certificate Path Validation . . . . . . . . . . . 22 7.3. Resource Certificate Path Validation . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Example Resource Certificate . . . . . . . . . . . . 25 Appendix A. Example Resource Certificate . . . . . . . . . . . . 26
Appendix B. Example Certificate Revocation List . . . . . . . . . 27 Appendix B. Example Certificate Revocation List . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 30
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
skipping to change at page 7, line 6 skipping to change at page 7, line 6
3.3. Signature Algorithm 3.3. Signature Algorithm
This field describes the algorithm used to compute the signature on This field describes the algorithm used to compute the signature on
this certificate. This profile specifies a minimum of SHA-256 with this certificate. This profile specifies a minimum of SHA-256 with
RSA (sha256WithRSAEncryption), and allows for the use of SHA-384 or RSA (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 } [RFC4055]. OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } [RFC4055].
It is noted that larger key sizes are computationally expensive for It is noted that larger key sizes are computationally expensive for
both the CA and relying parties, indicating that care should be taken both the Certiciate Authority and relying parties, indicating that
when deciding to use larger than the minimum key size. care should be taken when deciding to use larger than the minimum key
size.
3.4. Issuer 3.4. Issuer
This field identifies the entity that has signed and issued the This field identifies the entity that has signed and issued the
certificate. The value of this field is a valid X.501 name. certificate. The value of this field is a valid X.501 name.
If the certificate is a subordinate certificate issued by virtue of If the certificate is a subordinate certificate issued by virtue of
the "cA" bit set in the immediate superior certificate, then the the "cA" bit set in the immediate superior certificate, then the
issuer name MUST correspond to the subject name as contained in the issuer name MUST correspond to the subject name as contained in the
immediate superior certificate. immediate superior certificate.
skipping to change at page 10, line 18 skipping to change at page 10, line 26
The Key Identifier used here is the 160-bit SHA-1 hash of the value The Key Identifier used here is the 160-bit SHA-1 hash of the value
of the DER-encoded ASN.1 bit string of the issuer's public key, as of the DER-encoded ASN.1 bit string of the issuer's public key, as
described in Section 4.2.1.1 of [RFC3280]. described in Section 4.2.1.1 of [RFC3280].
3.9.4. Key Usage 3.9.4. Key Usage
This describes the purpose of the certificate. This is a critical This describes the purpose of the certificate. This is a critical
extension, and it MUST be present. extension, and it MUST be present.
In certificates issued to CAs only the keyCertSign and CRLSign bits In certificates issued to Certicate Authorities only the keyCertSign
are set to TRUE and MUST be the only bits set to TRUE. and CRLSign bits are set to TRUE and MUST be the only bits set to
TRUE.
In end-entity certificates the digitialSignature bit MUST be set and In end-entity certificates the digitialSignature bit MUST be set and
MUST be the only bit set to TRUE. MUST be the only bit set to TRUE.
3.9.5. CRL Distribution Points 3.9.5. CRL Distribution Points
This field (CRLDP) identifies the location(s) of the CRL(s) This field (CRLDP) identifies the location(s) of the CRL(s)
associated with certificates issued by this Issuer. This profile associated with certificates issued by this Issuer. This profile
uses the URI form of object identification. The preferred URI access uses the URI form of object identification. The preferred URI access
mechanism is a single RSYNC URI ("rsync://") [rsync] that references mechanism is a single RSYNC URI ("rsync://") [rsync] that references
skipping to change at page 12, line 19 skipping to change at page 12, line 30
Other access method URIs that reference the same location MAY also be Other 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 for URIs in this sequence reflect the subject's relative preferences for
access methods, with the first method in the sequence being the most access methods, with the first method in the sequence being the most
preferred. preferred.
This field MUST be present when the subject is a CA, and is non- This field MUST be present when the subject is a CA, and is non-
critical. critical.
For End Entity certificates, where the subject is not a CA, this For End Entity (EE) certificates, where the subject is not a CA, this
field MAY be present, and is non-critical. If present, it references field MAY be present, and is non-critical. If present, it either
the location where objects signed by the key pair associated with the references the location where objects signed by the key pair
End Entity certificate can be accessed. The id-ad- associated with the EE certificate can be accessed, or, in the case
signedObjectRepository OID is used when the subject is an End Entity of single-use EE certificates it references the location of the
and it publishes objects signed with the matching private key in a single object that has been signed by the corresponding key pair.
repository.
When the subject is an End Entity, and it publishes objects signed
with the matching private key in a repository, the directory where
these signed objects is published is referenced the id-ad-
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
signed with the matching private key, the location where this signed
objects is published is referenced the id-ad-signedObject OID.
id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }
This profile allows the use of repository publication manifests to
list all signed objects that are deposited in the repository
publication point assocaited with a CA or an EE. The publication
point of the manifest for a CA or EE is placed in the SIA extension
of the CA or EE certificate. This profile uses a URI form of
manifest identification for the accessLocation. The preferred URI
access mechanisms is "rsync", and an RSYNC URI MUST be specified.
Other accessDescription fields may exist with this id-ad-Manifest
accessMethod, where the accessLocation value indicates alternate URI
access mechanisms for the same manifest object.
id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }
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 15, line 33 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. Resource Certificate Request Profile 5. Manifest 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.
5.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 Certificate Authority formatted according to PKCS#10, is passed to a Certificate Authority
as the initial step in issuing a certificate. as the initial step 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.
5.1.1. PKCS#10 Resource Certificate Request Template Fields 6.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 16, line 40 skipping to change at page 17, line 33
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 5.3. requests is specified in Section 6.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].
skipping to change at page 17, line 4 skipping to change at page 17, line 44
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.
5.2. CRMF Profile 6.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 Certificate Authority 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.
5.2.1. CRMF Resource Certificate Request Template Fields 6.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 18, line 21 skipping to change at page 19, line 11
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 5.3. Section 6.3.
5.2.2. Resource Certificate Request Control Fields 6.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.
5.3. Certificate Extension Attributes in Certificate Requests 6.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 19, line 22 skipping to change at page 20, line 10
SubjectKeyIdentifier SubjectKeyIdentifier
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.
AuthorityKeyIdentifier AuthorityKeyIdentifier
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.
KeyUsage KeyUsage
The CA MAY honor KeyUsage extensions of CertificateSigning and The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign if
CRLSigning if present, as long as this is consistent with the present, as long as this is consistent with the BasicConstraints
BasicConstraints SubjectType sub field, when specified. SubjectType sub field, when specified.
SubjectInformationAccess SubjectInformationAccess
This field MAY 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.
If the field is not present, then the CA shall interpret the
request as a request by the subject entity to publish subordinate
certificates via the CA, and the CA will place the publication
point in the SIA field of the issued certificate.
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. Where the Subject is a CA in this profile,
this information and service collection will include all current this information and service collection will include all current
valid certificates that have been issued by this subject that are valid certificates that have been issued by this subject that are
signed with the subject's corresponding private key. 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
skipping to change at page 20, line 22 skipping to change at page 21, line 6
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.
6. Resource Certificate Validation 7. 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.
6.1. Trust Anchors for Resource Certificates 7.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 19 skipping to change at page 21, line 49
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 6.2, and the extension validation property, as described in Section 7.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 6.2. set, as described in Section 7.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.
6.2. Resource Extension Validation 7.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 22, line 30 skipping to change at page 23, line 12
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.
6.3. Resource Certificate Path Validation 7.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 23, line 42 skipping to change at page 24, line 24
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.
7. Security Considerations 8. 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.
8. IANA Considerations 9. 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.]
9. Acknowledgements 10. 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. this document. The document also reflects review comments received
from Sean Turner.
10. References 11. References
10.1. Normative References 11.1. Normative References
[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 6 skipping to change at page 25, line 37
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.
10.2. Informative References 11.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.
 End of changes. 40 change blocks. 
79 lines changed or deleted 102 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/