I've added the ct-policy mailing list, which might be a better venue for this question, at least for Google's logs.
To be clear, I don't think we can dictate what roots logs accept, though certainly the advice is "all roots accepted by common browsers" - which is a little vague, but hard to nail down further. This is certainly Google's current plan. On 2 July 2014 11:33, Eran Messeri <[email protected]> wrote: > > > > 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. Equally, it doesn't matter if they're still allowed - unless they suddenly become spammy. >> 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. Exactly so. >> 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. Not just for that reason: also so that there is a clear path for revocation, should the certificate be bad in some way. > 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. In general, our log is unlikely to produce more than one SCT for the same certificate, but it can happen (that's a result of engineering tradeoffs for reliability vs. availability). > 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 > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
