Rob,
...
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.
Glad to see we're on the same page now.
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.
I agree. BUT, the argument is being made that some (many?) CAs issue
certs that do not
comply with 5280, and that CT logs cannot reject such certs because such
sloppiness
is too widespread. That appears to be the rationale for the text you
cite below.
So, we are saying is that logs MAY reject certs that do not comply with
5280, for
any set of unspecified reasons, but there is no way for a submitter to
know which
logs do what checks, given the vast leeway accorded by the text below.
That results in
the non-determinism, which I see as bad.
(Note that my proposal to create a set of IANA-registered profiles for types
of certs, each describing syntax and other checks, might be applicable
here.
A log could enumerate the profiles against which it will perform
validation checks
and a submitter can indicate under which profile the cert was issued.
Just a thought.)
We don't want to encourage submitter CAs to needlessly violate RFC5280,
I agree!
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."
Your argument seems to be that by introducing ambiguity and uncertainty
into the
log validation process we will encourage CAs to adhere to 5280. That
strikes me as a
questionable design strategy.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
