< draft-ietf-lamps-hash-of-root-key-cert-extn-01.txt		draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Informational November 07, 2018		Intended status: Informational December 27, 2018
	Expires: May 11, 2019		Expires: June 30, 2019
	Hash Of Root Key Certificate Extension		Hash Of Root Key Certificate Extension
	draft-ietf-lamps-hash-of-root-key-cert-extn-01		draft-ietf-lamps-hash-of-root-key-cert-extn-02
	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.		at some point in the future.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 May 11, 2019.		This Internet-Draft will expire on June 30, 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
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	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 links 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		verify the signature on the self-signed certificate and verify that
	DER-encoded SubjectPublicKeyInfo from the potential Root CA		the hash of the DER-encoded SubjectPublicKeyInfo from the potential
	certificate matches the value from the HashOfRootKey certificate		Root CA certificate matches the value from the HashOfRootKey
	extension of the current Root CA certificate. If the signature does		certificate extension of the current Root CA certificate. Checking
	not validate or the hash values do not match, then potential Root CA		the self-signed certificate signature ensures that the certificate
			contains the subject name that the key owner intends, which is
			important for path validation. Checking the hash of the
			SubjectPublicKeyInfo ensures that the certificate contains the
			intended public key. If either check fails, 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
	The HashOfRootKey certificate extension MUST NOT be critical.		The HashOfRootKey certificate extension MUST NOT be critical.
	The following ASN.1 [X680][X690] syntax defines the HashOfRootKey		The following ASN.1 [X680][X690] syntax defines the HashOfRootKey
	certificate extension:		certificate extension:
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 45 ¶
	This document makes no requests of the IANA.		This document makes no requests of the IANA.
	5. Operational Considerations		5. Operational Considerations
	Guidance on the transition from one trust anchor to another is		Guidance on the transition from one trust anchor to another is
	available in [RFC2510]. In particular, the oldWithNew and newWithOld		available in [RFC2510]. In particular, the oldWithNew and newWithOld
	advice ensures that relying parties are able to validate certificates		advice ensures that relying parties are able to validate certificates
	issued under the current Root CA certificate and the next generation		issued under the current Root CA certificate and the next generation
	Root CA certificate throughout the transition. Further, this		Root CA certificate throughout the transition. Further, this
	technique ovoids the need for all relying parties to make the		technique avoids the need for all relying parties to make the
	transition at the same time.		transition at the same time.
	6. Security Considerations		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
End of changes. 5 change blocks.
	10 lines changed or deleted		14 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/