Kyle,
I don't disagree with your observation that, in a broader context, other
client
behavior might be appropriate. But the CT doc we're discussing is
focused on TLS, and
we should not try to broaden that scope at this time.
In the TLS client context, I agree with Fabrice that the description of
(TLS) client
behavior is not yet sufficiently precise to yield predictable results.
If we're going
to claim that CT solves a problem, and thus merits imposing changes on
how CAs issue
certs and how all clients process them, the doc needs to define client
behavior with
sufficient precision to substantiate this claim.
Steve
The more you apply your own "best idea" decision tree, the more you
restrict perfectly valid options that would otherwise be legitimate by
the spec, in the name of "interoperability". This is why, for example,
Netscape's insistence on a "trustworthy" (which really devolves to
"known, without judgment of trustworthiness") certifier managed to
create a new and completely artificial cottage industry that suffered
artificial stunted growth patterns... because it insisted on
ITU-standard authentication before anyone knew what it was really good
for. It also basically destroyed one of the use-cases explicitly
permitted by the spec, that of the unauthenticated connection.
Don't insist on a client-protocol stapling. Not everything uses TLS --
and even though TLS is the intended use case, leaving low hanging
fruit for other protocols is probably better than binding it so
tightly to TLS that no one can conceive of a use aside from that binding.
-Kyle H
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
