Subject: [Trans] Cross-certificates and log servers

From: Rick Andrews <[email-masked]>
Date: Tue, 1 Jul 2014 15:45:12 -0700

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?

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?

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?

-Rick

---

From: Eran Messeri <[email-masked]>
Date: Wed, 2 Jul 2014 11:33:18 +0100

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 2 Jul 2014 12:34:08 +0100

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-masked]> wrote:
>> Symantec (and I suspect other CAs) would like more information about what
>> roots will be configured into log servers.
>>
>> Root Certificates:

Equally, it doesn't matter if they're still allowed - unless they
suddenly become spammy.

> specified in the RFC, but I expect log operators would communicate such

Exactly so.

>> 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:
>> 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.

> 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
>>
>>

---

From: Matt Palmer <[email-masked]>
Date: Tue, 15 Jul 2014 15:24:10 +1000

As someone who is looking to run a log server, I'll answer with my personal
opinions.

On Tue, Jul 01, 2014 at 03:45:12PM -0700, Rick Andrews wrote:
> 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?

Since roots are only there to prevent mass-spammage, the only circumstance
in which I would foresee a root certificate being removed from the log's
trusted set would be if it went so totally rogue it was issuing a huge
volume of certificates and submitting it to the log.

Quite frankly, if you get control of a root or intermediate CA certificate's
signing key, and the most valuable thing you can think to do with it is spam
a CT log, you need to get out more.

> 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?

Completely valid.

> chained to that root have expired.

Darn tootin'.

> 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 Signed Certificate Timestamps identify the end-entity certificate being
signed, and a timestamp of when it was accepted for inclusion into the log. 
My implementation, at the very least, re-issues the same SCT if it sees the
same certificate again, regardless of the method by which is it chained to
one of the trusted root certs.

On a related point, I'm intending (until circumstances prove it to be a
foolhardy notion) to be *very* liberal in what roots I accept -- I'll
probably pre-populate with the trust stores of the browsers, etc, but I'll
have a form or something you can paste your root CA cert into and I'll add
it, unless you're obviously trying it on.

- Matt

-- 
When I was a kid I used to pray every night for a new bicycle. Then I
realised that the Lord doesn't work that way so I stole one and asked Him to
forgive me.
		-- Emo Philips