On 07/07/15 20:23, Stephen Kent wrote:
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.
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.
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!"
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?
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?
Clearly the answer is no. So why should CT be expected to achieve a
higher standard of determinism than TLS?
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.
Actually, I don't expect the level of CA adherence to 5280 to increase
or decrease due to this strategy.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
