Rick,
Thanks for taking the time to review my initial cut at an Appendix.
I have made changes to reflect all of the typos you noted.
Also, although I like the idea of log servers rejecting
syntactically-invalid certificates, that may create problems for CAs
because the CABF requirements have changed over time and will likely
change in the future. Any changes would have to be rolled out to log
servers and browsers in time to prevent rejection of a valid certificate.
Your observation about the need to coordinate CABF requirements changes
with what log servers
would check gave me an idea. Why not have the add (pre-cert) chain to
log request specify
whether the cert being added is to be checked against DV or EV specs,
and note the version
of the DV/EV spec to be used? This would make it easy for the log to
know which set of
checks to employ. Since each log needs to advertise a set of data about
itself anyway
(e.g., what root CAs it supports), it could also advertise the set of
specs against which
it is prepared to check submissions. This way a CA or Subject would know
whether the log
was prepared to accept a chain for checking under the selected criteria.
Note that a Monitor
could not perform checks as easily, because it does not interact
directly with the entity
submitting the log request. I think that argues for logs performing
these checks.
*A.2 Semantic Verification of a Certificate *
Nonetheless, a Monitor can "protect" specific Subjects, based on
reference data provided by these Subjects. A Monitor trying to
determine that a certificate has been issued to the "right" Subject
can do so using the certificate(s) issued to the Subject, as a
reference. For example, if a Monitor is providing "protection" for a
Subject, it requires the name of the Subject (as it appears in the
Subject field or subjectAltName extension) and the public key
associated with that Subject. Armed with this information, a Monitor
can examine every log entry to determine if it contains the same
Subject or SubjectAltName. If a log entry matches either of these
names, and if it contain a different public key, this is evidence of
mis-issuance.
There's no requirement that a Subject be associated with a single
public key. In some cases, web site owners generate a different key
pair on each machine behind a load balancer, and apply for
certificates with the same Subject name but different key.
I'm not sure if you've captured the type of mis-issuance that CT was
originally intended to detect: when a hacked, faulty or rogue CA
issues a certificate to a Subject without the Subject's knowledge. The
Monitor alone cannot detect that. It can report to the Subject that a
certificate was logged for the Subject, but only the Subject can tell
if that was a valid issuance or mis-issuance.
Your observation is correct; that's what I get for trying to write a
quick description of
the algorithm for this. Accommodating multiple keys per Subject is easy
to fix.
For example, if a Monitor is providing "protection" for a Subject,
it requires the name of the Subject (as it appears in the Subject
field or subjectAltName extension) and the public key(s) associated
with that Subject. Armed with this information, a Monitor can
examine every log entry to determine if it contains the same Subject
or SubjectAltName. If a log entry matches either of these names, and
if it contain a public key other that the one(s) provided by the
Subject, this is evidence of mis-issuance.
If the Subject provides a list of all o the keys associated with the
Subject, perhaps in the form
of certs issued to the Subject (and currently valid) this would enable a
Monitor to detect this form of mis-issuance, agreed?
A separate topic is issuance of a bogus cert for a Subject who doesn't
have a cert issued legitimately.
In this case there is no reference cert to present to a Monitor. It may
be hard for a Subject who
doesn't have a cert to convince a 3rd party Monitor to check for certs
issued to the Subject name
in question. Should we classify this as mis-issuance as well?
Steve
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
