On 06/07/15 20:50, Stephen Kent wrote:
Rob,
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 think may have misunderstood my point. I did not request that a log
return an error indicating why a cert failed the logs checks. I asked
that there be a deterministic way for a submitter to know whether a
cert will pass.
Ah, I see.
That can be accomplished in (at least) two ways:
establish a standard set of checks that all logs perform
The I-D already says:
"Logs MUST accept certificates that are fully valid according to RFC
5280 [RFC5280] verification rules and are submitted with such a
chain."
So the "deterministic way for a submitter to know whether a cert will
pass" is for the submitter to ensure that the cert is fully compliant
with RFC5280 verification rules and is supplied with a chain up to a
root cert that the log accepts.
We don't want to encourage submitter CAs to needlessly violate RFC5280,
so I see no good reason why we should turn the following behaviour into
something deterministic:
"Logs MAY accept certificates and precertificates that have
expired, are not yet valid, have been revoked, or are otherwise not
fully valid according to RFC 5280 verification rules in order to
accommodate quirks of CA certificate-issuing software."
, or establish a way to each log to state what set of checks it performs.
Steve
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
