< draft-ietf-lamps-hash-of-root-key-cert-extn-05.txt		draft-ietf-lamps-hash-of-root-key-cert-extn-06.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Informational January 31, 2019		Intended status: Informational June 28, 2019
	Expires: August 4, 2019		Expires: December 30, 2019
	Hash Of Root Key Certificate Extension		Hash Of Root Key Certificate Extension
	draft-ietf-lamps-hash-of-root-key-cert-extn-05		draft-ietf-lamps-hash-of-root-key-cert-extn-06
	Abstract		Abstract
	This document specifies the Hash Of Root Key certificate extension.		This document specifies the Hash Of Root Key certificate extension.
	This certificate extension is carried in the self-signed certificate		This certificate extension is carried in the self-signed certificate
	for a trust anchor, which is often called a Root Certification		for a trust anchor, which is often called a Root Certification
	Authority (CA) certificate. This certificate extension unambiguously		Authority (CA) certificate. This certificate extension unambiguously
	identifies the next public key that will be used at some point in the		identifies the next public key that will be used at some point in the
	future as the next Root CA certificate, eventually replacing the		future as the next Root CA certificate, eventually replacing the
	current one.		current one.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on August 4, 2019.		This Internet-Draft will expire on December 30, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 4		3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5. Operational Considerations . . . . . . . . . . . . . . . . . 4		5. Operational Considerations . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document specifies the Hash Of Root Key X.509 version 3		This document specifies the Hash Of Root Key X.509 version 3
	certificate extension. The extension is an optional addition to the		certificate extension. The extension is an optional addition to the
	Internet X.509 Public Key Infrastructure Certificate and Certificate		Internet X.509 Public Key Infrastructure Certificate and Certificate
	Revocation List (CRL) Profile [RFC5280]. The certificate extension		Revocation List (CRL) Profile [RFC5280]. The certificate extension
	facilitates the orderly transition from one Root Certification		facilitates the orderly transition from one Root Certification
	Authority (CA) public key to the next. It does so by publishing the		Authority (CA) public key to the next. It does so by publishing the
	hash value of the next generation public key in the current self-		hash value of the next generation public key in the current self-
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. ASN.1		1.2. ASN.1
	Certificates [RFC5280] are generated using ASN.1 [X680]; certificates		Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding Rules
	are always encoded with the Distinguished Encoding Rules (DER)		(DER) [X690] are REQUIRED for certificate signing and validation.
	[X690].
	2. Overview		2. Overview
	Before the initial deployment of the Root CA, the following are		Before the initial deployment of the Root CA, the following are
	generated:		generated:
	R1 = The initial Root key pair		R1 = The initial Root key pair
	R2 = The second generation Root key pair		R2 = The second generation Root key pair
	H2 = Thumbprint (hash) of the public key of R2		H2 = Thumbprint (hash) of the public key of R2
	C1 = Self-signed certificate for R1, which also contains H2		C1 = Self-signed certificate for R1, which also contains H2
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 24 ¶
	The following ASN.1 [X680][X690] syntax defines the HashOfRootKey		The following ASN.1 [X680][X690] syntax defines the HashOfRootKey
	certificate extension:		certificate extension:
	ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates		ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates
	SYNTAX HashedRootKey		SYNTAX HashedRootKey
	IDENTIFIED BY id-ce-hashOfRootKey		IDENTIFIED BY id-ce-hashOfRootKey
	CRITICALITY {FALSE} }		CRITICALITY {FALSE} }
	HashedRootKey ::= SEQUENCE {		HashedRootKey ::= SEQUENCE {
	hashAlg AlgorithmIdentifier, -- Hash algorithm used		hashAlg HashAlgorithm, -- Hash algorithm used
	hashValue OCTET STRING } -- Hash of DER-encoded		hashValue OCTET STRING } -- Hash of DER-encoded
	-- SubjectPublicKeyInfo		-- SubjectPublicKeyInfo
	id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 }		id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 }
	The definitions of EXTENSION and HashAlgorithm can be found in		The definitions of EXTENSION and HashAlgorithm can be found in
	[RFC5912].		[RFC5912].
	The hashAlg indicates the one-way hash algorithm that was used to		The hashAlg indicates the one-way hash algorithm that was used to
	compute the hash value.		compute the hash value.
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 9 ¶
	available in Section 4.4 of [RFC4210]. In particular, the oldWithNew		available in Section 4.4 of [RFC4210]. In particular, the oldWithNew
	and newWithOld advice ensures that relying parties are able to		and newWithOld advice ensures that relying parties are able to
	validate certificates issued under the current Root CA certificate		validate certificates issued under the current Root CA certificate
	and the next generation Root CA certificate throughout the		and the next generation Root CA certificate throughout the
	transition. The notAfter field in the oldWithNew certificate MUST		transition. The notAfter field in the oldWithNew certificate MUST
	cover the validity period of all unexpired certificates issued under		cover the validity period of all unexpired certificates issued under
	the old Root CA private key. Further, this advice SHOULD be followed		the old Root CA private key. Further, this advice SHOULD be followed
	by Root CAs to avoid the need for all relying parties to make the		by Root CAs to avoid the need for all relying parties to make the
	transition at the same time.		transition at the same time.
	After issuing the oldWithNew and newWithOld certificates, the Root CA		After issuing the newWithOld certificate, the Root CA MUST stop using
	MUST stop using the old private key to sign certificates.		the old private key to sign certificates.
	Some enterprise and application-specific environments offer a		Some enterprise and application-specific environments offer a
	directory service or certificate repository to make certificate and		directory service or certificate repository to make certificate and
	CRLs available to relying parties. Section 3 in [RFC5280] describes		CRLs available to relying parties. Section 3 in [RFC5280] describes
	a certificate repository. When a certificate repository is		a certificate repository. When a certificate repository is
	available, the oldWithNew and newWithOld certificates SHOULD be		available, the oldWithNew and newWithOld certificates SHOULD be
	published before the successor to the current Root CA self-signed		published before the successor to the current Root CA self-signed
	certificate is released. Recipients that are able to obtain the		certificate is released. Recipients that are able to obtain the
	oldWithNew certificate SHOULD immediately remove the old Root CA		oldWithNew certificate SHOULD immediately remove the old Root CA
	self-signed certificate from the trust anchor store.		self-signed certificate from the trust anchor store.
			In environments without such a directory service or repository, like
			the Web PKI, recipients need a way to obtain the oldWithNew and
			newWithOld certificates. The Root CA SHOULD include the subject
			information access extension [RFC5280] with the accessMethod set to
			id-ad-caRepository and the assessLocation set to the HTTP URL that
			can be used to fetch a DER-encoded "certs-only" (simple PKI response)
			message as specified in [RFC5272] in all of their self-signed
			certificates. The Root CA SHOULD publish the "certs-only" message
			with the oldWithNew certificate and the newWithOld certificate before
			the subsequent Root CA self-signed certificate is released. The
			"certs-only" message format allows certificates to be added and
			removed from the bag of certificates over time, so the same HTTP URL
			can be used throughout the lifetime of the Root CA.
	In environments without such a directory service or repository,		In environments without such a directory service or repository,
	recipients SHOULD keep both the old and replacement Root CA self-		recipients SHOULD keep both the old and replacement Root CA self-
	signed certificate in the trust anchor store for some amount of time		signed certificates in the trust anchor store for some amount of time
	to ensure that all end-entity certificates can be validated until		to ensure that all end-entity certificates can be validated until
	they expire. The recipient MAY keep the old Root CA self-signed		they expire. The recipient MAY keep the old Root CA self-signed
	certificate until all of the certificates in the local cache that are		certificate until all of the certificates in the local cache that are
	subordinate to it have expired.		subordinate to it have expired.
	Certification path construction is more complex when multiple self-		Certification path construction is more complex when the trust anchor
	signed certificates in the trust anchor store have the same		store contains multiple self-signed certificates with the same
	distinguished name. For this reason, the replacement Root CA self-		distinguished name. For this reason, the replacement Root CA self-
	signed certificate SHOULD contain a different distinguished name than		signed certificate SHOULD contain a different distinguished name than
	the one it is replacing. One approach is to include a number as part		the one it is replacing. One approach is to include a number as part
	of the name that is incremented with each generation, such as		of the name that is incremented with each generation, such as
	"Example CA", "Example CA G2", "Example CA G3", and so on.		"Example CA", "Example CA G2", "Example CA G3", and so on.
	Changing names from one generation to another can lead to confusion		Changing names from one generation to another can lead to confusion
	when reviewing the history of a trust anchor store. To assist with		when reviewing the history of a trust anchor store. To assist with
	such review, a recipient MAY create an audit entry to capture the old		such review, a recipient MAY create an audit entry to capture the old
	and replacement self-signed certificates.		and replacement self-signed certificates.
	skipping to change at page 6, line 43 ¶		skipping to change at page 7, line 8 ¶
	preimage attacks [RFC4270]. A first-preimage attack against the hash		preimage attacks [RFC4270]. A first-preimage attack against the hash
	function would allow an attacker to find another input that results		function would allow an attacker to find another input that results
	published hash value. For the attack to be successful, the input		published hash value. For the attack to be successful, the input
	would have to be a valid SubjectPublicKeyInfo that contains a public		would have to be a valid SubjectPublicKeyInfo that contains a public
	key that corresponds to a private key known to the attacker. A		key that corresponds to a private key known to the attacker. A
	second-preimage attack becomes possible once the Root CA releases the		second-preimage attack becomes possible once the Root CA releases the
	next generation public key, which makes the input to the hash		next generation public key, which makes the input to the hash
	function available to the attacker and everyone else. Again, the		function available to the attacker and everyone else. Again, the
	attacker needs to find a valid SubjectPublicKeyInfo that contains the		attacker needs to find a valid SubjectPublicKeyInfo that contains the
	public key that corresponds to a private key known to the attacker.		public key that corresponds to a private key known to the attacker.
			If the employed hash function is broken after the Root CA publishes
			the self-signed certificate with the HashOfRootKey certificate
			extension, an attacker would be able to trick the recipient into
			installing the incorrect next generation certificate in the trust
			anchor store.
	If an early release of the next generation public key occurs and the		If an early release of the next generation public key occurs and the
	Root CA is concerned that attackers were given too much lead time to		Root CA is concerned that attackers were given too much lead time to
	analyze that public key, then the Root CA can transition to a freshly		analyze that public key, then the Root CA can transition to a freshly
	generated key pair by rapidly performing two transitions. The first		generated key pair by rapidly performing two transitions. The first
	transition takes the Root CA to the key pair that suffered the early		transition takes the Root CA to the key pair that suffered the early
	release, and it causes the Root CA to generate the subsequent Root		release, and it causes the Root CA to generate the subsequent Root
	key pair. The second transition occurs when the Root CA is confident		key pair. The second transition occurs when the Root CA is confident
	that the population of relying parties have completed the first		that the population of relying parties have completed the first
	transition, and it takes the Root CA to the freshly generated key		transition, and it takes the Root CA to the freshly generated key
	pair. Of course, the second transition also causes the Root CA to		pair. Of course, the second transition also causes the Root CA to
	generate another key pair that is reserved for future use.		generate another key pair that is reserved for future use. Queries
			for the CRLs associated with certificates that are subordinate to the
			self-signed certificate can give some indication for the number of
			relying parties that are still actively using the self-signed
			certificates.
	7. Acknowledgements		7. Acknowledgements
	The Secure Electronic Transaction (SET) [SET] specification published		The Secure Electronic Transaction (SET) [SET] specification published
	by MasterCard and VISA in 1997 includes a very similar certificate		by MasterCard and VISA in 1997 includes a very similar certificate
	extension. The SET certificate extension has essentially the same		extension. The SET certificate extension has essentially the same
	semantics, but the syntax fairly different.		semantics, but the syntax fairly different.
	CTIA - The Wireless Association is developing a public key		CTIA - The Wireless Association - is developing a public key
	infrastructure that will make use of the certificate extension		infrastructure that will make use of the certificate extension
	described in this document.		described in this document, and the object identifiers used in the
			ASN.1 module were assigned by CTIA.
	Many thanks to Stefan Santesson, Jim Schaad, Daniel Kahn Gillmor,		Many thanks to Stefan Santesson, Jim Schaad, Daniel Kahn Gillmor,
	Joel Halpern, Paul Hoffman, and Rich Salz. Their review and comments		Joel Halpern, Paul Hoffman, Rich Salz, and Ben Kaduk. Their review
	have greatly improved the document, especially the Operational		and comments have greatly improved the document, especially the
	Considerations and Security Considerations sections.		Operational Considerations and Security Considerations sections.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,		[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
	"Internet X.509 Public Key Infrastructure Certificate		"Internet X.509 Public Key Infrastructure Certificate
	Management Protocol (CMP)", RFC 4210,		Management Protocol (CMP)", RFC 4210,
	DOI 10.17487/RFC4210, September 2005,		DOI 10.17487/RFC4210, September 2005,
	<https://www.rfc-editor.org/info/rfc4210>.		<https://www.rfc-editor.org/info/rfc4210>.
	[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic		[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
	Hashes in Internet Protocols", RFC 4270,		Hashes in Internet Protocols", RFC 4270,
	DOI 10.17487/RFC4270, November 2005,		DOI 10.17487/RFC4270, November 2005,
	<https://www.rfc-editor.org/info/rfc4270>.		<https://www.rfc-editor.org/info/rfc4270>.
			[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
			(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
			<https://www.rfc-editor.org/info/rfc5272>.
	[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, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
	DOI 10.17487/RFC5912, June 2010,		DOI 10.17487/RFC5912, June 2010,
	<https://www.rfc-editor.org/info/rfc5912>.		<https://www.rfc-editor.org/info/rfc5912>.
	skipping to change at page 9, line 14 ¶		skipping to change at page 10, line 14 ¶
	HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 }		HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS All		-- EXPORTS All
	IMPORTS		IMPORTS
	AlgorithmIdentifier{}, DIGEST-ALGORITHM		HashAlgorithm
	FROM AlgorithmInformation-2009 -- [RFC5912]		FROM PKIX1-PSS-OAEP-Algorithms-2009 -- [RFC5912]
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-algorithmInformation-02(58) }		id-mod-pkix1-rsa-pkalgs-02(54) }
	EXTENSION		EXTENSION
	FROM PKIX-CommonTypes-2009		FROM PKIX-CommonTypes-2009
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkixCommon-02(57) } ;		id-mod-pkixCommon-02(57) } ;
	--		--
	-- Expand the certificate extensions list in [RFC5912]		-- Expand the certificate extensions list in [RFC5912]
	--		--
	skipping to change at page 9, line 43 ¶		skipping to change at page 10, line 43 ¶
	--		--
	-- HashOfRootKey Certificate Extension		-- HashOfRootKey Certificate Extension
	--		--
	ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates		ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates
	SYNTAX HashedRootKey		SYNTAX HashedRootKey
	IDENTIFIED BY id-ce-hashOfRootKey		IDENTIFIED BY id-ce-hashOfRootKey
	CRITICALITY {FALSE} }		CRITICALITY {FALSE} }
	HashedRootKey ::= SEQUENCE {		HashedRootKey ::= SEQUENCE {
	hashAlg HashAlgorithmId, -- Hash algorithm used		hashAlg HashAlgorithm, -- Hash algorithm used
	hashValue OCTET STRING } -- Hash of DER-encoded		hashValue OCTET STRING } -- Hash of DER-encoded
	-- SubjectPublicKeyInfo		-- SubjectPublicKeyInfo
	HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }}		HashAlgorithmId ::= AlgorithmIdentifier {DIGEST-ALGORITHM,{ ... }}
	id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 }		id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 }
	END		END
	Author's Address		Author's Address
End of changes. 19 change blocks.
	30 lines changed or deleted		56 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/