[cabfpub] CT Precertificates and the BRs
philliph at comodo.com
Fri Dec 20 14:40:37 UTC 2013
We seem to be getting a lot of confusion here, lets start from first principles.
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 policies.
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.
More information about the Public