On Tue, Jul 1, 2014 at 11:45 PM, Rick Andrews <[email protected]> wrote:
> Symantec (and I suspect other CAs) would like more information about > what roots will be configured into log servers. > > Root Certificates: > The current spec includes a call to Retrieve Accepted Root Certificates. > Should we infer from that that the list might change over time? We expect > new roots would be added, but would roots ever get removed? For example, > browser vendors are in the process of removing 1024-bit roots from their > trust stores, and in the next few years we expect that SHA-1 roots might be > removed too. Would log server operators also phase out such roots? > The purpose behind requiring that submitted certificates chain to a set of accepted root certificates is to avoid the log being flooded with uninteresting certificates (e.g. self-signed certificates). To that purpose I do not think it matters if obsolete roots are removed because the log should not get submissions chaining to these roots. > > Once there are more than three log servers, we expect to decide up front > which log servers we will contact for SCTs. We do not expect to dynamically > query each log server to confirm that it still trusts our root, just before > attempting to log a certificate. Is that a valid assumption? > Yes - How a log operator changes the set of roots its log accepts is not specified in the RFC, but I expect log operators would communicate such changes beforehand. > > It would be preferable for the log server operator to publish a list of > roots and commit to supporting those roots until the CA informs the > operator that the root is no longer in active use, and all certificates > chained to that root have expired. > > > Cross-Certificates: > We have been providing cross-certificates to customers to deploy so that > their certificate could chain up to a 1024-bit root (for use in older > browsers without our 2048-bit roots). If the cross-certificate is ignored, > the end-entity cert chains up to one of our 2048-bit roots. We expect to > continue using cross-certificates until we determine that their use is no > longer required. We’d like to be sure that the use of cross-certificates > will not cause any problems for log servers. For example, take the case > where we log a certificate we’re about to issue (or have issued) and we > include the cross-certificate in the chain sent to the log server. Then the > customer (for whatever reason) decides to also send their certificate to > the log server, but without the cross-certificate. Will the log server see > this as the same certificate, and return to the customer the same SCTs? Or > will the certificate get logged a second time? If the latter, will that > cause any problems? > The SCT is over the certificate itself, not the entire chain, so that should not be a problem. As mentioned above, the log checks the chain just to prevent it being spammed. It shouldn't matter to the client if it gets the same SCT or not - as long as the log provides proofs for all SCTs it produces. The issue here is that to get a proof from the log the client has to provide the hash of the leaf in the tree, which is calculated over the certificate + timestamp from the SCT. If the log returns different SCTs from the same certificate it likely means it logged the certificate multiple times. Either way the client should get a valid inclusion proof. As a side note, it is beneficial if log operators keep obsolete roots in the set - that way it's easy to explain why a certificate was added to a log in the first place (since the chain that was in place when the certificate was added is never changed). > > -Rick > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
