Eran,
In that case, how about including the CCID and the results of the
checks the log performed in the get-sth response, but not in the SCT
itself?
The SCT will be available to the client (in the cert or as part of a
handshake), so the CCID
needs to be there for the client to take advantage of it.
The log could still sign the complete get-sth reply so submitters get
a confirmation it is indeed the log which performed the checks, and
TLS clients will not be burdened with handling another field in the
SCT there's no immediate use for.
If, as Ben has recently suggested, there are few or no client mandated
client checks, then
all of the SCT data has no immediate use :-). More to the point, it
behooves us to decide on
an SCT format that need not change for a while, so as to minimize the
impact on clients and
Monitors.
As I said, I see the value in getting an "independent opinion" on the
validity of a chain submitted to the log (both in syntactic and
semantic compliance perspectives) and is much more useful than the
current error handling approach (where the log returns a vague error).
I just like to exclude this information from being embedded in the SCT
if it's not useful for TLS clients.
I think I've provided a few examples of how it might be used by clients.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
