We'd be very grateful for some discussion of this so
that we can close it (one way or the other) and move
forward.
Thanks,
Melinda
On 1/11/16 8:31 AM, Karen Seo wrote:
Folks,
I agree with the approach discussed on the list of simplifying 6962-bis
to focus only on specifications for the CT log by moving the detailed
specifications for other components of the CT system to other documents.
This is in line with a message from Melinda on July 2 re: client
behavior, and amessage from Rich Saltz on July 6 re: the Auditor
function. To facilitate moving requirements for the CA/Subject part of
the system, I propose that we make the changes below with regard to
statements about CT requirements for CA and Subject behavior. These
changes will also help to address some of the concerns that have been
cited elsewhere aboutthe text of 6962-bis (e.g., issues 139, 140, 144).
Karen
*_Changes to 6962-bis_*
_/**/_/*Section 3. Submitters*/
*_From: _*Submitters submit certificates or pre-certificates to logs
for public auditing, as described below. In order to enable
attribution of each logged certificate or pre-certificate to its
issuer, each submission MUST be accompanied by all additional
certificates required to verify the chain up to an accepted root
certificate. The root certificate itself MAY be omitted from the
submission.
If a log accepts a submission, it will return a Signed Certificate
Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the
returned SCT as described in Section 9.2 if they understand its
format and they intend to use it directly in a TLS handshake or to
construct a certificate.
*_To:_*
A Submitter sends a certificate or pre-certificate (see Section 3.1
below) to one or more logs. This enables public monitoring of
certificates to facilitate detection of certificate mis-issuance. If
a log accepts a submission, it will return a Signed Certificate
Timestamp (SCT) (see Section 5.6). This document specifies the
interface to a log that a Submitter uses to log a certificate or
pre-certificate (see Section 3). A detailed specification of how a
Submitter should choose to submit a certificate vs. a
pre-certificate and how it should process the SCT that is returned,
will be described in a separate specification to be published later.
/*Sections 3.1 and 3.2*/
*_From:_*
3.1. Certificates
Anyone can submit a certificate (Section 6.1) to a log. Since
certificates may not be accepted by TLS clients unless logged, it is
expected that certificate owners or their CAs will usually submit them.
3.2. Precertificates
Alternatively, (root as well as intermediate) CAs may pre-announce a
certificate prior to issuance by submitting a pre-certificate
(Section 6.2) that the log can use to create an entry that will be
valid against the issued certificate. The CA MAY incorporate the
returned SCT in the issued certificate.
*_To: _*
3.1 Certificates and Pre-certificates
Anyone can submit a certificate to a log (see Section 6.1). It is
expected that certificate owners (Subjects) or their CAs will
usually submit certificates. Alternatively, (root as well as
intermediate) CAs may log a certificate prior to issuance by
submitting a pre-certificate. The log will use this to create an
entry and return an SCT that can be used to verify that the issued
certificate was logged (see Section 6.2). The CA may incorporate the
returned SCT in the issued certificate.
/[The rest of 3.2 defines both what the log should accept for a
pre-certificate and what the CA must do. So it should remain here
but also be duplicated in a requirements document for CAs. ]/**
/*Section 4 Private Domain Names*/
/**/
_*From: *_
Some regard some DNS domain name labels within their registered
domain space as private and security sensitive. Even though these
domains are often only accessible within the domain owner's private
network, it's common for them to be secured using publicly trusted
TLS server certificates. We define a mechanism to allow these
private labels to not appear in public logs.
_*To: *_
Some organizations regard some of the DNS domain name labels within
their registered domain space as private and security sensitive.
Even though these domains are often only accessible within the
domain owner's private network, it's common for them to be secured
using publicly trusted TLS server certificates. A detailed
description of mechanisms that a CA could use to support this will
be described in a separate specification to be published later.
/*Sections 4.1 Wildcard Certificates, 4.2 */***/Redacting Domain Name
Labels in Precertificates, and /*/*4.3 Using a Name-Constrained
Intermediate CA*/**
**
/[The text in these sections applies only to CAs and should be moved
to a requirements specification for CAs]/
***/Possible new section/*
**
If the log checks the syntax of a pre-certificate, then that should
be described in a new section called something like "Checking
Certificate Syntax ." Any syntax checking done by the CA should be
put in a requirememts specificatio/n/ for CAs.
/*Section 7 TLS Servers*/
/**/
*_From:_*
TLS servers MUST use at least one of the three mechanisms listed
below to present one or more SCTs or inclusion proofs from one or
more logs to each TLS client during TLS handshakes, where each SCT
or inclusion proof corresponds to the server certificate or to a
name- constrained intermediate the server certificate chains to.
Three mechanisms are provided because they have different tradeoffs.
*_To:_*
A CT-aware TLS server (certificate Subject) can present one or more
SCTs or inclusion proofs from one or more logs to each TLS client
during a TLS handshake. (A TLS server is considered to be CT-aware
if it is configured to send certificates with embedded SCTs or
inclusion proofs during a TLS handshake, or to convey SCTs
separately during the handshake.) Each SCT or inclusion proof
corresponds to the server certificate or to a name-constrained
intermediate CA certificate to which the server certificate chains.
The mechanisms by which the TLS server presents the SCTs or
inclusion proofs to a TLS client will be described in a TLS server
requirements specification that will be published later.
/[The rest of 7 and all of 7.1 should be moved to the//above
mentioned TLS server requirements specification.//]/
/*Section 8 (Certification Authorities), 8.1. (Transparency Information
X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate
Extension*/**
/[These sections defines only CA actions/behavior. They should be
moved to a requirements specification for CAs./*]
*
/*Section 12.3 (Redaction of Public Domain Name Labels*/
/[This subsection applies only to CAs. It //should be moved to a
requirements specification for CAs.]//*
*/
/**//**//*Section 12.5 Multiple SCTs*/
/**/
/[This//subsection applies only to CAs and clients. The text should
be moved to a requirements specification for CAs and a specification
for browsers.]/**********************
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
