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