draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt   draft-ietf-lamps-hash-of-root-key-cert-extn-05.txt 
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Informational January 15, 2019 Intended status: Informational January 31, 2019
Expires: July 19, 2019 Expires: August 4, 2019
Hash Of Root Key Certificate Extension Hash Of Root Key Certificate Extension
draft-ietf-lamps-hash-of-root-key-cert-extn-04 draft-ietf-lamps-hash-of-root-key-cert-extn-05
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 July 19, 2019. This Internet-Draft will expire on August 4, 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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
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 oldWithNew and newWithOld certificates, the Root CA
MUST stop using the old private key to sign certificates. MUST stop using the old private key to sign certificates.
In enterprise and application-specific environments where a directory Some enterprise and application-specific environments offer a
service or certificate repository is available, the oldWithNew and directory service or certificate repository to make certificate and
newWithOld certificates SHOULD be published before the successor to CRLs available to relying parties. Section 3 in [RFC5280] describes
the current Root CA self-signed certificate is released. In a certificate repository. When a certificate repository is
environments without such a directory service or repository, available, the oldWithNew and newWithOld certificates SHOULD be
published before the successor to the current Root CA self-signed
certificate is released. Recipients that are able to obtain the
oldWithNew certificate SHOULD immediately remove the old Root CA
self-signed certificate from the trust anchor store.
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 certificate 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 multiple self-
signed certificates in the trust anchor store have the same signed certificates in the trust anchor store have the same
distinguished name. For this reason, the replacement Root CA self- distinguished name. For this reason, the replacement Root CA self-
 End of changes. 5 change blocks. 
10 lines changed or deleted 16 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/