Re: [Trans] Cross-certificates and log servers

[Ben Laurie <[e-mail]>]

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 <[e-mail]> wrote:
>
>
>
> 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.

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>