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

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Nov 2014 08:54:55 -0500

Russ,

Sorry I didn't get to this sooner, vacation, etc. I see that Rick 
already replied, but for
completeness ...

> ...
>
> Can't anyone build the certificate chain?  Since the logs are posting 
> the supported trust anchors, anyone can build a chain for the end 
> entity certificate.
Anyone can build a cert chain that should be accepted by a log, if the 
chain is "valid" relative to
one of the CAs for which the log says it will accept certs. I think this 
is why Rick suggested that I
make the fist sentence of the second paragraph more general, which I have.
> ...
>
> Alternatively, a log could check to see if the reported certificate is 
> already present, and if so, return the older entry to the party that 
> reports the certificate.  I seem to recall reading this idea at some 
> point, buy I admit I did not look into the current I-D to see if that 
> was where i read it.
I believe you're correct, i.e., a log may, at its discretion, return the 
SCT it generated previouslythen
if a duplicate cert is submitted.
>
>> ...
>
> If the log performs some validation checks, are you suggesting that a 
> relying party can leverage the work already done by the log?  If so, 
> it puts the log checking at a different place in the certificate 
> validation than I was imagining.
That's not what I meant to imply. I was saying that if an entity 
submitting a cert to a log asserted
the type of cert, then  a Monitor and/or a client knows what additional 
checks it ought to perform,
based on the assertion. So, for example, if a client gets a cert that 
the log entry and SCT say is
an S/MIME cert, but the cert has been submitted in a Web PKI context, 
this might raise an alarm. Also if
a log states that it performed syntax checks for the indicated type of 
cert, and a Monitor or client
performs the same checks and gets a different outcome, this should raise 
doubts about the log.

Nonetheless, I guess a client might choose to rely on cert validation by 
a log, although
one should do so only if one has confidence that the log (or a set of 
logs that all agree the
cert was valid) can do a better job than the client. Given experience 
with some browsers, that
might not be a bad idea ;-).

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Nov 2014 09:03:01 -0500

> Nonetheless, I guess a client might choose to rely on cert validation by a
> log, although
> one should do so only if one has confidence that the log (or a set of logs
> that all agree the
> cert was valid) can do a better job than the client. Given experience with
> some browsers, that

And so the TRANS notary becomes a trusted critical component rather
than a transparent notary whose actions are completely constrained by
the Harber-Stornetta block chain...

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Nov 2014 09:07:07 -0500

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Nov 2014 14:55:36 -0500

PHB,
> On Mon, Nov 24, 2014 at 8:54 AM, Stephen Kent<[email-masked]>  wrote:
>> Russ,
trusted by a client IF it elects to do so. as I said, given the 
performance of _some_ browsers, this is not necessarily a bad idea, and 
it would be up to the user to make this decision.

Steve