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. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
