Re: [Trans] Goals and generic mis-issuance fgramework

[Stephen Kent <[e-mail]>]

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