Ben,
...
Again, I disagree. We should define what we can and make design decisions
based on that definition. Anything else that might be considered
mis-issuanve,
is out of scope for purposes of this work. This is the sort of delineation
that
we often impose on RFCs; we define a scope for a standard and declare that
other
stuff is out of scope, relative to the standard.
Then perhaps we should have a broader scope. Focusing on mis-issuance
seems to lead to all sorts of, IMO, unnecessary complications.
I'm may get in trouble for saying this, but it seems as though the
"complications"
to which you allude are just the result of taking the terms that have
been used
to motivate development of CT and making them concrete, rather than
ambiguous.
If a "broader scope" means using more ambiguous terms, I can't see why that
would be an improvement.
It might be simpler to define CT as a mechanism for allowing the
public examination of the contents of all issued certificates, without
getting into exactly what might be done as a result of that
examination. Detecting mis-issuance is, of course, an obvious example.
I'm very bothered by your suggested change of focus. For me, this
characterization of
CT is way too vague for an IETF security standard (vs. an experimental RFC).
It leads a reader to imagine that we don't have a simple, sound,
defensible argument
for why we're pursuing this technology. It has the flavor of "CT is
obviously good,
so let's just do it." (pardon me for putting words into anyone's mouth.)
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
