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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
