Subject: Re: [therightkey] some CT questions/comments

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Jan 2013 12:35:48 +0000

On 7 January 2013 14:04, Carl Wallace <[email-masked]> wrote:
> Here are a few questions/comments on draft-laurie-pki-sunlight-05.
>
> - In section 2.1.4, should algorithm requirements be stated using RFC2119
> language?

Yes.

> - In section 3.2, why would multiple SCTs be included in a handshake - for
> sct version diversity, for log signer diversity, for certification path
> diversity, something else?

To increase the chance that one of the SCTs is valid (i.e. the log is
still accepted by the client).

>  Is there any required relationship between sct
> included in a handshake and certificates returned in the handshake?

I'm not sure what you mean? The SCT has to be for the end entity certificate.

>
> - In section 4, what key is subject to the "one-to-one" mapping - the
> server's TLS key or the log signing key?  I am assuming these are
> different keys and it means the log signing key, but this could made more
> clear.

Yes.

> In either case, why is this mapping necessary?  Given only the key
> ID appears in the sct, verification occurs with no knowledge of which <log
> server> prefix was employed.  Why impose a different requirement for these
> API calls?  The requirement interferes with mirroring log contents at a
> different <log server> prefix.

Hmmm. Good point.

> - In 4.1, if multiple clients submit the same certificate, is the same sct
> signature returned to each?

This is addressed in 3. "If the log has previously seen the
certificate, it MAY return the same SCT as it returned before"

> What if the path is different for different
> submissions?

Only the end entity certificate is used to make the SCT.

>  What should occur if the certificate contains log data
> already?

Nothing special, I think? i.e. it is just part of the data in the certificate.

>  Should it matter to a server operator if a certificate is
> already present in the log when he attempts to add the certificate to a
> log (probably not but this may be worth noting)?

I guess that depends what the provenance of the cert is, not sure I
have anything intelligent to say about that.

> - In 4.1, what is the output when the log refuses to log a certificate
> presented by a client?  Generally, all of the section 4 sections would
> benefit from discussion of error returns.

Already addressed.

> - In section 7.2, if a server operator wants to make sure there are no
> other certificates for names of interest, must the entire log be
> monitored?

Yes.

>  It'd be nice if there were a client message that took a domain
> name as input.

That is a service a monitor could provide to its clients.

> Of course, this could probably be achieved by sticking an
> X.500 or LDAP interface on the log instead:-)  Should a server operator
> take any steps if it finds a new sct that chains to a different root than
> the sct it includes in TLS handshakes?

I don't know, but I also don't think CT is a chain discovery
mechanism, just an end entity cert discovery mechanism.

> - In section 9, what does "new log" mean?  Doesn't the spec already
> support key rollover by simply including a different path in the <log
> server> prefix?  Why not just use that for key rollover and define a "log"
> as the <log server>/LogID pair?  If you are thinking about supporting
> multiple keys under the same <log server> prefix, the one-to-one mapping
> requirement in section 4 should be removed.

The note is there in response to a previous comment - in short, we
haven't really decided what to do, but my inclination was as you say -
define the log by its log id (I don't really see what the cost is for
a log server operator to start a new log compared to key rollover -
if, indeed, they even get a second chance).

> - I agree with JeffH regarding lack of TLS client (at a minimum)
> verification steps.

Agreed,.

> - It would be helpful if each type of client with different functionality
> (log, TLS, audit, monitor) were introduced early in the document and if
> unqualified "client" references were identified by type.

Its a bit tricky, since that would cause forward references to how
they perform their function - which would,. no doubt, lead to
suggestions that we should put the messages and log structure earlier
in the document...

Client references have been qualified anyway.

> - Having a client message to retrieve roots recognized by the log would be
> nice, to avoid having a client repeatedly attempt to submit certificates
> to the log that will be rejected.

Good idea, I can add one.

>
>
>
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Carl Wallace <[email-masked]>
Date: Sat, 12 Jan 2013 15:14:05 -0500

On 1/9/13 7:35 AM, "Ben Laurie" <[email-masked]> wrote:

<snip>
>I'm not sure what you mean? The SCT has to be for the end entity

OK.  I drifted in and out of recognizing the SCT only has the EE while the
messages to the server have the path.

<snip>
>certificate, it MAY return the same SCT as it returned before"

Missed that.  Thanks.  Why not MUST?

>Only the end entity certificate is used to make the SCT.

This could be made clear.  Seems like the log really doesn't care (or need
to care) about multiple paths to an EE.  Once it has an EE, the same SCT
can be used.

><snip>

That makes sense.

>mechanism, just an end entity cert discovery mechanism.

Got it.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 13 Jan 2013 13:30:53 +0000

> Missed that.  Thanks.  Why not MUST?

It makes it harder to build reliable infrastructure.