draft-ietf-trans-rfc6962-bis-38.txt   draft-ietf-trans-rfc6962-bis-39.txt 
TRANS (Public Notary Transparency) B. Laurie TRANS (Public Notary Transparency) B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Obsoletes: 6962 (if approved) E. Kasper Obsoletes: 6962 (if approved) E. Kasper
Intended status: Experimental E. Messeri Intended status: Experimental E. Messeri
Expires: 15 November 2021 Google Expires: 18 November 2021 Google
R. Stradling R. Stradling
Sectigo Sectigo
14 May 2021 17 May 2021
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-38 draft-ietf-trans-rfc6962-bis-39
Abstract Abstract
This document describes version 2.0 of the Certificate Transparency This document describes version 2.0 of the Certificate Transparency
(CT) protocol for publicly logging the existence of Transport Layer (CT) protocol for publicly logging the existence of Transport Layer
Security (TLS) server certificates as they are issued or observed, in Security (TLS) server certificates as they are issued or observed, in
a manner that allows anyone to audit certification authority (CA) a manner that allows anyone to audit certification authority (CA)
activity and notice the issuance of suspect certificates as well as activity and notice the issuance of suspect certificates as well as
to audit the certificate logs themselves. The intent is that to audit the certificate logs themselves. The intent is that
eventually clients would refuse to honor certificates that do not eventually clients would refuse to honor certificates that do not
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 15 November 2021. This Internet-Draft will expire on 18 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 50 skipping to change at page 3, line 50
10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47 10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47
10.1.2. URN Sub-namespace for TRANS errors 10.1.2. URN Sub-namespace for TRANS errors
(urn:ietf:params:trans:error) . . . . . . . . . . . . 47 (urn:ietf:params:trans:error) . . . . . . . . . . . . 47
10.2. New CT-Related registries . . . . . . . . . . . . . . . 47 10.2. New CT-Related registries . . . . . . . . . . . . . . . 47
10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48 10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48
10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48 10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48
10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49 10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49
10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50 10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50
10.2.5. Log ID Registry . . . . . . . . . . . . . . . . . . 51 10.2.5. Log ID Registry . . . . . . . . . . . . . . . . . . 51
10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52 10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52
10.3. OID Assignment . . . . . . . . . . . . . . . . . . . . . 54
11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 54 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 55
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 54 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 55
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55
11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 55 11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 56
11.5. Leakage of DNS Information . . . . . . . . . . . . . . . 56 11.5. Leakage of DNS Information . . . . . . . . . . . . . . . 56
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . 56
13.2. Informative References . . . . . . . . . . . . . . . . . 58 13.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Supporting v1 and v2 simultaneously (Informative) . 59 Appendix A. Supporting v1 and v2 simultaneously (Informative) . 60
Appendix B. An ASN.1 Module (Informative) . . . . . . . . . . . 60 Appendix B. An ASN.1 Module (Informative) . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
Certificate Transparency aims to mitigate the problem of misissued Certificate Transparency aims to mitigate the problem of misissued
certificates by providing append-only logs of issued certificates. certificates by providing append-only logs of issued certificates.
The logs do not themselves prevent misissuance, but they ensure that The logs do not themselves prevent misissuance, but they ensure that
interested parties (particularly those named in certificates) can interested parties (particularly those named in certificates) can
detect such misissuance. Note that this is a general mechanism that detect such misissuance. Note that this is a general mechanism that
skipping to change at page 47, line 22 skipping to change at page 47, line 22
The assignment policy criteria mentioned in this section refer to the The assignment policy criteria mentioned in this section refer to the
policies outlined in [RFC8126]. policies outlined in [RFC8126].
10.1. Additions to existing registries 10.1. Additions to existing registries
This sub-section defines additions to existing registries. This sub-section defines additions to existing registries.
10.1.1. New Entry to the TLS ExtensionType Registry 10.1.1. New Entry to the TLS ExtensionType Registry
IANA is asked to add an entry for "transparency_info(TBD)" to the IANA is asked to add the following entry to the "TLS ExtensionType
"TLS ExtensionType Values" registry defined in [RFC8446], setting the Values" registry defined in [RFC8446], with an assigned Value:
"Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
CT", and citing this document as the "Reference". +=======+===================+============+=============+===========+
| Value | Extension Name | TLS 1.3 | Recommended | Reference |
+=======+===================+============+=============+===========+
| TBD | transparency_info | CH, CR, CT | Y | RFCXXXX |
+-------+-------------------+------------+-------------+-----------+
Table 7
10.1.2. URN Sub-namespace for TRANS errors 10.1.2. URN Sub-namespace for TRANS errors
(urn:ietf:params:trans:error) (urn:ietf:params:trans:error)
IANA is requested to add a new entry in the "IETF URN Sub-namespace IANA is requested to add a new entry in the "IETF URN Sub-namespace
for Registered Protocol Parameter Identifiers" registry, following for Registered Protocol Parameter Identifiers" registry, following
the template in [RFC3553]: the template in [RFC3553]:
Registry name: trans:error Registry name: trans:error
skipping to change at page 48, line 26 skipping to change at page 48, line 28
| 0x01 - | Unassigned | | Specification | | 0x01 - | Unassigned | | Specification |
| 0xDF | | | Required | | 0xDF | | | Required |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
| 0xE0 - | Reserved | | Experimental Use | | 0xE0 - | Reserved | | Experimental Use |
| 0xEF | | | | | 0xEF | | | |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
| 0xF0 - | Reserved | | Private Use | | 0xF0 - | Reserved | | Private Use |
| 0xFF | | | | | 0xFF | | | |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
Table 7 Table 8
The Designated Expert(s) should ensure that the proposed algorithm The Designated Expert(s) should ensure that the proposed algorithm
has a public specification and is suitable for use as a cryptographic has a public specification and is suitable for use as a cryptographic
hash algorithm with no known preimage or collision attacks. These hash algorithm with no known preimage or collision attacks. These
attacks can damage the integrity of the log. attacks can damage the integrity of the log.
10.2.2. Signature Algorithms 10.2.2. Signature Algorithms
IANA is asked to establish a registry of signature algorithm values, IANA is asked to establish a registry of signature algorithm values,
named "Signature Algorithms". named "Signature Algorithms".
skipping to change at page 49, line 39 skipping to change at page 49, line 41
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
| 0x0808 - 0xFDFF | Unassigned | Expert | | 0x0808 - 0xFDFF | Unassigned | Expert |
| | | Review | | | | Review |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
| 0xFE00 - 0xFEFF | Reserved | Experimental | | 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use | | | | Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
| 0xFF00 - 0xFFFF | Reserved | Private Use | | 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
Table 8 Table 9
The Designated Expert(s) should ensure that the proposed algorithm The Designated Expert(s) should ensure that the proposed algorithm
has a public specification, has a value assigned to it in the TLS has a public specification, has a value assigned to it in the TLS
SignatureScheme Registry (that IANA was asked to establish in SignatureScheme Registry (that IANA was asked to establish in
[RFC8446]) and is suitable for use as a cryptographic signature [RFC8446]) and is suitable for use as a cryptographic signature
algorithm. algorithm.
10.2.3. VersionedTransTypes 10.2.3. VersionedTransTypes
IANA is asked to establish a registry of "VersionedTransType" values, IANA is asked to establish a registry of "VersionedTransType" values,
skipping to change at page 50, line 39 skipping to change at page 50, line 41
| 0x0008 - | Unassigned | Specification Required | | 0x0008 - | Unassigned | Specification Required |
| 0xDFFF | | | | 0xDFFF | | |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0xE000 - | Reserved | Experimental Use | | 0xE000 - | Reserved | Experimental Use |
| 0xEFFF | | | | 0xEFFF | | |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0xF000 - | Reserved | Private Use | | 0xF000 - | Reserved | Private Use |
| 0xFFFF | | | | 0xFFFF | | |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
Table 9 Table 10
The Designated Expert(s) should review the public specification to The Designated Expert(s) should review the public specification to
ensure that it is detailed enough to ensure implementation ensure that it is detailed enough to ensure implementation
interoperability. interoperability.
10.2.4. Log Artifact Extension Registry 10.2.4. Log Artifact Extension Registry
IANA is asked to establish a registry of "ExtensionType" values, IANA is asked to establish a registry of "ExtensionType" values,
named "Log Artifact Extensions", that initially consists of: named "Log Artifact Extensions", that initially consists of:
skipping to change at page 51, line 18 skipping to change at page 51, line 18
| 0x0000 - | Unassigned | n/a | Specification Required | | 0x0000 - | Unassigned | n/a | Specification Required |
| 0xDFFF | | | | | 0xDFFF | | | |
+---------------+------------+-----+-------------------------------+ +---------------+------------+-----+-------------------------------+
| 0xE000 - | Reserved | n/a | Experimental Use | | 0xE000 - | Reserved | n/a | Experimental Use |
| 0xEFFF | | | | | 0xEFFF | | | |
+---------------+------------+-----+-------------------------------+ +---------------+------------+-----+-------------------------------+
| 0xF000 - | Reserved | n/a | Private Use | | 0xF000 - | Reserved | n/a | Private Use |
| 0xFFFF | | | | | 0xFFFF | | | |
+---------------+------------+-----+-------------------------------+ +---------------+------------+-----+-------------------------------+
Table 10 Table 11
The "Use" column should contain one or both of the following values: The "Use" column should contain one or both of the following values:
* "SCT", for extensions specified for use in Signed Certificate * "SCT", for extensions specified for use in Signed Certificate
Timestamps. Timestamps.
* "STH", for extensions specified for use in Signed Tree Heads. * "STH", for extensions specified for use in Signed Tree Heads.
The Designated Expert(s) should review the public specification to The Designated Expert(s) should review the public specification to
ensure that it is detailed enough to ensure implementation ensure that it is detailed enough to ensure implementation
skipping to change at page 51, line 49 skipping to change at page 51, line 49
| Log ID | Log Base URL | Log Operator | Reference / | | Log ID | Log Base URL | Log Operator | Reference / |
| | | | Assignment Policy | | | | | Assignment Policy |
+================+==============+==============+===================+ +================+==============+==============+===================+
| 1.3.101.8192 - | Unassigned | Unassigned | First Come First | | 1.3.101.8192 - | Unassigned | Unassigned | First Come First |
| 1.3.101.16383 | | | Served | | 1.3.101.16383 | | | Served |
+----------------+--------------+--------------+-------------------+ +----------------+--------------+--------------+-------------------+
| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First | | 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
| 1.3.101.80.* | | | Served | | 1.3.101.80.* | | | Served |
+----------------+--------------+--------------+-------------------+ +----------------+--------------+--------------+-------------------+
Table 11 Table 12
All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
set aside for Log IDs. This is a limited resource of 8,192 OIDs, set aside for Log IDs. This is a limited resource of 8,192 OIDs,
each of which has an encoded length of 4 octets. each of which has an encoded length of 4 octets.
The 1.3.101.80 arc has also been set assigned for LogIDs. This is an The 1.3.101.80 arc has also been set assigned for LogIDs. This is an
unlimited resource, but only the 128 OIDs from 1.3.101.80.0 to unlimited resource, but only the 128 OIDs from 1.3.101.80.0 to
1.3.101.80.127 have an encoded length of only 4 octets. 1.3.101.80.127 have an encoded length of only 4 octets.
Each application for the allocation of a Log ID MUST be accompanied Each application for the allocation of a Log ID MUST be accompanied
skipping to change at page 52, line 50 skipping to change at page 52, line 50
+============+========+===========+ +============+========+===========+
| Field Name | Type | Reference | | Field Name | Type | Reference |
+============+========+===========+ +============+========+===========+
| identifier | string | RFCXXXX | | identifier | string | RFCXXXX |
+------------+--------+-----------+ +------------+--------+-----------+
| meaning | string | RFCXXXX | | meaning | string | RFCXXXX |
+------------+--------+-----------+ +------------+--------+-----------+
| reference | string | RFCXXXX | | reference | string | RFCXXXX |
+------------+--------+-----------+ +------------+--------+-----------+
Table 12 Table 13
The initial values are as follows, taken from the text above: The initial values are as follows, taken from the text above:
+===================+===============================+===========+ +===================+===============================+===========+
| Identifier | Meaning | Reference | | Identifier | Meaning | Reference |
+===================+===============================+===========+ +===================+===============================+===========+
| malformed | The request could not be | RFCXXXX | | malformed | The request could not be | RFCXXXX |
| | parsed. | | | | parsed. | |
+-------------------+-------------------------------+-----------+ +-------------------+-------------------------------+-----------+
| badSubmission | "submission" is neither a | RFCXXXX | | badSubmission | "submission" is neither a | RFCXXXX |
skipping to change at page 54, line 15 skipping to change at page 54, line 15
| | existing STH. | | | | existing STH. | |
+-------------------+-------------------------------+-----------+ +-------------------+-------------------------------+-----------+
| startUnknown | "start" is greater than the | RFCXXXX | | startUnknown | "start" is greater than the | RFCXXXX |
| | number of entries in the | | | | number of entries in the | |
| | Merkle tree. | | | | Merkle tree. | |
+-------------------+-------------------------------+-----------+ +-------------------+-------------------------------+-----------+
| endBeforeStart | "start" cannot be greater | RFCXXXX | | endBeforeStart | "start" cannot be greater | RFCXXXX |
| | than "end". | | | | than "end". | |
+-------------------+-------------------------------+-----------+ +-------------------+-------------------------------+-----------+
Table 13 Table 14
10.3. OID Assignment
IANA is asked to assign one object identifier from the "SMI Security
for PKIX Module Identifier" registry to identify the ASN.1 module in
Appendix B of this document with an assigned Decimal value.
+=========+=========================+============+
| Decimal | Description | References |
+=========+=========================+============+
| TBD | id-mod-public-notary-v2 | RFCXXXX |
+---------+-------------------------+------------+
Table 15
11. Security Considerations 11. Security Considerations
With CAs, logs, and servers performing the actions described here, With CAs, logs, and servers performing the actions described here,
TLS clients can use logs and signed timestamps to reduce the TLS clients can use logs and signed timestamps to reduce the
likelihood that they will accept misissued certificates. If a server likelihood that they will accept misissued certificates. If a server
presents a valid signed timestamp for a certificate, then the client presents a valid signed timestamp for a certificate, then the client
knows that a log has committed to publishing the certificate. From knows that a log has committed to publishing the certificate. From
this, the client knows that monitors acting for the subject of the this, the client knows that monitors acting for the subject of the
certificate have had some time to notice the misissuance and take certificate have had some time to notice the misissuance and take
 End of changes. 16 change blocks. 
20 lines changed or deleted 41 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/