Re: [Trans] defining "mis-issuance"

[Rick Andrews <[e-mail]>]

Stephen,

You said "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."

It's doable, but it still leaves the CA in a bind. What if the CA wants to start issuing certs according to new CABF docs, but finds that none of the existing log servers support that version? This is probably a moot point, isn't it, because Melinda has reminded us not to introduce any normative dependencies on CAB Forum documents or processes.

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?
Agreed, but it puts a burden on the Subject. Before issuing any new legitimate certificate, the Subject would need to notify the Monitor of the new Subject name and/or public key. We've got some customers who issue thousands of certificates across their organization. IMO, the model might work better if the Monitor is simply a conduit, providing information found in log servers to the Subject, and then the Subject can decide if each new certificate was intentionally issued.


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?
See my comment above. Must the Monitor be able to decide by itself what is legitimate and what is mis-issued, or is that the role of the Subject, with help from the Monitor? In other words, couldn't we say that it's mis-issuance if the Monitor finds a cert in a log, forwards it to the Subject, and the Subject determines that it's mis-issued?

-Rick