< draft-ietf-sidr-res-certs-12.txt   draft-ietf-sidr-res-certs-13.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: March 10, 2009 APNIC Expires: March 23, 2009 APNIC
September 6, 2008 September 19, 2008
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-12 draft-ietf-sidr-res-certs-13
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 March 10, 2009. This Internet-Draft will expire on March 23, 2009.
Copyright Notice
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-of-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.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Describing Resources in Certificates . . . . . . . . . . . . . 5 2. Describing Resources in Certificates . . . . . . . . . . . . . 5
3. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . 9
3.9.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . 10 3.9.6. Authority Information Access . . . . . . . . . . . . . 11
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 . . . . . . . . . 13 4. Resource Certificate Revocation List Profile . . . . . . . . . 14
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Issuer Name . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. This Update . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Next Update . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 15 4.6. Revoked Certificate List . . . . . . . . . . . . . . . . . 15
4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 15 4.6.1. Serial Number . . . . . . . . . . . . . . . . . . . . 15
4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 15 4.6.2. Revocation Date . . . . . . . . . . . . . . . . . . . 15
4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 15 4.7. CRL Extensions . . . . . . . . . . . . . . . . . . . . . . 15
4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 15 4.7.1. Authority Key Identifier . . . . . . . . . . . . . . . 15
4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 15 4.7.2. CRL Number . . . . . . . . . . . . . . . . . . . . . . 16
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 . . 17 5.2.1. CRMF Resource Certificate Request Template Fields . . 18
5.2.2. Resource Certificate Request Control Fields . . . . . 18 5.2.2. Resource Certificate Request Control Fields . . . . . 19
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. Resource Extension Validation . . . . . . . . . . . . . . 21 6.1. Resource Extension Validation . . . . . . . . . . . . . . 22
6.2. Resource Certification Path Validation . . . . . . . . . . 22 6.2. Resource Certification Path Validation . . . . . . . . . . 23
6.3. Trust Anchors for Resource Certificates . . . . . . . . . 24 6.3. Trust Anchors for Resource Certificates . . . . . . . . . 24
6.3.1. Distribution Format of Nominated Trust Anchor 6.3.1. Distribution Format of Nominated Trust Anchor
Material . . . . . . . . . . . . . . . . . . . . . . . 25 Material . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Draft Review Notes . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Example Resource Certificate . . . . . . . . . . . . 32 Appendix A. Example Resource Certificate . . . . . . . . . . . . 33
Appendix B. Example Certificate Revocation List . . . . . . . . . 34 Appendix B. Example Certificate Revocation List . . . . . . . . . 35
Appendix C. Cryptographic Message Syntax Profile for RPKI Appendix C. Cryptographic Message Syntax Profile for RPKI
Trust Anchor Material . . . . . . . . . . . . . . . . 35 Trust Anchor Material . . . . . . . . . . . . . . . . 37
C.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 35 C.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 37
C.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 36 C.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 38
C.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 37 C.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 39
C.2. RTA Validation . . . . . . . . . . . . . . . . . . . . . . 39 C.2. RTA Validation . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines a standard profile for X.509 certificates This document defines a standard profile for X.509 certificates
[X.509] for use in the context of certification of IP Addresses and [X.509] for use in the context of certification of IP Addresses and
AS Numbers. Such certificates are termed here "Resource AS Numbers. Such certificates are termed here "Resource
Certificates." Resource Certificates are X.509 certificates that Certificates." Resource Certificates are X.509 certificates that
conform to the PKIX profile [RFC5280], and also conform to the conform to the PKIX profile [RFC5280], and also conform to the
constraints specified in this profile. Resource Certificates attest constraints specified in this profile. Resource Certificates attest
that the issuer has granted the subject a "right-of-use" for a listed that the issuer has granted the subject a "right-of-use" for a listed
skipping to change at page 5, line 38 skipping to change at page 5, line 38
2. Describing Resources in Certificates 2. Describing Resources in Certificates
The framework for describing an association between the subject of a The framework for describing an association between the subject of a
certificate and the resources currently under the subject's control certificate and the resources currently under the subject's control
is described in [RFC3779]. is described in [RFC3779].
There are three aspects of this resource extension that are noted in There are three aspects of this resource extension that are noted in
this profile: this profile:
1. RFC 3779 notes that a resource extension SHOULD be a CRITICAL 1. RFC 3779 notes that a resource extension SHOULD be a CRITICAL
extension to the X.509 Certificate. This Resource Certificate extension to the X.509 Certificate. This Resource Certificate
profile further specifies that the use of this certificate profile further specifies that the use of this certificate
extension MUST be used in all Resource Certificates and MUST be extension MUST be used in all Resource Certificates and MUST
marked as CRITICAL. be marked as CRITICAL.
2. RFC 3779 defines a sorted canonical form of describing a resource 2. RFC 3779 defines a sorted canonical form of describing a
set, with maximal spanning ranges and maximal spanning prefix resource set, with maximal spanning ranges and maximal
masks as appropriate. All valid certificates in this profile spanning prefix masks as appropriate. All valid certificates
MUST use this sorted canonical form of resource description in in this profile MUST use this sorted canonical form of
the resource extension field. resource description in the resource extension field.
3. A test of the resource extension in the context of certificate 3. A test of the resource extension in the context of certificate
validity includes the condition that the resources described in validity includes the condition that the resources described
the immediate superior certificate in the PKI hierarchy (the in the immediate superior certificate in the PKI hierarchy
certificate where this certificate's issuer is the subject) has a (the certificate where this certificate's issuer is the
resource set (called here the "issuer's resource set") that must subject) has a resource set (called here the "issuer's
encompass the resource set of the issued certificate. In this resource set") that MUST encompass the resource set of the
context "encompass" allows for the issuer's resource set to be issued certificate. In this context "encompass" allows for
the same as, or a strict superset of, any subject's resource set. the issuer's resource set to be 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 certification 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.
skipping to change at page 7, line 23 skipping to change at page 7, line 24
immediate superior certificate. immediate superior certificate.
This field MUST be non-empty. This field MUST be non-empty.
3.5. Subject 3.5. Subject
This field identifies the entity to whom the resource has been This field identifies the entity to whom the resource has been
allocated / assigned. The value of this field is a valid X.501 name. allocated / assigned. The value of this field is a valid X.501 name.
In this profile the subject name is determined by the issuer, and In this profile the subject name is determined by the issuer, and
each distinct entity certified by the issuer MUST be identified using each distinct subordinate CA and EE certified by the issuer MUST be
a subject name that is unique per issuer. identified using a subject name that is unique per issuer.
In this context "distinct" is defined as an entity and a given key
pair. An issuer SHOULD use a a different subject name if the subject
entity or the subject entity's key pair has changed.
This field MUST be non-empty. This field MUST be non-empty.
3.6. Valid From 3.6. Valid From
The starting time at which point the certificate is valid. In this The starting time at which point the certificate is valid. In this
profile the "Valid From" time SHOULD be no earlier than the time of profile the "Valid From" time SHOULD be no earlier than the time of
certificate generation. As per Section 4.1.2.5 of [RFC5280], certificate generation. As per Section 4.1.2.5 of [RFC5280],
Certification Authorities (CAs) conforming to this profile MUST Certification Authorities (CAs) conforming to this profile MUST
always encode the certificate's "Valid From" date through the year always encode the certificate's "Valid From" date through the year
skipping to change at page 10, line 26 skipping to change at page 10, line 36
In this profile the certificate issuer is also the CRL issuer, In this profile the certificate issuer is also the CRL issuer,
implying at the CRLIssuer sub field MUST be omitted, and the implying at the CRLIssuer sub field MUST be omitted, and the
distributionPoint sub-field MUST be present. The Reasons sub-field distributionPoint sub-field MUST be present. The Reasons sub-field
MUST be omitted. MUST be omitted.
The distributionPoint MUST contain general names, and MUST NOT The distributionPoint MUST contain general names, and MUST NOT
contain a nameRelativeToCRLIssuer. The type of the general name MUST contain a nameRelativeToCRLIssuer. The type of the general name MUST
be of type URI. be of type URI.
In this profile, the scope of the CRL is specified to be all In this profile, the scope of the CRL is specified to be all
certificates issued by this CA issuer using a given key pair. certificates issued by this CA issuer.
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, namely where a CA distributes its public key in the form exception, namely where a CA distributes its public key in the form
skipping to change at page 11, line 37 skipping to change at page 11, line 52
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
subject's corresponding private key. subject's corresponding private key.
This profile uses a URI form of location identification. The This profile uses a URI form of location identification. The
preferred URI access mechanism is "rsync", and an RSYNC URI MUST be preferred URI access mechanism is "rsync", and an RSYNC URI MUST be
specified, with an access method value of id-ad-caRepository when the specified, with an access method value of id-ad-caRepository when the
subject of the certificate is a CA. The RSYNC URI must reference an subject of the certificate is a CA. The RSYNC URI MUST reference an
object collection rather than an individual object and MUST use a object collection rather than an individual object and MUST use a
trailing '/' in the URI. trailing '/' in the URI.
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-
skipping to change at page 14, line 5 skipping to change at page 14, line 17
Each CA MUST issue a version 2 Certificate Revocation List (CRL), Each CA MUST issue a version 2 Certificate Revocation List (CRL),
consistent with [RFC5280]. The CRL issuer is the CA, and no indirect consistent with [RFC5280]. The CRL issuer is the CA, and no indirect
CRLs are supported in this profile. CRLs are supported in this profile.
An entry MUST NOT be removed from the CRL until it appears on one An entry MUST NOT be removed from the CRL until it appears on one
regularly scheduled CRL issued beyond the revoked certificate's regularly scheduled CRL issued beyond the revoked certificate's
validity period. validity period.
This profile does not allow issuance of Delta CRLs. This profile does not allow issuance of Delta CRLs.
The scope of the CRL MUST be "all certificates issued by this CA The scope of the CRL MUST be "all certificates issued by this CA".
using a given key pair". The contents of the CRL are a list of all The contents of the CRL are a list of all non-expired certificates
non-expired certificates issued by the CA using a given key pair that that have been revoked by the CA.
have been revoked by the CA.
The profile allows the issuance of multiple current CRLs with
different scope by a single CA, with the scope being defined by the
key pair used by the CA.
No CRL fields other than those listed here are permitted in CRLs No CRL fields other than those listed here are permitted in CRLs
issued under this profile. Unless otherwise indicated, these fields issued under this profile. Unless otherwise indicated, these fields
MUST be present in the CRL. Where two or more CRLs issued by a MUST be present in the CRL. Where two or more CRLs issued by a
single CA with the same scope, the CRL with the highest value of the single CA with the same scope, the CRL with the highest value of the
"CRL Number" field supersedes all other CRLs issued by this CA. "CRL Number" field supersedes all other CRLs issued by this CA.
4.1. Version 4.1. Version
Resource Certificate Revocation Lists are Version 2 certificates (the Resource Certificate Revocation Lists are Version 2 certificates (the
skipping to change at page 16, line 31 skipping to change at page 16, line 41
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 5.1.1. PKCS#10 Resource Certificate Request Template Fields
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that may appear in a CertificationRequestInfo: that may appear in a CertificationRequestInfo:
Version Version
This field is mandatory and MUST have the value 0. This field is mandatory and MUST have the value 0.
Subject Subject
This field is optional. If present, the value of this field This field is optional. If present, the value of this field
SHOULD be empty, in which case the issuer MUST generate a subject SHOULD be empty, in which case the issuer MUST generate a
name that is unique in the context of certificates issued by this subject name that is unique in the context of certificates
issuer. If the value of this field is non-empty, then the CA MAY issued by this issuer. If the value of this field is non-
consider the value of this field as the subject's suggested empty, then the CA MAY consider the value of this field as the
subject name, but the CA is NOT bound to honour this suggestion, subject's suggested subject name, but the CA is NOT bound to
as the subject name MUST be unique per issuer in certificates honour this suggestion, as the subject name MUST be unique per
issued by this issuer. subordinate CA and EE in certificates issued by this issuer.
SubjectPublicKeyInfo SubjectPublicKeyInfo
This field specifies the subject's public key and the algorithm This field specifies the subject's public key and the algorithm
with which the key is used. The public key algorithm MUST be RSA, with which the key is used. The public key algorithm MUST be
and the OID for the algorithm is 1.2.840.113549.1.1.1. This field RSA, and the OID for the algorithm is 1.2.840.113549.1.1.1.
also includes a bit-string representation of the entity's public This field also includes a bit-string representation of the
key. For the RSA public-key algorithm the bit string contains the entity's public key. For the RSA public-key algorithm the bit
DER encoding of a value of PKCS #1 type RSAPublicKey. string contains the 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
Certificate Extensions. The profile for extensions in certificate X509v3 Certificate Extensions. The profile for extensions in
requests is specified in Section 5.3. certificate requests is specified in Section 5.3.
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that MAY appear in a CertificationRequest Object: that MAY appear in a CertificationRequest Object:
signatureAlgorithm signatureAlgorithm
This profile specifies a minimum of SHA-256 with RSA This profile specifies a minimum of SHA-256 with RSA
(sha256WithRSAEncryption), and allows for the use of SHA-384 or (sha256WithRSAEncryption), and allows for the use of SHA-384 or
SHA-512. Accordingly, the value for this field MUST be one of the SHA-512. Accordingly, the value for this field MUST be one of
OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } the OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 }
[RFC4055]. [RFC4055].
It is noted that larger key sizes are computationally expensive
for both the CA and relying parties, indicating that care should It is noted that larger key sizes are computationally expensive
be taken when deciding to use larger than the minimum key size. for both the CA and relying parties, indicating that care
should be taken when deciding to use larger than the minimum
key size.
5.2. CRMF Profile 5.2. CRMF Profile
This profile refines the Certificate Request Message Format (CRMF) This profile refines the Certificate Request Message Format (CRMF)
specification in [RFC4211], as it relates to Resource Certificates. specification in [RFC4211], as it relates to Resource Certificates.
A Certificate Request Message object, formatted according to the A Certificate Request Message object, formatted according to the
CRMF, is passed to a CA as the initial step in issuing a certificate. CRMF, is passed to a CA 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.2.1. CRMF Resource Certificate Request Template Fields 5.2.1. CRMF Resource Certificate Request Template Fields
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that may appear in a Certificate Request Template: that may appear in a Certificate Request Template:
Version Version
This field MAY be absent, or MAY specify the request of a Version This field MAY be absent, or MAY specify the request of a
3 Certificate. It SHOULD be omitted. Version 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
omitted in this profile. omitted in this profile.
SigningAlgorithm SigningAlgorithm
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
omitted in this profile. omitted in this profile.
Issuer Issuer
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.
Validity Validity
This field MAY be omitted. If omitted, the CA will issue a This field MAY be omitted. If omitted, the CA will issue a
Certificate with Validity dates as determined by the CA. If Certificate with Validity dates as determined by the CA. If
specified, then the CA MAY override the requested values with specified, then the CA MAY override the requested values with
dates as determined by the CA. dates as determined by the CA.
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
name that is unique in the context of certificates issued by this subject name that is unique in the context of certificates
issuer. If the value of this field is non-empty, then the CA MAY issued by this issuer. If the value of this field is non-
consider the value of this field as the subject's suggested empty, then the CA MAY consider the value of this field as the
subject name, but the CA is NOT bound to honour this suggestion, subject's suggested subject name, but the CA is NOT bound to
as the subject name MUST be unique per issuer in certificates honour this suggestion, as the subject name MUST be unique per
issued by this issuer. issuer in certificates 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 5.3.
5.2.2. Resource Certificate Request Control Fields 5.2.2. Resource Certificate Request Control Fields
The following control fields are supported in this profile: The following control fields are supported in this profile:
Authenticator Control Authenticator Control
It is noted that the intended model of authentication of the It is noted that the intended model of authentication of the
subject is a long term one, and the advice as offered in [RFC4211] subject is a long term one, and the advice as offered in
is that the Authenticator Control field be used. [RFC4211] is that the Authenticator Control field be used.
5.3. Certificate Extension Attributes in Certificate Requests 5.3. Certificate Extension Attributes in Certificate Requests
The following extensions MAY appear in a PKCS#10 or CRMF Certificate The following extensions MAY appear in a PKCS#10 or CRMF Certificate
Request. Any other extensions MUST NOT appear in a Certificate Request. Any other extensions MUST NOT appear in a Certificate
Request. This profile places the following additional constraints on Request. This profile places the following additional constraints on
these extensions.: these extensions.:
BasicConstraints BasicConstraints
If this is omitted then the CA will issue an end entity If this is omitted then the CA will issue an end entity
certificate with the BasicConstraints extension not present in the certificate with the BasicConstraints extension not present in
issued certificate. the 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
is set, then it indicates that the Subject is allowed to issue bit is set, then it indicates that the Subject is allowed to
resource certificates within this overall framework. issue resource certificates within this overall framework.
The CA MUST honour the SubjectType CA bit set to off (End Entity The CA MUST honour the SubjectType CA bit set to off (End
certificate request), in which case the corresponding end entity Entity certificate request), in which case the corresponding
certificate will not contain a BasicConstraints extension. end entity 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.
KeyUsage KeyUsage
The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign if The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign
present, as long as this is consistent with the BasicConstraints if present, as long as this is consistent with the
SubjectType sub field, when specified. BasicConstraints SubjectType sub field, when specified.
SubjectInformationAccess SubjectInformationAccess
This field MUST be present when the subject is a CA, and the field This field MUST be present when the subject is a CA, and the
value SHOULD be honoured by the CA. If the CA is not able to field value SHOULD be honoured by the CA. If the CA is not
honor the requested field value, then the CA MUST reject the able to honor the requested field value, then the CA MUST
Certificate Request. reject the Certificate Request.
This field (SIA) identifies the location of information and This field (SIA) identifies the location of information and
services relating to the subject of the certificate in which the services relating to the subject of the certificate in which
SIA extension appears. the SIA extension appears.
Where the subject is a CA in this profile, this information and Where the subject is a CA in this profile, this information and
service collection will include all current valid certificates 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
subject's corresponding private key. 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
URI MUST be specified, with an access method value of id-ad- RSYNC URI MUST be specified, with an access method value of id-
caRepository when the subject of the certificate is a CA. The ad-caRepository when the subject of the certificate is a CA.
RSYNC URI MUST reference an object collection rather than an The RSYNC URI MUST reference an object collection rather than
individual object and MUST use a trailing '/' in the URI. Other an individual object and MUST use a trailing '/' in the URI.
access method URIs that reference the same location MAY also be Other access method URIs that reference the same location MAY
included in the value sequence of this extension. The ordering of also be included in the value sequence of this extension. The
URIs in this sequence reflect the subject's relative preferences ordering of URIs in this sequence reflect the subject's
for access methods, with the first method in the sequence being relative preferences for access methods, with the first method
the most preferred by the Subject. in the sequence being 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-
rpkiManifest, where the associated accessLocation refers to the ad-rpkiManifest, where the associated accessLocation refers to
subject's published manifest object as an object URL. the subject's published manifest object as an object URL.
This field MAY be present when the subject is a EE. If it is 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 present the field value SHOULD be honoured by the CA. If the
is not able to honor the requested field value, then the CA MUST CA is not able to honor the requested field value, then the CA
reject the Certificate Request. If it is not present the CA MUST reject the Certificate Request. If it is not present the
SHOULD honor this request and omit the SIA from the issued 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 certificate. If the CA is not able to honor the request to
the SIA, then the CA MUST reject the Certificate Request. 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
objects, the certificate request for the EE certificate MUST multiple objects, the certificate request for the EE
include in the SIA of the request an access method OID of id-ad- certificate MUST include in the SIA of the request an access
signedObjectRepository, and also MUST include in the SIA of the method OID of id-ad-signedObjectRepository, and also MUST
request an access method OID of id-ad-rpkiManifest, where the include in the SIA of the request an access method OID of id-
associated access location refers to the publication point of the ad-rpkiManifest, where the associated access location refers to
objects that are verified using this EE certificate. the publication point of the objects that are verified using
this EE certificate.
When an EE certificate is used to sign a single published object, When an EE certificate is used to sign a single published
the certificate request for the EE certificate MUST include in the object, the certificate request for the EE certificate MUST
SIA of the request an access method OID of id-ad-signedObject, include in the SIA of the request an access method OID of id-
where the associated access location refers to the publication ad-signedObject, where the associated access location refers to
point of the single object that is verified using this EE the publication point of the single object that is verified
certificate, and MUST NOT include an id-ad-rpkiManifest access using this EE certificate, and MUST NOT include an id-ad-
method OID in the SIA of the request. rpkiManifest access method OID in the SIA of the request.
In the case when the EE certificate is to be used exclusively to In the case when the EE certificate is to be used exclusively
sign one or more unpublished objects, such that the all signed to sign one or more unpublished objects, such that the all
objects will not be published in any RPKI repository, then the SIA signed objects will not be published in any RPKI repository,
SHOULD be omitted from the request. 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
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 6. Resource Certificate Validation
This section describes the Resource Certificate validation procedure. This section describes the Resource Certificate validation procedure.
This refines the generic procedure described in section 6 of This refines the generic procedure described in section 6 of
[RFC5280]: [RFC5280].
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
issuer of certificate x+1; the 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. Resource Extension Validation 6.1. 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
sets: sets:
more specific: Given two IP address or AS number contiguous ranges, more specific
A and B, A is "more specific" than B if range B includes all IP Given two IP address or AS number contiguous ranges, A and B, A
addresses or AS numbers described by range A, and if range B is is "more specific" than B if range B includes all IP addresses
larger than range A. or AS numbers described by range A, and if range B is larger
than range A.
equal: Given two IP address or AS number contiguous ranges, A and B, equal
A is "equal" to B if range A describes precisely the same Given two IP address or AS number contiguous ranges, A and B, A
collection of IP addresses or AS numbers as described by range B. is "equal" to B if range A describes precisely the same
The definition of "inheritance" in [RFC3779] is equivalent to this collection of IP addresses or AS numbers as described by range
"equality" comparison. B. The definition of "inheritance" in [RFC3779] is equivalent
encompass: Given two IP address and AS number sets X and Y, X to this "equality" comparison.
"encompasses" Y if, for every contiguous range of IP addresses or
AS numbers elements in set Y, the range element is either more encompass
specific than or equal to a contiguous range element within the Given two IP address and AS number sets X and Y, X
set X. "encompasses" Y if, for every contiguous range of IP addresses
or AS numbers elements in set Y, the range element is either
more specific than or equal to a contiguous range element
within the set X.
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.2. Resource Certification 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
'Certification 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
the signature algorithm and 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
To values. and 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
values that MUST be present. field 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.
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
Revocation List, and the Certificate Revocation List is itself Certificate Revocation List, and the Certificate Revocation
valid. List is itself valid.
6. That the resource extension data is "encompassed" by the resource 6. That the resource extension data is "encompassed" by the
extension data contained in a valid certificate where this Issuer resource extension data contained in a valid certificate where
is the Subject (the previous certificate in the ordered sequence) this Issuer is the Subject (the previous certificate in the
ordered sequence)
7. The Certification Path originates with a certificate issued by a 7. The Certification Path originates with a certificate issued by
trust anchor, and there exists a signing chain across the a trust anchor, and there exists a signing chain across the
Certification Path where the Subject of Certificate x in the Certification Path where the Subject of Certificate x in the
Certification Path matches the Issuer in Certificate x+1 in the Certification Path matches the Issuer in Certificate x+1 in
Certification Path. the 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
skipping to change at page 24, line 39 skipping to change at page 25, line 10
extension validation property, as described in Section 6.1, and the extension validation property, as described in Section 6.1, 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.1. set, as described in Section 6.1.
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
public key, and the 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.3.1. Distribution Format of Nominated Trust Anchor Material 6.3.1. Distribution Format of Nominated Trust Anchor Material
In the RPKI the hierarchical certificate framework corresponds to the In the RPKI the hierarchical certificate framework corresponds to the
hierarchies of the resource distribution function. In consideration hierarchies of the resource distribution function. In consideration
of this, it is reasonable to nominate to relying parties a default 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 set of trust anchors for the RPKI that correspond to the entities who
operate at the upper levels of the associated resource allocation operate at the upper levels of the associated resource allocation
hierarchy. The corresponding nominated trust anchor CA(s) should hierarchy. The corresponding nominated trust anchor CA(s) should
therefore map, in some fashion, to apex point(s) of the hierarchical therefore map, in some fashion, to apex point(s) of the hierarchical
resource distribution structure. resource distribution structure.
The characteristics of a trust anchor framework for the RPKI includes The characteristics of a trust anchor framework for the RPKI includes
the following considerations: the following considerations:
o The entity or entities that issue proposed trust anchor material * The entity or entities that issue proposed trust anchor
for the RPKI should be as close as possible to the apex of the material for the RPKI should be as close as possible to the
associated resource distribution hierarchy. apex of the associated resource distribution hierarchy.
o Such trust anchor material should be long-lived. As it can be * Such trust anchor material SHOULD be long-lived. As it can be
reasonably anticipated that default nominated trust anchor reasonably anticipated that default nominated trust anchor
material would be distributed with relying party validation material would be distributed with relying party validation
software, the implication is that the distributed default software, the implication is that the distributed default
nominated trust anchor material should remain constant for nominated trust anchor material SHOULD remain constant for
extended time intervals. extended time intervals.
o It is a poor trust model when any entity that issues putative * It is a poor trust model when any entity that issues putative
trust anchor material is forced to be authoritative over trust anchor material is forced to be authoritative over
information or actions of which the entity has no direct information or actions of which the entity has no direct
knowledge, nor is in possession of a current definitive record of knowledge, nor is in possession of a current definitive record
such actions. Entities who propose themselves in a role of a of such actions. Entities who propose themselves in a role of
trust anchor issuer should be able to point to corroborative a trust anchor issuer SHOULD be able to point to corroborative
material supporting the assertion that they are legitimate material supporting the assertion that they are legitimate
authorities for the information where they are representing authorities for the information where they are representing
themselves as a potential trust anchor for relying parties. themselves as a potential trust anchor for relying parties.
An entity offering itself as a putative RPKI trust anchor for a part 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 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 a stable URL, and to publish a packaged form of this URL as
distributed trust anchor material, as follows: distributed trust anchor material, as follows:
o The entity issues a RPKI self-signed "root" CA certificate that is * The entity issues a RPKI self-signed "root" CA certificate that
used as the apex of a RPKI certificate issuance hierarchy. This is used as the apex of a RPKI certificate issuance hierarchy.
certificate MUST have the keyCertSign sign bit set in the key This certificate MUST have the keyCertSign sign bit set in the
usage extension, and the CA flag set in the basic constraints key usage extension, and the CA flag set in the basic
extension, no AIA value and no CRLDP value. This certificate MUST constraints extension, no AIA value and no CRLDP value. This
be reissued at regular intervals prior to expiration of the certificate MUST be reissued at regular intervals prior to
current RPKI self-signed certificate, and MUST be reissued upon expiration of the current RPKI self-signed certificate, and
any change in the resource set that has been allocated to the MUST be reissued upon any change in the resource set that has
entity who is operating this CA. The validity interval of this been allocated to the entity who is operating this CA. The
certificate should reflect the anticipated period of the regular validity interval of this certificate SHOULD reflect the
RPKI certificate re-issuance. anticipated period of the regular RPKI certificate re-issuance.
o The entity maintains a "trust anchor material" key pair. * The entity maintains a "trust anchor material" key pair.
o The entity issues a PKI self-signed CA certificate [RFC5280] using * The entity issues a PKI self-signed CA certificate [RFC5280]
the trust anchor material key pair, where the subject public key using the trust anchor material key pair, where the subject
in the certificate is the public key of the trust anchor material public key in the certificate is the public key of the trust
key pair and the certificate is signed by the corresponding anchor material key pair and the certificate is signed by the
private key of trust anchor material key pair. This certificate corresponding private key of trust anchor material key pair.
MUST have the keyCertSign sign bit set in the key usage extension, This certificate MUST have the keyCertSign sign bit set in the
and the CA flag set in the basic constraints extension, no AIA key usage extension, and the CA flag set in the basic
value and no CRLDP value. The validity period of this certificate constraints extension, no AIA value and no CRLDP value. The
shold be very long-lived, with the period to be defined by the validity period of this certificate shold be very long-lived,
entity. The SIA of this certificate references a publication with the period to be defined by the entity. The SIA of this
point where the CRL and the subordinate product of this certificate references a publication point where the CRL and
certificate are published. the subordinate product of this certificate are published.
o The PKI CA issues a subordinate PKI EE certificate with a validity * The PKI CA issues a subordinate PKI EE certificate with a
period identical to the validity period of the RPKI self-signed validity period identical to the validity period of the RPKI
"root" CA certificate. This PKI EE certificate MUST have the self-signed "root" CA certificate. This PKI EE certificate
digitalSignature bit set, and this MUST be the only bit set to MUST have the digitalSignature bit set, and this MUST be the
TRUE. The CA flag set MUST be cleared in the basic constraints only bit set to TRUE. The CA flag set MUST be cleared in the
extension. The validity period of this certificate should be basic constraints extension. The validity period of this
aligned to the validity period of the RPKI self-signed "root" CA certificate SHOULD be aligned to the validity period of the
certificate. RPKI self-signed "root" CA certificate.
o The PKI CA regularly issues a CRL. The CRL issuance cycle SHOULD * The PKI CA regularly issues a CRL. The CRL issuance cycle
be shorter than the validity period for the RPKI self-signed SHOULD be shorter than the validity period for the RPKI self-
"root" certificate. signed "root" certificate.
o Each time the RPKI self-signed "root" certificate is re-issued, or * Each time the RPKI self-signed "root" certificate is re-issued,
prior to the expiration of the PKI EE certificate, the PKI CA or prior to the expiration of the PKI EE certificate, the PKI
generates a Cryptographic Message Syntax (CMS) [RFC3852] signed- CA generates a Cryptographic Message Syntax (CMS) [RFC3852]
data object, where the payload is the RPKI self-signed "root" signed-data object, where the payload is the RPKI self-signed
certificate. The object is CMS-signed with the private key of the "root" certificate. The object is CMS-signed with the private
PKI EE certificate. The PKI EE certificate is included as a CMS key of the PKI EE certificate. The PKI EE certificate is
signed attribute in the CMS object. The PKI self-signed CA included as a CMS signed attribute in the CMS object. The PKI
certificate and the asociated CRL are not to be included in the self-signed CA certificate and the asociated CRL are not to be
CMS object. The format of the CMS object is specified in included in the CMS object. The format of the CMS object is
Appendix C. The CMS object is published at the location specified in Appendix C. The CMS object is published at the
referenced in the SIA of the PKI self-signed CA certificate. location referenced in the SIA of the PKI self-signed CA
certificate.
o The entity publically distributes the PKI self-signed CA * The entity publically distributes the PKI self-signed CA
certificate as its proposed trust anchor material. certificate as its proposed trust anchor material.
o The entity publishes the modulus and exponent of the "trust anchor * The entity publishes the modulus and exponent of the "trust
material" public key using a trusted form of publication that anchor material" public key using a trusted form of publication
allows the entity's identity to be validated and the retrieval of that allows the entity's identity to be validated and the
the published information to be secured. retrieval of the published information to be secured.
Relying Parties can assemble the default trust anchor collection by Relying Parties can assemble the default trust anchor collection by
using the distributed PKI self-signed CA certificate for each using the distributed PKI self-signed CA certificate for each
nominated trust anchor: nominated trust anchor:
o The public key in the self-signed CA PKI certificate can be * The public key in the self-signed CA PKI certificate can be
validated using the modulus and exponent values as retrieved from validated using the modulus and exponent values as retrieved
the entity's publication point using a secured retrieval from the entity's publication point using a secured retrieval
operation. operation.
o The PKI CA's CRL and CMS objects can be retrieved from the * The PKI CA's CRL and CMS objects can be retrieved from the
publication point referenced by the SIA in the PKI CA certificate. publication point referenced by the SIA in the PKI CA
certificate.
o The CRL can be verified against the PKI CA certificate. * The CRL can be verified against the PKI CA certificate.
o The CMS signature can be verified using the included PKI EE * The CMS signature can be verified using the included PKI EE
certificate together with the retrieved CRL and the self-signed certificate together with the retrieved CRL and the self-signed
PKI CA certificate. PKI CA certificate.
o The relying party can then load the enclosed RPKI self-signed CA * The relying party can then load the enclosed RPKI self-signed
certificate as a trust anchor for RPKI validation for those CA certificate as a trust anchor for RPKI validation for those
resources described in the resource extension of this RPKI resources described in the resource extension of this RPKI
certificate. certificate.
Relying Parties should perform this retrieval and validation Relying Parties SHOULD perform this retrieval and validation
operation at intervals no less frequent than the nextUpdate time of operation at intervals no less frequent than the nextUpdate time of
the published CRL, and should perform the retrieval operation prior the published CRL, and SHOULD perform the retrieval operation prior
to the expiration of the PKI EE certificate, or upon revocation of 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 PKI EE certificate that was used to sign the CMS object that held
the relying party's current RPKI self-signed CA certificate. the relying party's current RPKI self-signed CA certificate.
If a trust anchor CA wishes to perform an issuance of the RPKI self- If a trust anchor CA wishes to perform an issuance of the RPKI self-
signed CA certificate outside the established update cycle time, it signed CA certificate outside the established update cycle time, it
can notify relying parties of this by revising the nextUpdate time of 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 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 a new CMS object with the new RPKI self-signed CA
certificate, and revoking the old PKI EE certificate at the certificate, and revoking the old PKI EE certificate at the
nextUpdate time in the next issued CRL. This revocation will provide nextUpdate time in the next issued CRL. This revocation will provide
an indication to relying parties to perform the retrieval operation an indication to relying parties to perform the retrieval operation
ofthe RPKI self-signed CA certificate at a time earlier than the ofthe RPKI self-signed CA certificate at a time earlier than the
normal update cycle time. normal update cycle time.
7. Security Considerations 7. Design Notes
The Security Considerations of [RFC5280] and [RFC3779]apply to The following notes provide some additional commentary on the
Resource Certificates as defined by this profile, and their use. considerations that lie behind some of the design choices that were
made in the design of this certificate profile. These notes do not
constitute a formal part of the profile specification, and the
interpretation of key words as defined in RFC2119 are not applicable
in this section of the document.
A Resource Certificate PKI cannot in and of itself resolve any forms Certificate Extensions:
of ambiguity relating to uniqueness of assertions of rights of use in This profile does not not permit the use of any other critical
the event that two or more valid certificates encompass the same or non-critical extensions. The rationale for this restriction
resource. If the issuance of resource certificates is aligned to the is that the resource certificate profile is intended for a
status of resource allocations and assignments then the information specific use, and in this context it is not seen as being
conveyed in a certificate is no better than the information in the appropriate to be in the position of having certificates with
allocation and assignment databases. additional non-critical extensions that relying parties may see
as valid certificates without understanding the extensions, but
were the relying party in a position to understand the
extensions, would contradict or qualify in some way this
original judgement of validity. This profile takes the
position of minimialism over extensibility. The specific goal
for the associated Resource Public Key Infrastructure to
precisely match the IP number resource allocation structure
through an aligned certificate structure that describes the
allocation and its context within the number resource
distribution hierarchy. The profile defines a resource
certificate that is structured to meet these requirements.
8. IANA Considerations Certification Authorities and Key Values:
This profile uses a definition of an instance of a CA as a
combination of a certified entity and a key pair. Within this
definition a CA instance cannot rollover a key pair. However,
the entity can generate a new instance of a CA with a new key
pair and roll over all the signed subordinate products to the
new CA.
[Note to IANA, to be removed prior to publication: there are no IANA This has a number of implications in terms of subject name
considerations stated in this document.] management, CRL Scope and repository publication point
management.
9. Acknowledgements Subject Name:
For Subject Names the issuer should ensure that when an
entity requests a certificate with a new key pair it
issues a certificate with a new subject name. One way to
achieve this is for the issuer to use a mapping of the
hash of the subject public key value into a suitable
distinguished name to use as the Subject Name.
The authors would like to acknowledge the valued contributions from CRL Scope:
Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo For CRL Scope this profile specifies that a CA issues a
Patara and Rob Austein in the preparation and subsequent review of single CRL sequence, and the scope of the CRL is all
this document. The document also reflects review comments received products issued by this CA. Becuase the CA instance is
from Sean Turner and David Cooper. bound to a single key pair this implies that the CA's key
value, the key value that signs the CA's CRL and the key
value that signed the revoked products of the CA are all
the same key value.
10. Draft Review Notes Repository Publication Point:
The definition of a CA affects the design of the
repository publication system. In order to minimise the
amount of forced re-certification on key rollover events,
a repository publication regime that uses the same
repository publication point for all CA instances that
refers to the same entity, but with different key values
will minimise the extent of re-generation of certificate
products to immediate subordinate certificates.
The following review comments are unresolved at present: In order for two or more CA instances to share a single
repository publication point there needs to be a regime
of key management into OLD, CURRENT and FUTURE keys and a
similar regine of OLD, CURRENT and FUTURE CAs. An OLD CA
should regularly publish its CRL for as long as the OLD
CA instance is still valid, and issue EE certificates as
necessary to maintain a regularly issued signed manifest
of all OLD CA published products, but should not sign any
other products. The CURRENT CA should publish its CRL,
and should publish all subordinate products, as well as
issuing EE certificates as necessary to maintain a
regularly issued signed manifest of all CURRENT CA
published products. FUTURE CAs should publish no
products at all in the repository publication point. It
would be consistent with this repository object name
framework for the CRL and manifest to be published using
object names derived from the hash of the public key
value of the CA instance.
1. Use of additional non-critical extensions: Key Rollover:
As a CA instance is associated with a single key pair, then
there are some considerations regarding the procedure that
should be followed by an entity performing a key rollover
function. The entity will need to create a new CA instance and
then use this new CA instance to re-issue all subordinate
products with the new CA instance.
Section 3: "Unless specifically noted as being OPTIONAL, all the To perform a key rollover operation the entity will need to:
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 1. Generate a NEW key pair.
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 2. Generate a certificate request with the NEW key
that it was not seen as being appropriate to be in the pair and pass the request to the entity's issuer.
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. 3. The entity's issuer to generate and publish a NEW
CA certificate, with an issuer-selected subject
name that is distinct from the subject name used in
conjunction with the previous subject name value
for this entity.
2. CRL Scope: 4. Mark the CURRENT CA as OLD and the NEW CA as
CURRENT.
Section 3.9.5: In this profile, the scope of the CRL is specified 5. The CURRENT CA to generate subordinate certificates
to be all certificates issued by this CA issue using a given key for all existing subordinate CA and EE products,
pair. and publish those products in the same repository
publication point and with the same repository
publication point name as the previous OLD
subordinate CA and EE products.
The review comment was that the scope of a CRL must be all 6. The new subordinate EE certificates will need to
certificates issued by the issuing CA unless the CRL includes re-sign the objects signed by the OLD EE
an issuingDistributionPoint extension. So, if the scope of certificate, and publish these objects in the same
CRLs is to be limited to certificates signed with a given key repository publication point and the same
pair, then the profile must either require inclusion of the repository publication point name as the previous
issuingDistributionPoint extension in CRLs or forbid CAs from OLD signed objects.
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 7. Generate a certificate revocation request for the
text in Section 3.9.5. OLD CA certificate and pass it to the entity's
issuer.
3. Name Uniqueness: 8. Remove all published OLD CA products and destroy
the OLD keypair.
Section 3.5 stipulates that subject names must simply be unique Name Uniqueness:
per issuer, while X.509 requires that names must be globally This profile specifies that subject names must be unique per
unique. issuer, and does not specify that subject names must be
globally unique.
The review comment was that the Security Considerations Given that the Resource Certificate PKI is a distributed PKI,
section in RFC5280 states: " While X.509 mandates that names there is no inherent ability for Cartification authorities to
be unambiguous, there is a risk that two unrelated authorities coordinate PKI-wide unique subject names. Hierarchically
will issue certificates and/or CRLs under the same issuer structured subject names probably should not incorporate the
name." X.501 states that a (directory) name shall be use superior CA issuer names due to the issue of forced
unambiguous, in that it denotes just one object, but need not reissuance of subordinate products in the event of a re-keying
be unique, in that it not be the only name that unambiguously of a superior CA, as the practical implementation of a re-key
denotes the object, and that for every name form used in the operation is a change of CA. However, as the publication
GeneralName type, there shall be a name registration system repository is distributed, and distinct entities use distinct
that ensures that any name used unambiguously identifies one repository publication points any potential ambiguity is
entity to both certificate issuer and certificate users. The resolved by the distinct publication point.
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 8. Security Considerations
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 The Security Considerations of [RFC5280] and [RFC3779]apply to
uniqueness of names on a per-issuer basis. Resource Certificates as defined by this profile, and their use.
A Resource Certificate PKI cannot in and of itself resolve any forms
of ambiguity relating to uniqueness of assertions of rights of use in
the event that two or more valid certificates encompass the same
resource. If the issuance of resource certificates is aligned to the
status of resource allocations and assignments then the information
conveyed in a certificate is no better than the information in the
allocation and assignment databases.
9. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this document.]
10. Acknowledgements
The authors would like to acknowledge the valued contributions from
Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo
Patara and Rob Austein in the preparation and subsequent review of
this document. The document also reflects review comments received
from Sean Turner and David Cooper.
11. References 11. References
11.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",
skipping to change at page 39, line 49 skipping to change at page 41, line 49
signature algorithms. signature algorithms.
unsignedAttrs unsignedAttrs
unsignedAttrs MUST be omitted. unsignedAttrs MUST be omitted.
C.2. RTA Validation C.2. RTA Validation
Before a relying party can use an RTA, the relying party must first Before a relying party can use an RTA, the relying party must first
validate the RTA by performing the following steps. validate the RTA by performing the following steps.
1. Verify that the RTA syntax complies with this specification. In 1. Verify that the RTA syntax complies with this specification.
particular, verify the following: In particular, verify the following:
a. The contentType of the CMS object is SignedData (OID a. The contentType of the CMS object is SignedData (OID
1.2.840.113549.1.7.2). 1.2.840.113549.1.7.2).
b. The version of the SignedData object is 3. b. The version of the SignedData object is 3.
c. The digestAlgorithm in the SignedData object is SHA-256 (OID c. The digestAlgorithm in the SignedData object is SHA-256
2.16.840.1.101.3.4.2.1). (OID 2.16.840.1.101.3.4.2.1).
d. The certificates field in the SignedData object is present d. The certificates field in the SignedData object is present
and contains an EE certificate whose Subject Key Identifier and contains an EE certificate whose Subject Key
(SKI) matches the sid field of the SignerInfo object. Identifier (SKI) matches the sid field of the SignerInfo
object.
e. The crls field in the SignedData object is omitted. e. The crls field in the SignedData object is omitted.
f. The eContentType in the EncapsulatedContentInfo is id-ct- f. The eContentType in the EncapsulatedContentInfo is id-ct-
RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.[TBD]) RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.[TBD])
g. The version of the SignerInfo is 3. g. The version of the SignerInfo is 3.
h. The digestAlgorithm in the SignerInfo object is SHA-256 (OID h. The digestAlgorithm in the SignerInfo object is SHA-256
2.16.840.1.101.3.4.2.1). (OID 2.16.840.1.101.3.4.2.1).
i. The signatureAlgorithm in the SignerInfo object is RSA (OID i. The signatureAlgorithm in the SignerInfo object is RSA
1.2.840.113549.1.1.1). (OID 1.2.840.113549.1.1.1).
j. The signedAttrs field in the SignerInfo object is present and j. The signedAttrs field in the SignerInfo object is present
contains both the ContentType attribute (OID 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.3) and the MessageDigest attribute (OID
1.2.840.113549.1.9.4). 1.2.840.113549.1.9.4).
k. The unsignedAttrs field in the SignerInfo object is omitted. k. The unsignedAttrs field in the SignerInfo object is
omitted.
2. Use the public key in the EE certificate to verify the signature 2. Use the public key in the EE certificate to verify the
on the RTA. signature on the RTA.
3. Verify that the EE certificate is a valid end-entity certificate 3. Verify that the EE certificate is a valid end-entity
in the Trust Anchor PKI by validating that the PKI CA certificate certificate in the Trust Anchor PKI by validating that the PKI
issued this EE certificate, and the PKI CA's CRL has not revoked CA certificate issued this EE certificate, and the PKI CA's
the EE certificate, and that the PKI CA's CRL is valid. 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
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
George Michaelson George Michaelson
skipping to change at page 42, line 44 skipping to change at line 1967
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 131 change blocks. 
491 lines changed or deleted 545 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/