Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidationis ambiguous

[Stephen Kent <[e-mail]>]

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