< 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 30 ¶		skipping to change at page 22, line 28 ¶
	collection of IP addresses or AS numbers as described by range B.		collection of IP addresses or AS numbers as described by range B.
	The definition of "inheritance" in [RFC3779] is equivalent to this		The definition of "inheritance" in [RFC3779] is equivalent to this
	"equality" comparison.		"equality" comparison.
	encompass: Given two IP address and AS number sets X and Y, X		encompass: Given two IP address and AS number sets X and Y, X
	"encompasses" Y if, for every contiguous range of IP addresses or		"encompasses" Y if, for every contiguous range of IP addresses or
	AS numbers elements in set Y, the range element is either more		AS numbers elements in set Y, the range element is either more
	specific than or equal to a contiguous range element within the		specific than or equal to a contiguous range element within the
	set X.		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.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.
	skipping to change at page 24, line 24 ¶		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.
	152 lines changed or deleted		683 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/