draft-ietf-lamps-hash-of-root-key-cert-extn-00.txt		draft-ietf-lamps-hash-of-root-key-cert-extn-01.txt
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Informational August 31, 2018		Intended status: Informational November 07, 2018
	Expires: March 4, 2019		Expires: May 11, 2019
	Hash Of Root Key Certificate Extension		Hash Of Root Key Certificate Extension
	draft-ietf-lamps-hash-of-root-key-cert-extn-00		draft-ietf-lamps-hash-of-root-key-cert-extn-01
	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 by the trust anchor.		identifies the next public key that will be used by the trust anchor
			at some point in the future.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 4, 2019.		This Internet-Draft will expire on May 11, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 2		1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 3		3. Hash Of Root Key Certificate Extension . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Operational Considerations . . . . . . . . . . . . . . . . . 4
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 7
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	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-
	signed certificate. This allows a relying party to unambiguously		signed certificate. This allows a relying party to unambiguously
	recognize the next generation public key when it becomes available.		recognize the next generation public key when it becomes available,
			install that public key in the trust anchor store, and remove the
			previous public key from the trust anchor store.
	A Root CA Certificate MAY include the Hashed Root Key certificate		A Root CA Certificate MAY include the Hashed Root Key certificate
	extension to provide the hash value of the next public key that will		extension to provide the hash value of the next public key that will
	be used by the Root CA.		be used by the Root CA.
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		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], which uses		Certificates [RFC5280] are generated using ASN.1 [X680]; certificates
	the Basic Encoding Rules (BER) and the Distinguished Encoding Rules		are always encoded with the Distinguished Encoding Rules (DER)
	(DER) [X690].		[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
	C1 = Self-signed certificate for R1, which also contains H2		C1 = Self-signed certificate for R1, which also contains H2
	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
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 39 ¶
	R3 = The third generation Root key pair		R3 = The third generation Root key pair
	H3 = Thumbprint (hash) the public key of R3		H3 = Thumbprint (hash) the public key of R3
	C2 = Self-signed certificate for R2, which contains H3		C2 = Self-signed certificate for R2, which contains H3
	This is an iterative process. That is, R4 and H4 are generated when		This is an iterative process. That is, R4 and H4 are generated when
	it is time for C3 to replace C2. And so on.		it is time for C3 to replace C2. And so on.
	The successors to the Root CA self-signed certificate can be		The successors to the Root CA self-signed certificate can be
	delivered by any means. Whenever a new Root CA certificate is		delivered by any means. Whenever a new Root CA certificate is
	received, the recipient is able to verify that the potential Root CA		received, the recipient is able to verify that the potential Root CA
	certificate chains back to a previously authenticated Root CA		certificate links back to a previously authenticated Root CA
	certificate with the hashOfRootKey certificate extension. That is,		certificate with the hashOfRootKey certificate extension. That is,
	validate the self-signed signature and verify that the hash of the		validate the self-signed signature and verify that the hash of the
	DER-encoded SubjectPublicKeyInfo from the potential Root CA		DER-encoded SubjectPublicKeyInfo from the potential Root CA
	certificate matches the value from the HashOfRootKey certificate		certificate matches the value from the HashOfRootKey certificate
	extension of the current Root CA certificate. If the signature does		extension of the current Root CA certificate. If the signature does
	not validate or the hash values do not match, then potential Root CA		not validate or the hash values do not match, then potential Root CA
	certificate is not a valid replacement, and the recipient continues		certificate is not a valid replacement, and the recipient continues
	to use the current Root CA certificate.		to use the current Root CA certificate.
	3. Hash Of Root Key Certificate Extension		3. Hash Of Root Key Certificate Extension
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 22 ¶
	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 AlgorithmIdentifier, -- 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 TBD 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.
	The hashValue contains the hash value computed from the next		The hashValue contains the hash value computed from the next
	generation public key. The public key is DER-encoded		generation public key. The public key is DER-encoded
	SubjectPublicKeyInfo as defined in [RFC5280].		SubjectPublicKeyInfo as defined in [RFC5280].
	4. IANA Considerations		4. IANA Considerations
	This document makes no requests of the IANA.		This document makes no requests of the IANA.
	5. Security Considerations		5. Operational Considerations
			Guidance on the transition from one trust anchor to another is
			available in [RFC2510]. In particular, the oldWithNew and newWithOld
			advice ensures that relying parties are able to validate certificates
			issued under the current Root CA certificate and the next generation
			Root CA certificate throughout the transition. Further, this
			technique ovoids the need for all relying parties to make the
			transition at the same time.
			6. Security Considerations
	The security considerations from [RFC5280] apply, especially the		The security considerations from [RFC5280] apply, especially the
	discussion of self-issued certificates.		discussion of self-issued certificates.
	The Hash Of Root Key certificate extension facilitates the orderly		The Hash Of Root Key certificate extension facilitates the orderly
	transition from one Root CA public key to the next by publishing the		transition from one Root CA public key to the next by publishing the
	hash value of the next generation public key in the current		hash value of the next generation public key in the current
	certificate. This allows a relying party to unambiguously recognize		certificate. This allows a relying party to unambiguously recognize
	the next generation public key when it becomes available; however,		the next generation public key when it becomes available; however,
	the full public key is not disclosed until the Root CA releases the		the full public key is not disclosed until the Root CA releases the
	next generation certificate. In this way, attackers cannot begin to		next generation certificate. In this way, attackers cannot begin to
	analyze the public key before the next generation Root CA certificate		analyze the public key before the next generation Root CA certificate
	is released.		is released.
			The Root CA needs to ensure that the public key in the next
			generation certificate is as strong or stronger than the key that it
			is replacing.
			The Root CA needs to employ a hash function that is resistant to
			preimage attacks [RFC4270]. A first-preimage attack against the hash
			function would allow an attacker to find another input that results
			published hash value. For the attack to be successful, the input
			would have to be a valid SubjectPublicKeyInfo that contains the
			public key that corresponds to a private key known to the attacker.
			A second-preimage attack becomes possible once the Root CA releases
			the next generation public key, which makes the input to the hash
			function becomes available to the attacker and everyone else. Again,
			the attacker needs to find a valid SubjectPublicKeyInfo that contains
			the public key that corresponds to a private key known to the
			attacker.
	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 the Root key pair for future use.		generate the Root key pair for future use.
	6. 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.
	7. References		Many thanks to Jim Schaad and Stefan Santesson. Their review and
			comments have greatly improved the document, especially the
			Operational Considerations and Security Considerations sections.
	7.1. Normative References		8. 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>.
			[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
			Infrastructure Certificate Management Protocols",
			RFC 2510, DOI 10.17487/RFC2510, March 1999,
			<https://www.rfc-editor.org/info/rfc2510>.
			[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
			Hashes in Internet Protocols", RFC 4270,
			DOI 10.17487/RFC4270, November 2005,
			<https://www.rfc-editor.org/info/rfc4270>.
	[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 6, line 5 ¶		skipping to change at page 7, line 10 ¶
	[X680] ITU-T, "Information technology -- Abstract Syntax Notation		[X680] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation",		One (ASN.1): Specification of basic notation",
	ITU-T Recommendation X.680, 2015.		ITU-T Recommendation X.680, 2015.
	[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, 2015.		(DER)", ITU-T Recommendation X.690, 2015.
	7.2. Informative References		8.2. Informative References
	[SET] MasterCard and VISA, "SET Secure Electronic Transaction		[SET] MasterCard and VISA, "SET Secure Electronic Transaction
	Specification -- Book 2: Programmer's Guide, Version 1.0",		Specification -- Book 2: Programmer's Guide, Version 1.0",
	May 1997.		May 1997.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	The following ASN.1 module provides the complete definition of the		The following ASN.1 module provides the complete definition of the
	HashOfRootKey certificate extension.		HashOfRootKey certificate extension.
End of changes. 18 change blocks.
	25 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/