[cabfpub] CT Precertificates and the BRs

[Phillip Hallam-Baker]

If we are having to change policy to accommodate CT then I don't think the choice of using the serial number can be said to be 
working so well.

It is pretty easy to identify the record. If a cert is meant to be under CT control then we can require it to contain the record 
identifier in the cert. This could default to the serial number of the cert but a hash of the data entered would work just as well.

The CA knows the data to be entered when the cert is created, it is the publication of the logs and the log output that is delayed.


I am not sure what you mean by an intermediate not offering the same controls. If Carol's CA has registered a CT notification for 
alice.example that only specifies the issuer name and key, subject name a validity interval and extensions, then the log entry can 
be used to validate any certificate issued under that key. But Mallet CA can't issue a certificate because the CT entry is specific 
to Carol's signing key.



-----Original Message----- 
From: Jeremy Rowley
Sent: Friday, December 20, 2013 10:01 AM
To: 'Phillip Hallam-Baker' ; 'Rob Stradling'
Cc: public at cabforum.org
Subject: RE: [cabfpub] CT Precertificates and the BRs

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
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.
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public