David,
On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent<[email protected]> wrote:
I disagree. Once Ben said that he meant mis-issuance to be interpreted in a
much broader context,
and cited EV cert requirements as an example, I pursued documenting what
that would mean. If
the WG wants to say that mis-issuance is more than issuing a cert to the
wrong Subject, then
we need to say just what it is, not hand wave.
You are missing the point of certificate transparency.
I may, since the definition of the goals seem to change over time.
We have no idea all the forms that misissuance -- particularly
malicious misissuance -- might take. If it were trivial to detect
"misissuance", browsers would validate certs for "misissuance" and the
problem would be solved.
History suggests otherwise. We have seen many examples of browsers not
performing cert path validation correctly, e.g., not paying attention to
the basicConstrants extension (with serious security consequences), etc.
So browsers are not a reliable way to deal with many cert-related
security concerns.
More to the point, CT is a set of external mechanisms designed to detect
mis-issuance that might not be visible to an individual TLS client. So your
argument that if it were trivial to detect, browsers would do it, is way
off the mark.
The point of having a log that includes everything signed with a CA's
key is that analysis of issued certificates can be conducted post-hoc.
Well, to be accurate, CRLs are not logged, as per the current proposal,
so it's not "everything signed with a CA's key." But, irrespective of
that detail, I am not suggesting that we alter the post-hoc analysis;
I was suggesting that there might be benefits to checking at the time
of issuance, principally in the case of pre-certs.
Proposals to limit the scope of what logs can log kneecap CT. They
should not be considered.
What CT does should or should not be ought to be justified based on an
analysis of attacks and what CT does to address them, not on blanket
statements
that mis-issuance cannot be defined.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
