[cabfpub] CT Precertificates and the BRs

Jeremy Rowley jeremy.rowley at digicert.com
Fri Dec 20 15:01:07 UTC 2013

On 1, there is a deployed base for CT as of October.  It's not a big base,
but there are some. 

On 2, you need a way to look up the proof in the log server.  If you don't
use the certificate serial number, you'll need a log-proof serial number or
similar identifier.  I don't see an advantage in creating a brand new
separate identifier when the serial number works so well. 

An intermediate doesn't provide the same controls as CT since it doesn't
restrict other CAs from issuing the certificate.  Although a multi-party
signature scheme that included pinning could provide a similar solution,
Ryan pretty clearly explained why this is impractical over CT.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Phillip Hallam-Baker
Sent: Friday, December 20, 2013 7:41 AM
To: Rob Stradling
Cc: public at cabforum.org
Subject: Re: [cabfpub] CT Precertificates and the BRs

We seem to be getting a lot of confusion here, lets start from first

1) Is there a deployed base for CT? NO

Therefore the CT code is completely changeable. We are not restricted by the
current formats or solutions. If there is an incompatibility with deployed
infrastructure we can do that.

2) Is there a need for any CT record to bind to the certificate serial
number data?

I can't see one. The transparency criteria is for issue of certificates that
are signed by a particular CA that bind to particular names under specific

The less information that the CT binds to, the more coverage a CT record
gets. For example, a cloud service has 1000 certificates with separate keys
for each, do they really need to have an independent CT block for each one?
For example, a service refreshes its certificate every hour with a very
short expiry period to avoid the need for revocation processing, does it
really need to get a new CT authorization per certificate issue?

Including the certificate serial number and the subject key in the CT record
should both be optional. Including them does not seem to reduce the attack
surface in a meaningful way but it certainly constrains the operation of the
End Entity device.

In a cloud computing environment the service can be moving from machine to
machine on a very short cycle. I am old fashioned, I don't think private
keys for signature or exchange should ever be used on more than one machine.
So I would like to see a scheme where the certificates and keys flow into
the machine where they will be used along with the VM image and expire
within a day. 

Binding CT records to the subject keys and the serial numbers in the public
transparency records seems like a bad move to me. It would provide a huge
amount of information to an attacker on the internal workings of cloud
providers and big infrastructure players like Akamai (and Google).

If there was a customer that really wanted to have fine grain control over
cert issue then the appropriate way to handle that requirement would be for
the CA to issue them a sub CA with name constraints and give them partial
control over the signing key through a multiparty signature scheme. But I am
not sure which (if any) HSMs would support the capabilities needed and it
would be a huge engineering investment.
Public mailing list
Public at cabforum.org

More information about the Public mailing list