draft-ietf-trans-rfc6962-bis-40.txt   draft-ietf-trans-rfc6962-bis-41.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: 29 January 2022 Google Expires: 31 January 2022 Google
R. Stradling R. Stradling
Sectigo Sectigo
28 July 2021 30 July 2021
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-40 draft-ietf-trans-rfc6962-bis-41
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
appear in a log, effectively forcing CAs to add all issued appear in a log, effectively forcing CAs to add all issued
certificates to the logs. certificates to the logs.
This document obsoletes RFC 6962. It also specifies a new TLS This document obsoletes RFC 6962. It also specifies a new TLS
extension that is used to send various CT log artifacts. extension that is used to send various CT log artifacts.
Logs are network services that implement the protocol operations for Logs are network services that implement the protocol operations for
submissions and queries that are defined in this document. submissions and queries that are defined in this document.
[RFC Editor: please update 'RFCXXXX' to refer to this document, once [RFC Editor: please update 'RFCXXXX' to refer to this document, once
its RFC number is known, through the document.] its RFC number is known, through the document. Also, the OID
assigned below must also appear in the appendix as indicated. ]
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 29 January 2022.
This Internet-Draft will expire on 31 January 2022.
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 19, line 44 skipping to change at page 19, line 44
attacks). attacks).
The log SHALL allow retrieval of its list of accepted trust anchors The log SHALL allow retrieval of its list of accepted trust anchors
(see Section 5.7), each of which is a root or intermediate CA (see Section 5.7), each of which is a root or intermediate CA
certificate. This list might usefully be the union of root certificate. This list might usefully be the union of root
certificates trusted by major browser vendors. certificates trusted by major browser vendors.
4.2.1. Minimum Acceptance Criteria 4.2.1. Minimum Acceptance Criteria
To ensure that logged certificates and precertificates are To ensure that logged certificates and precertificates are
attributable to an accepted trust anchor, and to set clear attributable to an accepted trust anchor, to set clear expectations
expectations for what monitors would find in the log, and to avoid for what monitors would find in the log, and to avoid being
being overloaded by invalid submissions, the log MUST reject a overloaded by invalid submissions, the log MUST reject a submission
submission if any of the following conditions are not met: if any of the following conditions are not met:
* The "submission", "type" and "chain" inputs MUST be set as * The "submission", "type" and "chain" inputs MUST be set as
described in Section 5.1. The log MUST NOT accommodate misordered described in Section 5.1. The log MUST NOT accommodate misordered
CA certificates or use any other source of intermediate CA CA certificates or use any other source of intermediate CA
certificates to attempt certification path construction. certificates to attempt certification path construction.
* Each of the zero or more intermediate CA certificates in the chain * Each of the zero or more intermediate CA certificates in the chain
MUST have one or both of the following features: MUST have one or both of the following features:
- The Basic Constraints extension with the cA boolean asserted. - The Basic Constraints extension with the cA boolean asserted.
skipping to change at page 21, line 17 skipping to change at page 21, line 17
"TimestampedCertificateEntryDataV2" structure. The "TransItem" can "TimestampedCertificateEntryDataV2" structure. The "TransItem" can
be reconstructed from these fields and the entire chain that the log be reconstructed from these fields and the entire chain that the log
used to verify the submission. used to verify the submission.
4.4. Log ID 4.4. Log ID
Each log is identified by an OID, which is one of the log's Each log is identified by an OID, which is one of the log's
parameters (see Section 4.1) and which MUST NOT be used to identify parameters (see Section 4.1) and which MUST NOT be used to identify
any other log. A log's operator MUST either allocate the OID any other log. A log's operator MUST either allocate the OID
themselves or request an OID from the Log ID registry (see themselves or request an OID from the Log ID registry (see
Section 10.2.5). The only advantage of the registry is that the DER Section 10.2.5). One way to get an OID arc, from which OIDs can be
encoding can be small. (Recall that OID allocations do not require a allocated, is to request a Private Enterprise Number from IANA, by
central registration, although logs will most likely want to make completing the registration form (https://pen.iana.org/pen/
themselves known to potential clients through out of band means.) PenApplication.page). The only advantage of the registry is that the
Various data structures include the DER encoding of this OID, DER encoding can be small. (Recall that OID allocations do not
excluding the ASN.1 tag and length bytes, in an opaque vector: require a central registration, although logs will most likely want
to make themselves known to potential clients through out of band
means.) Various data structures include the DER encoding of this
OID, excluding the ASN.1 tag and length bytes, in an opaque vector:
opaque LogID<2..127>; opaque LogID<2..127>;
Note that the ASN.1 length and the opaque vector length are identical Note that the ASN.1 length and the opaque vector length are identical
in size (1 byte) and value, so the full DER encoding (including the in size (1 byte) and value, so the full DER encoding (including the
tag and length) of the OID can be reproduced simply by prepending an tag and length) of the OID can be reproduced simply by prepending an
OBJECT IDENTIFIER tag (0x06) to the opaque vector length and OBJECT IDENTIFIER tag (0x06) to the opaque vector length and
contents. contents.
The OID used to identify a log is limited such that the DER encoding The OID used to identify a log is limited such that the DER encoding
skipping to change at page 49, line 7 skipping to change at page 49, line 7
of this is leveraging the expertise of the TLS working group and of this is leveraging the expertise of the TLS working group and
its Designated Expert(s). its Designated Expert(s).
* The value "0x0403" appears twice. While this may be confusing, it * The value "0x0403" appears twice. While this may be confusing, it
is okay because the verification process is the same for both is okay because the verification process is the same for both
algorithms, and the choice of which to use when generating a algorithms, and the choice of which to use when generating a
signature is purely internal to the log server. signature is purely internal to the log server.
The registry should initially consist of: The registry should initially consist of:
+================================+==================+==============+ +================================+==================+===============+
| SignatureScheme Value | Signature | Reference / | | SignatureScheme Value | Signature | Reference / |
| | Algorithm | Assignment | | | Algorithm | Assignment |
| | | Policy | | | | Policy |
+================================+==================+==============+ +================================+==================+===============+
| 0x0000 - 0x0402 | Unassigned | Expert | | 0x0000 - 0x0402 | Unassigned | Specification |
| | | Review | | | | Required |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
| ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST | [FIPS186-4] | | ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST | [FIPS186-4] |
| | P-256) with | | | | P-256) with | |
| | SHA-256 | | | | SHA-256 | |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
| ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] | | ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] |
| | ECDSA (NIST | | | | ECDSA (NIST | |
| | P-256) with | | | | P-256) with | |
| | HMAC-SHA256 | | | | HMAC-SHA256 | |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
| 0x0404 - 0x0806 | Unassigned | Expert | | 0x0404 - 0x0806 | Unassigned | Specification |
| | | Review | | | | Required |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
| ed25519(0x0807) | Ed25519 | [RFC8032] | | ed25519(0x0807) | Ed25519 | [RFC8032] |
| | (PureEdDSA with | | | | (PureEdDSA | |
| | the edwards25519 | | | | with the | |
| | curve) | | | | edwards25519 | |
+--------------------------------+------------------+--------------+ | | curve) | |
| 0x0808 - 0xFDFF | Unassigned | Expert | +--------------------------------+------------------+---------------+
| | | Review | | 0x0808 - 0xFDFF | Unassigned | Expert Review |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
| 0xFE00 - 0xFEFF | Reserved | Experimental | | 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use | | | | Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
| 0xFF00 - 0xFFFF | Reserved | Private Use | | 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+---------------+
Table 9 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,
named "VersionedTransTypes". named "VersionedTransTypes".
The following note should be added: The following note should be added:
* The 0x0000 value is reserved so that v1 SCTs are distinguishable * The 0x0000 value is reserved so that v1 SCTs are distinguishable
skipping to change at page 52, line 9 skipping to change at page 52, line 9
| 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 12 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 aside for Log IDs. 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
by: by:
* the Log's Base URL (see Section 4.1). * the Log's Base URL (see Section 4.1).
* the Log Operator's contact details. * the Log Operator's contact details.
skipping to change at page 60, line 48 skipping to change at page 60, line 48
Section 3.3 of [RFC6962]. Section 3.3 of [RFC6962].
* Sign that TBSCertificate (which now contains v1 and v2 SCTs) to * Sign that TBSCertificate (which now contains v1 and v2 SCTs) to
issue the final X.509 certificate. issue the final X.509 certificate.
Appendix B. An ASN.1 Module (Informative) Appendix B. An ASN.1 Module (Informative)
The following ASN.1 module may be useful to implementors. The following ASN.1 module may be useful to implementors.
CertificateTransparencyV2Module-2021 CertificateTransparencyV2Module-2021
-- { OID Needed, but no point in using a short one } -- { id-mod-public-notary-v2 from above, in
iso(1) identified-organization(3) ...
form }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
EXTENSION EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912 FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } id-mod-pkixCommon-02(57) }
CONTENT-TYPE CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- RFC 6268 FROM CryptographicMessageSyntax-2010 -- RFC 6268
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 End of changes. 14 change blocks. 
53 lines changed or deleted 60 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/