Re: [Trans] Cross-certificates and log servers

[Eran Messeri <[e-mail]>]

On Tue, Jul 1, 2014 at 11:45 PM, Rick Andrews <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>
>