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

[Rob Stradling <[e-mail]>]

On 14/07/15 15:38, Stephen Kent wrote:
<snip>
>> The "profile" for Google's logs would be something like this:
>>
>> "We accept whatever OpenSSL accepts.  Good luck!"
>
> and is Google's log acceptance criteria the only one that counts?

No.

<snip>
>> For example, when a TLS server sends its cert chain to a TLS client,
>> can the TLS server know, deterministically, that the TLS client will
>> either accept or reject the cert chain?
>
> in principle, only the lack of an agreed upon trust anchor should cause
> a compliant client to reject a cert from a server (ignoring local policy
> controls).

Ditto for CT.  i.e. in principle, only the lack of an agreed upon trust 
anchor should cause a compliant log to reject a cert from a submitter.

> Servers rely on the ubiquity of trust anchor stores to reduce the
> likelihood that validation will fail on that basis.  So, for all
> practical purposes, a server can have high confidence that its cert will
> be accepted by browsers, if the cert is issued by a CA that is
> widely represented in the (almost uniform) trust store.

I disagree.  Only if the CA issues 5280-compliant certs can they have 
that high confidence.

For example, recently one CA was found to be incorrectly encoding 
basicConstraints.CA=FALSE by explicitly including the FALSE value even 
though FALSE is the DEFAULT (and DEFAULT values must not be explicitly 
included).  This was discovered when a popular browser maker tightened 
up their DER decoding code and the certs stopped being accepted.

>> Clearly the answer is no.  So why should CT be expected to achieve a
>> higher standard of determinism than TLS?
>
> two observations:
>      first, I disagree that the TLS example above is a probative as you
> suggest.

TLS clients and CT logs both need to verify certificate chains that they 
receive, and it's very likely that they'll use existing certificate 
chain processing libraries rather than roll their own code.

So there will be OpenSSL-based TLS clients that encounter 
5280-non-compliant cert chains, and there will be OpenSSL-based CT logs 
that encounter 5280-non-compliant cert chains.  In both cases, OpenSSL 
does the certificate chain verification.

>      second, we have years of experience with what's wrong with TLS in
> terms of cert processing, and hopefully we can do better with this
> effort, when we create new ways to introduce non-determinism.

I agree that it would be nice to do better, but I just don't see how 
anyone could ever complete the task of enumerating all of the ways in 
which 5280 can be violated (including all of the ways that haven't even 
been thought of yet) such that there can be a list of profiles detailing 
which sets of violations are tolerated and which aren't.  It would be a 
constantly moving target, entirely unsuited to being an IANA registry.

I can recall a couple of bugs in Comodo's ASN.1 code over the years that 
have led to some certs being issued with "minor" ASN.1 encoding errors. 
  In both cases, the affected certs seemed to "work" fine everywhere 
until a new version of OpenSSL was released that no longer tolerated 
those particular encoding errors.  So what did I do?  Did I blame 
OpenSSL for breaking my certs?  No.  Did I blame IETF for not 
enumerating all possible encoding errors?  No, that didn't even occur to 
me!  I blamed myself ('cos I wrote the code that had the bugs), and I 
fixed the bugs.

If, in the future, any CT logs start to reject Comodo certs and this 
leads to the discovery of another bug in my ASN.1 code, I will blame 
myself and fix the bug.  I don't want CT to be vastly overcomplicated 
just so that CA bug authors such as myself aren't required to put in 
some effort (reading 5280, reviewing the OpenSSL source code, asking 
questions on mailing lists, etc, etc) to diagnose and fix our mistakes.

Assuming I've still not convinced you, then let's agree to disagree. 
You think achieving determinism is practical, and I really don't.

>>> 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.
>>
>> Actually, I don't expect the level of CA adherence to 5280 to increase
>> or decrease due to this strategy.
>
> I don't either, yet that seems to be a part of the argument you made.

It really isn't.

> Steve

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online