On 7 January 2013 14:04, Carl Wallace <[email protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
