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
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
