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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/