[cabfpub] CT Precertificates and the BRs

[Ryan Sleevi]

Phil,

I fail to see how omitting the subject key can be argued as meeting the
security requirements of public auditability. Indeed, nothing would prevent
a CA from being compromised and issuing a new certificate - based on an
existing certificate - that contains an attacker controlled key. This may
be due to compromise or due to legal compulsion, and would be undetectable
by the public.

Surely you're not arguing that supporting compelled certificate issuance
would be a "feature"?


On Fri, Dec 20, 2013 at 12:56 PM, Phillip Hallam-Baker
<philliph at comodo.com>wrote:

>   An Experimental RFC is certainly not a bar to major protocol changes.
>
> Since any change would only impact verification, DigiCert would be
> unaffected. And we are told repeatedly that Chrome can be updated at will.
> So I don’t see you making a persuasive argument that it is too late to make
> changes.
>
>
> The parts of the cert that you cite as important are the parts that I
> agreed the CT entry needs to cover. The parts that I am dubious about are
> the serial number and the subject key.
>
> I don’t see you making an argument against excluding the parts of the
> certificate I suggested leaving out. You instead set up a straw man and
> argued against that.
>
> What I am proposing has far greater control than certifying an
> intermediate precisely because the EKU and other extensions can be
> included. It is actually strengthening the scheme over allowances already
> conceded.
>
>
>   *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Friday, December 20, 2013 3:19 PM
> *To:* Phillip Hallam-Baker <philliph at comodo.com>
> *Cc:* Rob Stradling <rob.stradling at comodo.com> ; public at cabforum.org
> *Subject:* Re: [cabfpub] CT Precertificates and the BRs
>
>
>
> On Fri, Dec 20, 2013 at 6:40 AM, Phillip Hallam-Baker <philliph at comodo.com
> > wrote:
>
>> 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.
>>
>
> As Jeremy has already pointed out, there is a deployed base of CT - Google
> and Digicert (
> http://www.digicert.com/news/2013-09-24-certificate-transparency.htm ),
> among others. There are people already examining the CT logs (using tools
> like https://github.com/agl/certificatetransparency ). There are clients
> validating SCTs (eg: https://twitter.com/reschly/status/410990449952698369)
>
> Finally, there is an IETF RFC assigned, the result of a very active
> discussion within the IETF.
>
>
>
>
>
>>
>>
>> 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.
>>
>
>
> While an interesting idea, it seems to fail to grasp some of the key
> benefits to CT.
>
> Such a proposal - to only bind precerts to certain elements of the cert,
> whether it be things like "just" the subjectAltNames - fails to consider
> the fact that CT represents a publicly-auditable record of issuance.
>
> We have seen repeatedly over the past several years - both in high-profile
> incidents like Trustwave, Diginotar, and Turktrust, and in smaller cases
> such as GoDaddy - where the stated CP/CPS (eg: as linked to within the
> certificate) is not adhered to. Whether this is intentional - such as a
> different interpretation of "issuance", as in the case of GoDaddy - the
> result of compromise, such as DigiNotar, or accident, such as TurkTrust, it
> remains a consistent problem.
>
> Google has, through our basic crawls that certainly fails to discover
> *all* certificates issued, continued to see this misissuance - RSA key
> sizes, validity periods, subject names, etc.
>
> If CT is meant to be a meaningful augmentation to the demonstrably
> inadequate WebTrust audits, then we really do need to cover all parts of
> the certificate that are governed by the BRs or the EVGs. And, as it turns
> out, that is the entire certificate - including extensions.
>
> Trying to chop up the cert into bits and pieces simply fails to accomplish
> that goal of providing a reasonable, publicly auditable trail of issuance
> and adherence. And, given the continued failure of audits to provide
> reasonable assurances, that is exactly what is needed at this time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20131220/7a9b3a6a/attachment.html