Re: [Trans] defining "mis-issuance"

[Stephen Kent <[e-mail]>]

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