On 06/07/15 17:00, Stephen Kent wrote:
Rob,

Having a cert rejected does not tell the submitter (CA or otherwise)
why, and thus the submitted doesn't know how to resolve the problem.

Are the folks that work for (sloppy) CAs really incapable of reading RFC5280 for themselves, incapable of examining their rejected certs to discover the problem(s) for themselves, and incapable of finding a suitable mailing list on which to ask questions if they get stuck?

I really don't see why we should over-complicate CT logs just to assist sloppy/lazy/incompetent CAs that are already expected (by the various web browser root cert inclusion programs) to be familiar with RFC5280.

It's likely that CT logs will not implement their own RFC5280 certificate processing code. The certificate-transparency.org code, for example, uses OpenSSL. If OpenSSL rejects a blob of data that is allegedly a cert, the error stack doesn't always explain precisely why the blob of data was rejected. Sometimes you just have to resort to reviewing an ASN.1 dump or firing up a hex editor. So I think the implication of what you're requesting might be that CT logs cannot use third-party RFC5280 certificate processing libraries at all!

Do any other IETF protocols that validate certs return a precise explanation for rejection if rejection occurs? I don't see a fully enumerated list of reasons for rejecting a "cert" in the TLS 1.2 spec, for example. So why should 6962-bis be required to do this?

Steve

On 06/07/15 16:06, Stephen Kent wrote:
If there is no standard for the validation checks logs perform, because
of a desire to accept malformed certs from (sloppy) CAs, then a CA
cannot
know whether its submission will be rejected by a log.

Huh?  Why can't the (potentially sloppy) CA call add-chain (or
add-pre-chain) and see what happens?

Either the log will return an SCT (in which case it accepted the
submission), or it won't (in which case it rejected the submission).

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to