Rick,
Thanks for the comments.
-------
1. Certificate Transparency Goals and Mechanisms
The goals of Certificate Transparency (CT) are threefold: detection,
deterrence, and enabling remediation of mis-issuance of certificates.
The initial focus of CT is the Web PKI context, (The Web PKI context
refers to the use of a set of Certification Authorities (CAs) that
issue X.509 certificates to web servers to enable TLS-protected access
by clients [cite WPKOPS?].) In the future, it is anticipated that
addition **additional** operational contexts may be supported. As a
result, mis-issuance is defined in an fashion that accommodates a
range of types of certificates used in a range of contexts.
CT supports detection of mis-issuance using logs of certificates,
populated by the CAs that issue them or by the Subjects of
certificates. Monitors (described in Section *X*) are the primary
elements of the CT system that check certificates for syntactic and
semantic mis-issuance, on behalf of Subjects. A Monitor may be
operated by a third party on behalf of Subjects, or may be operated by
a Subject on its own behalf. (The latter is referred to as
"self-monitoring".) Logs may optionally perform syntactic checks for
some classes of certificates, but a log is not required to offer
certificate checking.
The first sentence needs to be more broad, since anyone can send a
cert to a log. But it's most likely to be the CAs or the Subjects, so
I would suggest "CT supports detection of mis-issuance using logs of
certificates, populated by the CAs that issue them, by the Subjects of
certificates, or by anyone with knowledge of the entire certificate
chain.".
I'll use your text here, thanks.
To enable Monitors (and, optionally, logs) to perform an appropriate
set of checks, the (pre-) a CCID MUST be provided to a log when a
certificate is submitted by a CA or Subject. This CCID MUST appear in
the log entry and in the SCT generated by the log. By providing the
CCID in logs and SCTs, both Monitors and clients are empowered to
perform applicable checks based on the certificate class asserted by
the CA or Subject.
Hmm... Since anyone can send a cert to a log, the first sentence must
reflect that. But that makes me wonder what should happen if the
"Reporter" (I don't want to introduce a new role) sends the wrong
CCID? (By "wrong" I mean it's a valid CCID, but it's not the one that
the CA would associate with the cert.) Or sends the cert multiple
times with different CCIDs? I guess Monitors would have to expect
multiple entries for a given certificate in a given log, with
different CCIDs. I'm not sure if 6962-bis imposes any uniqueness
constraint that this might violate.
Thanks for catching the typo. If a (pre-) cert is submitted with a CCID
that is inappropriate
for the cert type, then there can be several outcomes, depending on the
nature of the error and the log operation. If a cert class not yet
accepted by the log, the log will not try to check it, and it will be
marked that way.
If the log does check the CCID in question, the cert may fail (but will
still be logged) because the wrong syntactic checks were applied. The
CA/Subject/other will get immediate feedback on that, which might cause
re-sumbission to the log, with the right CCID.
If the same cert is sent multiple times, with different CCIDS, this is
something a Monitor will notice, if it's protecting the name in the cert
in nquestion. The Subject should be notified of this anomalous behavior.
An Auditor might note this behavior as well; we'll see when we have a
concrete description of the functions that an Auditor performs.
In any case, I don't see the multiple CCID situation as a problem for
CT; it does provide more info to those watching logs. Since the same
cert may be submitted to a log by multiple entities (CA, Subject, nosy
3rd party) already, I don't see any uniqueness constraint issues from
6962-bis.
A log MUST generate a Syntax Verification Value (SVV) for the
certificate, and include the SVV in the log entry and in the SCT.
The LVV**SVV**is **a** value specified by this document (see Section
Z) that indicates whether or not the log performed applicable
syntactic checks, and whether the (pre-) certificate passed of **or**
failed the checks. Although it is anticipated that new certificate
classes will arise over time, the set of log actions with respect to
syntax checking appears to be well-defined and thus need not be
represented in an IANA registry. Each SCT issued by a log MUST include
an SVV.
thanks again for catching that typo too. Santosh also noted this in a
message to me.
Value Interpretation
0The CCID value was 0, so not **no** checks were performed
Again, thanks for catching this typo.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
