Rob,
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.
Yes. Such sloppiness is too widespread for WebPKI browsers to enforce
strict 5280 compliance. Since CT is concerned with protecting the
WebPKI ecosystem, it must follow suit. Otherwise, it would be trivial
for a bad CA to issue a cert that won't be logged by CT but will be
accepted by browsers that don't require CT.
agreed.
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.
I'll admit it's not ideal, but I think that we would get lost in a
maze of ratholes if we tried to do it any differently.
(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.
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?
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.)
Do any other IETF protocols that validate certs do this?
Some IETF protocols call for certs to be validated as per 5280, even if,
in practice,
implementations often fail to do so. As a standards body we try to
establish desirable
behavior for implementations, knowing that we may not always succeed.
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).
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.
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.
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.
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.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
