Subject: [therightkey] some CT questions/comments

From: Carl Wallace <[email-masked]>
Date: Mon, 07 Jan 2013 09:04:24 -0500

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?

- 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?  Is there any required relationship between sct
included in a handshake and certificates returned in the handshake?

- 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.  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.
 
- In 4.1, if multiple clients submit the same certificate, is the same sct
signature returned to each?  What if the path is different for different
submissions?  What should occur if the certificate contains log data
already?  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)?

- 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.

- 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?  It'd be nice if there were a client message that took a domain
name as input.  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?

- 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.

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

- 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.

- 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.