Matt,
On Thu, Feb 26, 2015 at 03:37:04PM -0500, Stephen Kent wrote:
Ben,
My thinking is that:
1. There is concern, generally, about the size of certificates (really
about the size of handshakes).
That concern varies a lot, depending on context. I don't agree that this
is a universal, major concern. Look at JSON; it's use of XML encoding
suggests no concern about bloat in a web context.
This isn't a *web* context, though; it's a TLS session establishment
context. Bloating the handshake so as to require an additional round trip
increases session establishment time, which degrades user experience --
something which is generally considered a bad thing.
The charter for the WG says:
"The working group will produce a standards-track version of the
experimental RFC 6962
*for HTTP over TLS*, ..." so I think it's appropriate to discuss this in
the web context.
3. Embedding SCTs in certs runs the risk that the SCTs will become invalid
before the cert does.
until we have a precise description of how a client will deal with an
invalid SCT, we can't really evaluate the implications of this potential
mismatch. Also, what causes an SCT to become invalid?.
An SCT becomes invalid when the log which issued it ceases to be trusted by
the browser.
Thanks for that clarification. But, since there is no spec for client
behavior,
the notion of a browser no longer trusting a log is undefined at this
time. Also,
there is no description of how a web site operator will learn that some
non-trivial set
of clients no longer trust a given log, and thus the operator will be
motivated to
acquire a new SCT for his cert from another log. Finally, the text above
refers to a
cert becoming "invalid." Does this mean the cert is revoked, or does
this refer to a
cert expiring? if the latter is intended, then it is preferable to use
the correct term.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
