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

[Rob Stradling <[e-mail]>]

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