draft-ietf-sidr-res-certs-11.txt   draft-ietf-sidr-res-certs-12.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: February 2, 2009 APNIC Expires: March 10, 2009 APNIC
August 1, 2008 September 6, 2008
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-11.txt draft-ietf-sidr-res-certs-12
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 February 2, 2009. This Internet-Draft will expire on March 10, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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-of-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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . 8
3.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 9 3.9.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 9
3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 10 3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . 10
3.9.7. Subject Information Access . . . . . . . . . . . . . . 11 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 . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . 16 4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 15
4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 16 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 15
5. Resource Certificate Request Profile . . . . . . . . . . . . . 16 5. Resource Certificate Request Profile . . . . . . . . . . . . . 16
5.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 16 5.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. PKCS#10 Resource Certificate Request Template 5.1.1. PKCS#10 Resource Certificate Request Template
Fields . . . . . . . . . . . . . . . . . . . . . . . . 16 Fields . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. CRMF Resource Certificate Request Template Fields . . 18 5.2.1. CRMF Resource Certificate Request Template Fields . . 17
5.2.2. Resource Certificate Request Control Fields . . . . . 19 5.2.2. Resource Certificate Request Control Fields . . . . . 18
5.3. Certificate Extension Attributes in Certificate 5.3. Certificate Extension Attributes in Certificate
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Resource Certificate Validation . . . . . . . . . . . . . . . 21 6. Resource Certificate Validation . . . . . . . . . . . . . . . 21
6.1. Trust Anchors for Resource Certificates . . . . . . . . . 22 6.1. Resource Extension Validation . . . . . . . . . . . . . . 21
6.2. Resource Extension Validation . . . . . . . . . . . . . . 22 6.2. Resource Certification Path Validation . . . . . . . . . . 22
6.3. Resource Certificate Path Validation . . . . . . . . . . . 23 6.3. Trust Anchors for Resource Certificates . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6.3.1. Distribution Format of Nominated Trust Anchor
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 Material . . . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 26 10. Draft Review Notes . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Example Resource Certificate . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix B. Example Certificate Revocation List . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Appendix A. Example Resource Certificate . . . . . . . . . . . . 32
Appendix B. Example Certificate Revocation List . . . . . . . . . 34
Appendix C. Cryptographic Message Syntax Profile for RPKI
Trust Anchor Material . . . . . . . . . . . . . . . . 35
C.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 35
C.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 36
C.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 37
C.2. RTA Validation . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 42
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
use in the context of certification of IP Addresses and AS Numbers. [X.509] for use in the context of certification of IP Addresses and
Such certificates are termed here "Resource Certificates." Resource AS Numbers. Such certificates are termed here "Resource
Certificates are X.509 certificates that conform to the PKIX profile Certificates." Resource Certificates are X.509 certificates that
[RFC5280], and also conform to the constraints specified in this conform to the PKIX profile [RFC5280], and also conform to the
profile. Resource Certificates attest that the issuer has granted constraints specified in this profile. Resource Certificates attest
the subject a "right-to-use" for a listed set of IP addresses and that the issuer has granted the subject a "right-of-use" for a listed
Autonomous System numbers. set of IP addresses and Autonomous System numbers.
A Resource Certificate describes an action by a certificate issuer A Resource Certificate describes an action by a certificate issuer
that binds a list of IP Address blocks and AS Numbers to the subject that binds a list of IP Address blocks and AS Numbers to the subject
of the issued certificate. The binding is identified by the of the issued certificate. The binding is identified by the
association of the subject's private key with the subject's public association of the subject's private key with the subject's public
key contained in the Resource Certificate, as signed by the private key contained in the Resource Certificate, as signed by the private
key of the certificate's issuer. key of the certificate's issuer.
In the context of the public Internet, and the use of public number In the context of the public Internet, and the use of public number
resources within this context, it is intended that Resource resources within this context, it is intended that Resource
skipping to change at page 4, line 39 skipping to change at page 4, line 39
Certificate. This certificate is issued by the number registry, and Certificate. This certificate is issued by the number registry, and
the subject's public key that is being certified by the issuer the subject's public key that is being certified by the issuer
corresponds to the public key part of a public / private key pair corresponds to the public key part of a public / private key pair
that was generated by the same entity who is the recipient of the that was generated by the same entity who is the recipient of the
number assignment or allocation. A critical extension to the number assignment or allocation. A critical extension to the
certificate enumerates the IP Resources that were allocated or certificate enumerates the IP Resources that were allocated or
assigned by the issuer to the entity. In the context of the public assigned by the issuer to the entity. In the context of the public
number distribution function, this corresponds to a hierarchical PKI number distribution function, this corresponds to a hierarchical PKI
structure, where Resource Certificates are only issued in one structure, where Resource Certificates are only issued in one
'direction' and there is a single unique path of certificates from a 'direction' and there is a single unique path of certificates from a
certificate authority operating at the apex of a resource certification authority operating at the apex of a resource
distribution hierarchy to a valid certificate. distribution hierarchy to a valid certificate.
Validation of a Resource Certificate in such a hierarchical PKI can Validation of a Resource Certificate in such a hierarchical PKI can
be undertaken by establishing a valid issuer-subject certificate be undertaken by establishing a valid issuer-subject certificate
chain from a certificate issued by a trust anchor certificate chain from a certificate issued by a trust anchor certification
authority to the certificate [RFC4158], with the additional authority to the certificate [RFC4158], with the additional
constraint of ensuring that each subject's listed resources are fully constraint of ensuring that each subject's listed resources are fully
encompassed by those of the issuer at each step in the issuer-subject encompassed by those of the issuer at each step in the issuer-subject
certificate chain. certificate chain.
Resource Certificates may be used in the context of the operation of Resource Certificates may be used in the context of the operation of
secure inter-domain routing protocols to convey a right-to-use of an secure inter-domain routing protocols to convey a right-of-use of an
IP number resource that is being passed within the routing protocol, IP number resource that is being passed within the routing protocol,
allowing relying parties to verify legitimacy and correctness of allowing relying parties to verify legitimacy and correctness of
routing information. Related use contexts include validation of routing information. Related use contexts include validation of
Internet Routing Registry objects, validation of routing requests, Internet Routing Registry objects, validation of routing requests,
and detection of potential unauthorised use of IP addresses. and detection of potential unauthorised use of IP addresses.
This profile defines those fields that are used in a Resource This profile defines those fields that are used in a Resource
Certificate that MUST be present for the certificate to be valid. Certificate that MUST be present for the certificate to be valid.
Relying Parties SHOULD check that a Resource Certificate conforms to Relying Parties SHOULD check that a Resource Certificate conforms to
this profile as a requisite for validation of a Resource Certificate. this profile as a requisite for validation of a Resource Certificate.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
the immediate superior certificate in the PKI hierarchy (the the immediate superior certificate in the PKI hierarchy (the
certificate where this certificate's issuer is the subject) has a certificate where this certificate's issuer is the subject) has a
resource set (called here the "issuer's resource set") that must resource set (called here the "issuer's resource set") that must
encompass the resource set of the issued certificate. In this encompass the resource set of the issued certificate. In this
context "encompass" allows for the issuer's resource set to be context "encompass" allows for the issuer's resource set to be
the same as, or a strict superset of, any subject's resource set. the same as, or a strict superset of, any subject's resource set.
A test of certificate validity entails the identification of a A test of certificate validity entails the identification of a
sequence of valid certificates in an issuer-subject chain (where the sequence of valid certificates in an issuer-subject chain (where the
subject field of one certificate appears as the issuer in the next subject field of one certificate appears as the issuer in the next
certificate in the sequence) from a trust anchor certificate certificate in the sequence) from a trust anchor certification
authority to the certificate being validated, and that the resource authority to the certificate being validated, and that the resource
extensions in this certificate sequence from the trust anchor's extensions in this certificate sequence from the trust anchor's
issued certificate to the certificate being validated form a sequence issued certificate to the certificate being validated form a sequence
of encompassing relationships in terms of the resources described in of encompassing relationships in terms of the resources described in
the resource extension. the resource extension.
3. Resource Certificate Fields 3. Resource Certificate Fields
A Resource Certificate is a valid X.509 v3 public key certificate, A Resource Certificate is a valid X.509 v3 public key certificate,
consistent with the PKIX profile [RFC5280], containing the fields consistent with the PKIX profile [RFC5280], containing the fields
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Issuer. Issuer.
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
both the Certificate Authority and relying parties, indicating that
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 8, line 29 skipping to change at page 8, line 24
certificate that will be used to validate the issued certificate. certificate that will be used to validate the issued certificate.
However, in the context of this profile, it is anticipated that a CA However, in the context of this profile, it is anticipated that a CA
may have valid grounds to issue a certificate with a validity may have valid grounds to issue a certificate with a validity
interval that exceeds the validity interval of the CA's certificate. interval that exceeds the validity interval of the 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 2048
bits. In the context of certifying resources it is recommended that bits.
the key size of keys that are intended to be used at the apex of a
certificate issuance hierarchy, and their immediate subordinates,
SHOULD use a minimum key size of 2048 bits. Immediate subordinates
of these certificates, when used in the context of continued levels
of high trust, SHOULD use a minimum key size of 2048 bits.
In the application of this profile to certification of public number
resources, it would be consistent with this recommendation that the
Regional Internet Registries use a key size of 2048 bits in their
issued certificates, and that their immediate subordinate certificate
authorities also use a key size of 2048 bits. All other subordinate
certificates MAY use a key size of 1024 bits.
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 CA and relying parties, indicating that care should be taken
when deciding to use larger than the minimum key size. when deciding to use larger than the minimum key size.
3.9. Resource Certificate Version 3 Extension Fields 3.9. Resource Certificate Version 3 Extension Fields
As noted in Section 4.2 of [RFC5280], each extension in a certificate As noted in Section 4.2 of [RFC5280], each extension in a certificate
is designated as either critical or non-critical. A certificate- is designated as either critical or non-critical. A certificate-
using system MUST reject the certificate if it encounters a critical using system MUST reject the certificate if it encounters a critical
skipping to change at page 11, line 6 skipping to change at page 10, line 36
certificates issued by this CA issuer using a given key pair. certificates issued by this CA issuer using a given key pair.
The sequence of distributionPoint values MUST contain only a single The sequence of distributionPoint values MUST contain only a single
DistributionPointName set. The DistributionPointName set MAY contain DistributionPointName set. The DistributionPointName set MAY contain
more than one URI value. An RSYNC URI MUST be present in the more than one URI value. An RSYNC URI MUST be present in the
DistributionPointName set, and reference the most recent instance of DistributionPointName set, and reference the most recent instance of
this issuer's certificate revocation list. Other access form URIs this issuer's certificate revocation list. Other access form URIs
MAY be used in addition to the RSYNC URI. MAY be used in addition to the RSYNC URI.
This extension MUST be present and it is non-critical. There is one This extension MUST be present and it is non-critical. There is one
exception; where a CA distributes its public key in the form of a exception, namely where a CA distributes its public key in the form
"self-signed" certificate, the CRLDP MUST be omitted. of a "self-signed" certificate, the CRLDP MUST be omitted.
3.9.6. Authority Information Access 3.9.6. Authority Information Access
This field (AIA) identifies the point of publication of the This field (AIA) identifies the point of publication of the
certificate that is issued by the issuer's immediate superior CA, certificate that is issued by the issuer's immediate superior CA,
where this certificate's issuer is the subject. In this profile a where this certificate's issuer is the subject. In this profile a
single reference object to publication location of the immediate single reference object to publication location of the immediate
superior certificate MUST be used, except in the case where a CA superior certificate MUST be used, except in the case where a CA
distributes its public key in the form of a "self-signed" distributes its public key in the form of a "self-signed"
certificate, the AIA field SHOULD be omitted. certificate, in which case the AIA field SHOULD be omitted.
This profile uses a URI form of object identification. The preferred This profile uses a URI form of object identification. The preferred
URI access mechanisms is "rsync", and an RSYNC URI MUST be specified URI access mechanisms is "rsync", and an RSYNC URI MUST be specified
with an accessMethod value of id-ad-caIssuers. The URI MUST with an accessMethod value of id-ad-caIssuers. The URI MUST
reference the point of publication of the certificate where this reference the point of publication of the certificate where this
issuer is the subject (the issuer's immediate superior certificate). issuer is the subject (the issuer's immediate superior certificate).
Other access method URIs referencing the same object MAY also be Other access method URIs referencing the same object MAY also be
included in the value sequence of this extension. included in the value sequence of this extension.
When an Issuer re-issues a CA certificate, the subordinate When an Issuer re-issues a CA certificate, the subordinate
skipping to change at page 11, line 40 skipping to change at page 11, line 21
issuance necessarily implies a requirement to re-issue all issuance necessarily implies a requirement to re-issue all
subordinate certificates, CA Certificate issuers SHOULD use a subordinate certificates, CA Certificate issuers SHOULD use a
persistent URL name scheme for issued certificates. This implies persistent URL name scheme for issued certificates. This implies
that re-issued certificates overwrite previously issued certificates that re-issued certificates overwrite previously issued certificates
to the same subject in the publication repository, and use the same to the same subject in the publication repository, and use the same
publication name as previously issued certificates. In this way publication name as previously issued certificates. In this way
subordinate certificates can maintain a constant AIA field value and subordinate certificates can maintain a constant AIA field value and
need not be re-issued due solely to a re-issue of the superior need not be re-issued due solely to a re-issue of the superior
certificate. The issuers' policy with respect to the persistence of certificate. The issuers' policy with respect to the persistence of
name objects of issued certificates MUST be specified in the Issuer's name objects of issued certificates MUST be specified in the Issuer's
Certificate Practice Statement. Certification Practice Statement.
This extension is non-critical. This extension is non-critical.
3.9.7. Subject Information Access 3.9.7. Subject Information Access
This field (SIA) identifies the location of information and services This field (SIA) identifies the location of information and services
relating to the subject of the certificate in which the SIA extension relating to the subject of the certificate in which the SIA extension
appears. Where the Subject is a CA in this profile, this information appears. Where the Subject is a CA in this profile, this information
and service collection will include all current valid certificates and service collection will include all current valid certificates
that have been issued by this subject that are signed with the that have been issued by this subject that are signed with the
skipping to change at page 13, line 17 skipping to change at page 12, line 47
CA certificates MUST include in the SIA an accessMethod OID of id-ad- CA certificates MUST include in the SIA an accessMethod OID of id-ad-
rpkiManifest, where the associated accessLocation refers to the rpkiManifest, where the associated accessLocation refers to the
subject's published manifest object as an object URL. subject's published manifest object as an object URL.
When an EE certificate is intended for use in verifying multiple When an EE certificate is intended for use in verifying multiple
objects, EE certificate MUST include in the SIA an access method OID objects, EE certificate MUST include in the SIA an access method OID
of id-ad-rpkiManifest, where the associated access location refers to of id-ad-rpkiManifest, where the associated access location refers to
the publication point of the objects that are verified using this EE the publication point of the objects that are verified using this EE
certificate. certificate.
When an EE certificate is used to sign a single object, the EE When an EE certificate is used to sign a single published object, the
certificate MUST include in the SIA an access method OID of id-ad- EE certificate MUST include in the SIA an access method OID of id-ad-
signedObject, where the associated access location refers to the signedObject, where the associated access location refers to the
publication point of the single object that is verified using this EE publication point of the single object that is verified using this EE
certificate. In this case, the SIA MUST NOT include the access certificate. In this case, the SIA MUST NOT include the access
method OID of id-ad-rpkiManifest. method OID of id-ad-rpkiManifest.
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
skipping to change at page 15, line 39 skipping to change at page 15, line 22
For each revoked resource certificate only the following fields MUST For each revoked resource certificate only the following fields MUST
be present. No CRL entry extensions are supported in this profile, be present. No CRL entry extensions are supported in this profile,
and CRL entry extensions MUST NOT be present in a CRL. and CRL entry extensions MUST NOT be present in a CRL.
4.6.1. Serial Number 4.6.1. Serial Number
The issuer's serial number of the revoked certificate. The issuer's serial number of the revoked certificate.
4.6.2. Revocation Date 4.6.2. Revocation Date
The time the certificate was revoked. This time SHOULD NOT be a The time the certificate was revoked. This time MUST NOT be a future
future date. The value of this field MUST be encoded as UTCTime for date. The value of this field MUST be encoded as UTCTime for dates
dates through the year 2049, and MUST be encoded as GeneralizedTime through the year 2049, and MUST be encoded as GeneralizedTime for
for dates in the year 2050 or later. dates in the year 2050 or later.
4.7. CRL Extensions 4.7. CRL Extensions
The X.509 v2 CRL format allows extensions to be placed in a CRL. The The X.509 v2 CRL format allows extensions to be placed in a CRL. The
following extensions are supported in this profile, and MUST be following extensions are supported in this profile, and MUST be
present in a CRL. present in a CRL.
4.7.1. Authority Key Identifier 4.7.1. Authority Key Identifier
The authority key identifier extension provides a means of The authority key identifier extension provides a means of
skipping to change at page 19, line 42 skipping to change at page 19, line 25
issued certificate. issued certificate.
The Path Length Constraint is not supported in this Resource The Path Length Constraint is not supported in this Resource
Certificate Profile, and this field MUST be omitted in this Certificate Profile, and this field MUST be omitted in this
profile. profile.
The CA MAY honour the SubjectType CA bit set to on. If this bit The CA MAY honour the SubjectType CA bit set to on. If this bit
is set, then it indicates that the Subject is allowed to issue is set, then it indicates that the Subject is allowed to issue
resource certificates within this overall framework. resource certificates within this overall framework.
The CA MAY honour the SubjectType CA bit set to off (End Entity The CA MUST honour the SubjectType CA bit set to off (End Entity
certificate request), in which case the corresponding end entity certificate request), in which case the corresponding end entity
certificate will not contain a BasicConstraints extension. certificate will not contain a BasicConstraints extension.
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.
skipping to change at page 20, line 45 skipping to change at page 20, line 26
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 A request for a CA certificate MUST include in the SIA of the
request the id-ad-caRepository access method, and also MUST request the id-ad-caRepository access method, and also MUST
include in the SIA of the request the accessMethod OID of id-ad- include in the SIA of the request the accessMethod OID of id-ad-
rpkiManifest, where the associated accessLocation refers to the rpkiManifest, where the associated accessLocation refers to the
subject's published manifest object as an object URL. subject's published manifest object as an object URL.
This field MAY be present when the subject is a EE. If it is
present the field 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 Certificate Request. If it is not present the CA
SHOULD honor this request and omit the SIA from the issued
certificate. If the CA is not able to honor the request to omit
the SIA, then the CA MUST reject the Certificate Request.
When an EE certificate is intended for use in verifying multiple When an EE certificate is intended for use in verifying multiple
objects, the certificate request for the EE certificate MUST objects, the certificate request for the EE certificate MUST
include in the SIA of the request an access method OID of id-ad- include in the SIA of the request an access method OID of id-ad-
signedObjectRepository, and also MUST include in the SIA of the signedObjectRepository, and also MUST include in the SIA of the
request an access method OID of id-ad-rpkiManifest, where the request an access method OID of id-ad-rpkiManifest, where the
associated access location refers to the publication point of the associated access location refers to the publication point of the
objects that are verified using this EE certificate. objects that are verified using this EE certificate.
When an EE certificate is used to sign a single object, the When an EE certificate is used to sign a single published object,
certificate request for the EE certificate MUST include in the SIA the certificate request for the EE certificate MUST include in the
of the request an access method OID of id-ad-signedObject, where SIA of the request an access method OID of id-ad-signedObject,
the associated access location refers to the publication point of where the associated access location refers to the publication
the single object that is verified using this EE certificate, and point of the single object that is verified using this EE
MUST NOT include an id-ad-rpkiManifest access method OID in the certificate, and MUST NOT include an id-ad-rpkiManifest access
SIA of the request. method OID in the SIA of the request.
In the case when the EE certificate is to be used exclusively to
sign one or more unpublished objects, such that the all signed
objects will not be published in any RPKI repository, then the SIA
SHOULD be omitted from 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
skipping to change at page 22, line 5 skipping to change at page 21, line 45
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 6.1. Resource Extension Validation
The trust model that may be used in the resource certificate
framework in the context of validation of assertions of public number
resources in public-use contexts is one that readily maps to a top-
down delegated CA model that mirrors the delegation of resources from
a registry distribution point to the entities that are the direct
recipients of these resources. Within this trust model these
recipient entities may, in turn, operate a registry and perform
further allocations or assignments. This is a strict hierarchy, in
that any number resource and a corresponding recipient entity has
only one 'parent' issuing registry for that number resource (i.e.
there is always a unique parent entity for any resource and
corresponding entity), and that the issuing registry is not a direct
or indirect subordinate recipient entity of the recipient entity in
question (i.e. no loops in the model).
The more general consideration is that selection of a trust anchor CA
is a task undertaken by relying parties. The structure of the
resource certificate profile admits potentially the same variety of
trust models as the PKIX profile. There is only one additional
caveat on the general applicability of trust models and PKIX
frameworks, namely that in forming a validation path to a trust
anchor CA, the sequence of certificates MUST preserve the resource
extension validation property, as described in Section 6.2, and the
validation of the first certificate in the validation path not only
involves the verification that the certificate was issued by a trust
anchor CA, but also that the resource set described in the
certificate MUST be encompassed by the trust anchor CA's resource
set, as described in Section 6.2.
The trust anchor information, describing a CA that serves as a trust
anchor, includes the following:
1. the trusted issuer name,
2. the trusted public key algorithm,
3. the trusted public key,
4. optionally, the trusted public key parameters associated with the
public key, and
5. a resource set, consisting of a set of IPv4 resources, IPv6
resources and AS number resources.
The trust anchor information may be provided to the path processing
procedure in the form of a self-signed certificate.
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 38 skipping to change at page 22, line 36
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 6.2. Resource Certification 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 'Certification 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
2. The current time lies within the certificate's Validity From and 2. The current time lies within the certificate's Validity From and
To values. To values.
3. The certificate contains all fields that MUST be present and 3. The certificate contains all fields that MUST be present and
contains field values as specified in this profile for all field contains field values as specified in this profile for all field
values that MUST be present. values that MUST be present.
4. No field value that MUST NOT be present in this profile is 4. No field value that MUST NOT be present in this profile is
present in the certificate. present in the certificate.
skipping to change at page 24, line 23 skipping to change at page 23, line 21
5. The Issuer has not revoked the certificate by placing the 5. The Issuer has not revoked the certificate by placing the
certificate's serial number on the Issuer's current Certificate certificate's serial number on the Issuer's current Certificate
Revocation List, and the Certificate Revocation List is itself Revocation List, and the Certificate Revocation List is itself
valid. valid.
6. That the resource extension data is "encompassed" by the resource 6. That the resource extension data is "encompassed" by the resource
extension data contained in a valid certificate where this Issuer extension data contained in a valid certificate where this Issuer
is the Subject (the previous certificate in the ordered sequence) is the Subject (the previous certificate in the ordered sequence)
7. The Certificate Path originates with a certificate issued by a 7. The Certification Path originates with a certificate issued by a
trust anchor, and there exists a signing chain across the trust anchor, and there exists a signing chain across the
Certificate Path where the Subject of Certificate x in the Certification Path where the Subject of Certificate x in the
Certificate Path matches the Issuer in Certificate x+1 in the Certification Path matches the Issuer in Certificate x+1 in the
Certificate Path. Certification Path.
A certificate validation algorithm may perform these tests in any A certificate validation algorithm may perform these tests in any
chosen order. chosen order.
Certificates and CRLs used in this process may be found in a locally Certificates and CRLs used in this process may be found in a locally
maintained cache, maintained by a regular top-down synchronization maintained cache, maintained by a regular top-down synchronization
pass, seeded with the CAs who operate at the apex of the resource pass, seeded with the CAs who operate at the apex of the resource
distribution hierarchy, via reference to Issued certificates and distribution hierarchy, via reference to issued certificates and
their SIA fields as forward pointers, plus the CRLDP. Alternatively, their SIA fields as forward pointers, plus the CRLDP. Alternatively,
validation may be performed using a bottom-up process with on-line validation may be performed using a bottom-up process with on-line
certificate access using the AIA and CRLDP pointers to guide the certificate access using the certificate's AIA and CRLDP pointers to
certificate retrieval process. guide the certificate retrieval process for each certificate's
immediate superior CA certificate.
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 certification
validation process in order to avoid some of the issues associated path validation process in order to avoid some of the issues
with attempts to validate such structures. It is suggested that associated with attempts to validate such structures. It is
implementations of Resource Certificate validation MAY halt with a suggested that implementations of Resource Certificate validation MAY
validation failure if the certificate path length exceeds a pre- halt with a validation failure if the certification path length
determined configuration parameter. exceeds a pre-determined configuration parameter.
6.3. Trust Anchors for Resource Certificates
The trust model that may be used in the resource certificate
framework in the context of validation of assertions of public number
resources in public-use contexts is one that readily maps to a top-
down delegated CA model that mirrors the delegation of resources from
a registry distribution point to the entities that are the direct
recipients of these resources. Within this trust model these
recipient entities may, in turn, operate a registry and perform
further allocations or assignments. This is a strict hierarchy, in
that any number resource and a corresponding recipient entity has
only one 'parent' issuing registry for that number resource (i.e.
there is always a unique parent entity for any resource and
corresponding entity), and that the issuing registry is not a direct
or indirect subordinate recipient entity of the recipient entity in
question (i.e. no loops in the model).
The more general consideration is that selection of one or more trust
anchor CAs is a task undertaken by relying parties. The structure of
the resource certificate profile admits potentially the same variety
of trust models as the PKIX profile. There is only one additional
caveat on the general applicability of trust models and PKIX
frameworks, namely that in forming a validation path to a trust
anchor CA, the sequence of certificates MUST preserve the resource
extension validation property, as described in Section 6.1, and the
validation of the first certificate in the validation path not only
involves the verification that the certificate was issued by a trust
anchor CA, but also that the resource set described in the
certificate MUST be encompassed by the trust anchor CA's resource
set, as described in Section 6.1.
The trust anchor information, describing a CA that serves as a trust
anchor, includes the following:
1. the trusted issuer name,
2. the trusted public key algorithm,
3. the trusted public key,
4. optionally, the trusted public key parameters associated with the
public key, and
5. a resource set, consisting of a set of IPv4 resources, IPv6
resources and AS number resources.
The trust anchor information may be provided to the path processing
procedure in the form of a self-signed certificate.
6.3.1. Distribution Format of Nominated Trust Anchor Material
In the RPKI the hierarchical certificate framework corresponds to the
hierarchies of the resource distribution function. In consideration
of this, it is reasonable to nominate to relying parties a default
set of trust anchors for the RPKI that correspond to the entities who
operate at the upper levels of the associated resource allocation
hierarchy. The corresponding nominated trust anchor CA(s) should
therefore map, in some fashion, to apex point(s) of the hierarchical
resource distribution structure.
The characteristics of a trust anchor framework for the RPKI includes
the following considerations:
o The entity or entities that issue proposed trust anchor material
for the RPKI should be as close as possible to the apex of the
associated resource distribution hierarchy.
o Such trust anchor material should be long-lived. As it can be
reasonably anticipated that default nominated trust anchor
material would be distributed with relying party validation
software, the implication is that the distributed default
nominated trust anchor material should remain constant for
extended time intervals.
o It is a poor trust model when any entity that issues putative
trust anchor material is forced to be authoritative over
information or actions of which the entity has no direct
knowledge, nor is in possession of a current definitive record of
such actions. Entities who propose themselves in a role of a
trust anchor issuer should be able to point to corroborative
material supporting the assertion that they are legitimate
authorities for the information where they are representing
themselves as a potential trust anchor for relying parties.
An entity offering itself as a putative RPKI trust anchor for a part
of the RPKI is required to regularly publish a RPKI CA certificate at
a stable URL, and to publish a packaged form of this URL as
distributed trust anchor material, as follows:
o The entity issues a RPKI self-signed "root" CA certificate that is
used as the apex of a RPKI certificate issuance hierarchy. This
certificate MUST have the keyCertSign sign bit set in the key
usage extension, and the CA flag set in the basic constraints
extension, no AIA value and no CRLDP value. This certificate MUST
be reissued at regular intervals prior to expiration of the
current RPKI self-signed certificate, and MUST be reissued upon
any change in the resource set that has been allocated to the
entity who is operating this CA. The validity interval of this
certificate should reflect the anticipated period of the regular
RPKI certificate re-issuance.
o The entity maintains a "trust anchor material" key pair.
o The entity issues a PKI self-signed CA certificate [RFC5280] using
the trust anchor material key pair, where the subject public key
in the certificate is the public key of the trust anchor material
key pair and the certificate is signed by the corresponding
private key of trust anchor material key pair. This certificate
MUST have the keyCertSign sign bit set in the key usage extension,
and the CA flag set in the basic constraints extension, no AIA
value and no CRLDP value. The validity period of this certificate
shold be very long-lived, with the period to be defined by the
entity. The SIA of this certificate references a publication
point where the CRL and the subordinate product of this
certificate are published.
o The PKI CA issues a subordinate PKI EE certificate with a validity
period identical to the validity period of the RPKI self-signed
"root" CA certificate. This PKI EE certificate MUST have the
digitalSignature bit set, and this MUST be the only bit set to
TRUE. The CA flag set MUST be cleared in the basic constraints
extension. The validity period of this certificate should be
aligned to the validity period of the RPKI self-signed "root" CA
certificate.
o The PKI CA regularly issues a CRL. The CRL issuance cycle SHOULD
be shorter than the validity period for the RPKI self-signed
"root" certificate.
o Each time the RPKI self-signed "root" certificate is re-issued, or
prior to the expiration of the PKI EE certificate, the PKI CA
generates a Cryptographic Message Syntax (CMS) [RFC3852] signed-
data object, where the payload is the RPKI self-signed "root"
certificate. The object is CMS-signed with the private key of the
PKI EE certificate. The PKI EE certificate is included as a CMS
signed attribute in the CMS object. The PKI self-signed CA
certificate and the asociated CRL are not to be included in the
CMS object. The format of the CMS object is specified in
Appendix C. The CMS object is published at the location
referenced in the SIA of the PKI self-signed CA certificate.
o The entity publically distributes the PKI self-signed CA
certificate as its proposed trust anchor material.
o The entity publishes the modulus and exponent of the "trust anchor
material" public key using a trusted form of publication that
allows the entity's identity to be validated and the retrieval of
the published information to be secured.
Relying Parties can assemble the default trust anchor collection by
using the distributed PKI self-signed CA certificate for each
nominated trust anchor:
o The public key in the self-signed CA PKI certificate can be
validated using the modulus and exponent values as retrieved from
the entity's publication point using a secured retrieval
operation.
o The PKI CA's CRL and CMS objects can be retrieved from the
publication point referenced by the SIA in the PKI CA certificate.
o The CRL can be verified against the PKI CA certificate.
o The CMS signature can be verified using the included PKI EE
certificate together with the retrieved CRL and the self-signed
PKI CA certificate.
o The relying party can then load the enclosed RPKI self-signed CA
certificate as a trust anchor for RPKI validation for those
resources described in the resource extension of this RPKI
certificate.
Relying Parties should perform this retrieval and validation
operation at intervals no less frequent than the nextUpdate time of
the published CRL, and should perform the retrieval operation prior
to the expiration of the PKI EE certificate, or upon revocation of
the PKI EE certificate that was used to sign the CMS object that held
the relying party's current RPKI self-signed CA certificate.
If a trust anchor CA wishes to perform an issuance of the RPKI self-
signed CA certificate outside the established update cycle time, it
can notify relying parties of this by revising the nextUpdate time of
the PKI CA's CRL to a shorter interval, issuing a new PKI CA
certificate and a new CMS object with the new RPKI self-signed CA
certificate, and revoking the old PKI EE certificate at the
nextUpdate time in the next issued CRL. This revocation will provide
an indication to relying parties to perform the retrieval operation
ofthe RPKI self-signed CA certificate at a time earlier than the
normal update cycle time.
7. Security Considerations 7. Security Considerations
The Security Considerations of [RFC5280] and [RFC3779]apply to The Security Considerations of [RFC5280] 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 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 document.]
9. 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 and David Cooper.
10. References 10. Draft Review Notes
10.1. Normative References The following review comments are unresolved at present:
1. Use of additional non-critical extensions:
Section 3: "Unless specifically noted as being OPTIONAL, all the
fields listed here MUST be present, and any other field MUST NOT
appear in a conforming Resource Certificate."
The review comment was that certificate profile should permit
the use of non-critical extensions. The scenario nominatedwas
one in which a CA product added non-critical extensions to a
certificate that would not affect a relying party's decision
to accept the certificate, regardless of whether the relying
party could process the extension. It was noted that it may
be possible to configure these CA products so that they do not
include these extensions in the certificates, but that is a
question that would need to be answered by someone more
familiar with particular CA products that add non-critical
extensions that identify the CA product used to mint the
certificate.
The rationale for not permitting non-critical extensions is
that it was not seen as being appropriate to be in the
position of having certificates with extensions which relying
parties may see as valid, but contain extensions that, were
the relying party to understand the extension, would
contradict or qualify in some way this original validity. The
profile takes the position of minimialism over extensibility,
taking the approach of nomination of a specific goal for the
PKI, namely to construct a PKI that precisely matches the IP
number resource allocation structure, and then defining a
certificate profile that was precisely aligned to this
objective. If there is some need or requirement to use the
RFC3779 extensions in contexts other than assertions about
right of use of resources by virtue of an allocation action,
that make use of other extensions than are specified here,
then the authors suggest that it would be more appropriate to
define a distinct profile to fulfil this function.
It is proposed to leave the text as is.
2. CRL Scope:
Section 3.9.5: In this profile, the scope of the CRL is specified
to be all certificates issued by this CA issue using a given key
pair.
The review comment was that the scope of a CRL must be all
certificates issued by the issuing CA unless the CRL includes
an issuingDistributionPoint extension. So, if the scope of
CRLs is to be limited to certificates signed with a given key
pair, then the profile must either require inclusion of the
issuingDistributionPoint extension in CRLs or forbid CAs from
performing key rollover. The latter option may be implemented
by having issuers change names whenever changing the key pair
used to sign certificates.
It is proposed to drop the scope restriction, and remove the
text in Section 3.9.5.
3. Name Uniqueness:
Section 3.5 stipulates that subject names must simply be unique
per issuer, while X.509 requires that names must be globally
unique.
The review comment was that the Security Considerations
section in RFC5280 states: " While X.509 mandates that names
be unambiguous, there is a risk that two unrelated authorities
will issue certificates and/or CRLs under the same issuer
name." X.501 states that a (directory) name shall be
unambiguous, in that it denotes just one object, but need not
be unique, in that it not be the only name that unambiguously
denotes the object, and that for every name form used in the
GeneralName type, there shall be a name registration system
that ensures that any name used unambiguously identifies one
entity to both certificate issuer and certificate users. The
review comment is that problem with a less stringent
requirement is that if two CAs issue certificates and CRLs
under the same name, there is a risk that a relying party will
use a CRL issued by one of these CAs to determine the status
of a certificate issued by the other CA.
The rationale for using a name this is unique per issuer is
that the RPKI is strictly hierarchical, the repository
publication structure is structured on a per-CA basis, the
CRLDP is mandatory to include in all RPKI certificates (except
apex self-signed certs) so that each certificate points
directly to the associated CRL that can revoke it, the
contextof the use of names is within a per issuer context, a
single entity may hold resources from multiple sources and the
RPKI name space is unconstrained such that it is neither
coordinated nor restricted to be structured in any fashion,
and the RPKI is not attesting a name or an identity but a
right to use resources. Because the context of the use of
names in the RPKI is one that positions names within a strict
hierarchy, then the essential name attribute of unambiguity is
achieved in the RPKI when names are specified to be unique per
issuer.
It is proposed not to alter the existing specification of
uniqueness of names on a per-issuer basis.
11. 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.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
10.2. Informative References [X.509] ITU-T, "Recommendation X.509: The Directory -
Authentication Framework", 2000.
11.2. Informative References
[ID.SIDR-MANIFESTS] [ID.SIDR-MANIFESTS]
Austein, R., Huston, G., Kent, S., and M. Lepinski, Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure", "Manifests for the Resource Public Key Infrastructure",
Work in progress: Internet Work in progress: Internet
Drafts draft-ietf-sidr-rpki-manifests-00.txt, Drafts draft-ietf-sidr-rpki-manifests-00.txt,
January 2008. January 2008.
[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,
skipping to change at page 30, line 5 skipping to change at page 35, line 5
d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12: d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12:
cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8: cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8:
c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c: c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c:
d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a: d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a:
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
Appendix C. Cryptographic Message Syntax Profile for RPKI Trust Anchor
Material
Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust
Anchor Object (RTA) is a type of signed-data object. The general
format of a CMS object is:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
As a RTA is a signed-data object, it uses the corresponding OID,
1.2.840.113549.1.7.2. [RFC3852].
C.1. Signed-Data ContentType
According to the CMS specification, the signed-data content type
shall have ASN.1 type SignedData:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
The elements of the signed-data content type are as follows:
version
The version is the syntax version number. It MUST be 3,
corresponding to the signerInfo structure having version
number 3.
digestAlgorithms
The digestAlgorithms set MUST include only SHA-256, the OID
for which is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST
NOT contain any other algorithms.
encapContentInfo
This element is defined in Appendix C.1.1.
certificates
The certificates element MUST be included and MUST contain
only the single PKI EE certificate needed to validate this
CMS Object. The CertificateSet type is defined in section
10 of [RFC3852]
crls
The crls element MUST be omitted.
signerInfos
This element is defined in Appendix C.1.2.
C.1.1. encapContentInfo
encapContentInfo is the signed content, consisting of a content type
identifier and the content itself.
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
The elements of this signed content type are as follows:
eContentType
The ContentType for an RTA is defined as id-ct-
RPKITrustAnchor and has the numerical value of
1.2.840.113549.1.9.16.1.33.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 }
eContent
The content of an RTA is an RPKI self-signed CA certificate.
It is formally defined as:
id-ct-RPKITrustAnchor ::= Certificate
The definition of Certificate is taken from [X.509].
C.1.2. signerInfos
SignerInfo is defined under CMS as:
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
The content of the SignerInfo element are as follows:
version
The version number MUST be 3, corresponding with the choice
of SubjectKeyIdentifier for the sid.
sid
The sid is defined as:
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
For a RTA, the sid MUST be a SubjectKeyIdentifier.
digestAlgorithm
The digestAlgorithm MUST be SHA-256, the OID for which is
2.16.840.1.101.3.4.2.1. [RFC4055]
signedAttrs
The signedAttrs element is defined as:
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
The signedAttr element MUST be present and MUST include the
content-type and message-digest attributes. The signer MAY
also include the signing-time signed attribute, the binary-
signing-time signed attribute, or both signed attributes.
Other signed attributes that are deemed appropriate MAY also
be included. The intent is to allow additional signed
attributes to be included if a future need is identified.
This does not cause an interoperability concern because
unrecognized signed attributes are ignored by the relying
party.
The signedAttr MUST include only a single instance of any
particular attribute. Additionally, even though the syntax
allows for a SET OF AttributeValue, in a RTA the attrValues
must consist of only a single AttributeValue.
ContentType Attribute
The ContentType attribute MUST be present. The
attrType OID for the ContentType attribute is
1.2.840.113549.1.9.3.
The attrValues for the ContentType attribute in
a RTA MUST be 1.2.840.113549.1.9.16.1.24
(matching the eContentType in the
EncapsulatedContentInfo).
MessageDigest Attribute
The MessageDigest attribute MUST be present.
The attrType OID for the MessageDigest Attribute
is 1.2.840.113549.1.9.4.
The attrValues for the MessageDigest attribute
contains the output of the digest algorithm
applied to the content being signed, as
specified in Section 11.1 of [RFC3852].
SigningTime Attribute
The SigningTime attribute MAY be present. If it
is present it MUST be ignored by the relying
party. The presence of absence of the
SigningTime attribute in no way affects the
validation of the RTA. The attrType OID for the
SigningTime attribute is 1.2.840.113549.1.9.5.
The attrValues for the SigningTime attribute is
defined as:
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
The Time element specifies the time, based on
the local system clock, at which the digital
signature was applied to the content.
BinarySigningTime Attribute
The The BinarySigningTime attribute MAY be
present. If it is present it MUST be ignored by
the relying party. The presence of absence of
the BinarySigningTime attribute in no way
affects the validation of the RTA. The attrType
OID for the SigningTime attribute is
1.2.840.113549.1.9.16.2.46.
The attrValues for the SigningTime attribute is
defined as:
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
The BinaryTime element specifies the time, based
on the local system clock, at which the digital
signature was applied to the content.
signatureAlgorithm
The signatureAlgorithm MUST be RSA (rsaEncryption), the OID
for which is 1.2.840.113549.1.1.1.q
signature
The signature value is defined as:
SignatureValue ::= OCTET STRING
The signature characteristics are defined by the digest and
signature algorithms.
unsignedAttrs
unsignedAttrs MUST be omitted.
C.2. RTA Validation
Before a relying party can use an RTA, the relying party must first
validate the RTA by performing the following steps.
1. Verify that the RTA syntax complies with this specification. In
particular, verify the following:
a. The contentType of the CMS object is SignedData (OID
1.2.840.113549.1.7.2).
b. The version of the SignedData object is 3.
c. The digestAlgorithm in the SignedData object is SHA-256 (OID
2.16.840.1.101.3.4.2.1).
d. The certificates field in the SignedData object is present
and contains an EE certificate whose Subject Key Identifier
(SKI) matches the sid field of the SignerInfo object.
e. The crls field in the SignedData object is omitted.
f. The eContentType in the EncapsulatedContentInfo is id-ct-
RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.[TBD])
g. The version of the SignerInfo is 3.
h. The digestAlgorithm in the SignerInfo object is SHA-256 (OID
2.16.840.1.101.3.4.2.1).
i. The signatureAlgorithm in the SignerInfo object is RSA (OID
1.2.840.113549.1.1.1).
j. The signedAttrs field in the SignerInfo object is present and
contains both the ContentType attribute (OID
1.2.840.113549.1.9.3) and the MessageDigest attribute (OID
1.2.840.113549.1.9.4).
k. The unsignedAttrs field in the SignerInfo object is omitted.
2. Use the public key in the EE certificate to verify the signature
on the RTA.
3. Verify that the EE certificate is a valid end-entity certificate
in the Trust Anchor PKI by validating that the PKI CA certificate
issued this EE certificate, and the PKI CA's CRL has not revoked
the EE certificate, and that the PKI CA's CRL is valid.
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 (2008). 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
 End of changes. 46 change blocks. 
151 lines changed or deleted 682 lines changed or added

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