[cabfpub] CT Precertificates and the BRs

[Stephen Davidson]

While the standards may not be scared texts, they are the basis upon which PKI software is designed.  Most "off the shelf" PKI software rigidly enforces the unique serial per CA.

I understand the benefits of CT.  Essentially it's a massive SSL search engine that allows anyone to datamine the activities of trusted CAs.  The plus side of this is that the value of attacks on SSL CAs will be reduced due to the reduced timespan before the badcerts are found.  It will also make it easier to punch down on CAs that are straying from established standards.  It also may increase poaching amongst CAs (aka competition) and perhaps even lead to some new business models.

I am however concerned that the cost of implementing CT has been dramatically underestimated.  The thought that "changing the CAs is cheaper than changing the servers/clients" is of small consolation when the cost of implementing CT may be prohibitive for some solid-but-smaller CAs that issue SSL, or there is limited visibility into when CT will be required or even when it will be widely enabled within PKI software vendors.

The big "monoline SSL" CAs that have limited cert flavors and their own PKI software may be able to drop in Google's code.  But the CA ecosystem is pretty complex, where CAs may be using outside RA or CA software, have individual issuing CAs that provide a mix of SSL and other cert types (which do not need CT logging), or have a complex hierarchy of issuing CAs that are capable of issuing SSL.  I appreciate that the designers of CT have provided multiple options to implement it, but at the end of the day it seems to me that the precert-from-actual-CA option is the only acceptable one at scale, and this may require many RA and/or CA implementations to be reconceptualised and rebuilt.

This is not without risk.  CAs know existing cert technologies and implementations that have been finetuned over time.  This CT stuff is amazing ... but let's face it, it will require CAs to bring in new skills and in many cases turn proven infrastructure on its head.  CT is an external dependency bang in the middle of the certificate creation process, the area where CAs are designed to be relatively inflexible.

Regards, Stephen



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Friday, December 20, 2013 5:29 PM
To: 'Rob Stradling'; 'Phillip Hallam-Baker'
Cc: public at cabforum.org
Subject: Re: [cabfpub] CT Precertificates and the BRs

Agreed.  Plus, a CT-type solution was not anticipated by the RFCs so this scenario can't be considered covered by the RFCs recommendations.  As mentioned on the call, I view them as the same certificate, so I don't see an issue with the same serial number.

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

On 20/12/13 16:34, Phillip Hallam-Baker wrote:
> 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.

X.509 and the PKIX RFCs are not sacred texts.  The BRs have deviated from them on a few points already: allow non-critical Name Constraints, disallow OCSP "good" for non-issued certs.

To repeat my question:
If there are 2 certs (a Certificate and its associated CT
Precertificate) with the same Issuer Name and Serial Number, what exactly would break in the WebPKI?

An RFC6962 Precertificate/Certificate pair MUST be revoked together, so from this point of view sharing the same Issuer Name and Serial Number is actually desirable.

Yes, RFC6962-bis could specify a non-X509v3 format for Precertificates, but that would be reinventing the wheel.  Not impossible, but (for those who have already implemented RFC6962 Precertificates, including me) not desirable either.

What would be the tangible benefit(s) of disallowing the same Issuer Name and Serial Number for a Precertificate/Certificate pair?

<snip>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public