[cabfpub] SHA1 options for payment processors

[Doug Beattie]

Ryan – have you heard back from the team on this?  I’d like to keep this discussion going.

Is this an accurate summary of where we are?

Allow the cloning of an existing SHA-1 or SHA-2 signed SSL certificate (the Target Certificate) for the purposes of generating a SHA-1 signed certificate (the Cloned Certificate) as of the effective date of this agreement (ballot or some other agreement we can all point to?) and continuing until December 31, 2016 where:
- The Target Certificate must be posted to at least one Google and one non-Google CT log prior to May 31, 2016.
- The issuing CA must announce their intent to clone a certificate by posting a link (using crt.sh) on the Public list of each Target Certificate that they intend to clone.
- The CA must perform an OV level vetting and issue the certificate from a SHA-1 OV CA.
- The Cloned Certificate must be posted at least one Google and one non-Google CT log after issuance.
- The issuing CA must complete the disclosure and cloning process by sending links of the Target Certificate and Cloned Certificate to the Public list.
- The CA must keep a record of the certificates issued via this process for their auditors along with sufficient proof they followed this process, otherwise these would be considered mis-issued certificates.

The following fields in the Cloned Certificate must be identical to the Target Certificate
- Public Key
- Subject DN
- Certificate version (of course)
- SKI (if SKI is present in the Cloned Certificate)

The following will have values identical with the CAs standard policy for the type of SSL certificate being issued:
- AIA
- CDP
- CP
- EKU
- KU
- BC
- Issuer DN

The following will be present but the values will be different:
- NotBefore:  must be the current date/time and NotAfter where
- NotAfter:  must be no later than 12/31/2016
- Serial number with at least 20 bits of entropy
- AKI

Not to sidetrack the above process, but I’m still a bit concerned about how we handle those customers who don’t realize they have an issue until after May 31, 2016.  Would it be possible to require the CA to generate the key pair in these cases under auditable circumstances with the relevant disclosure to the public list?



From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, April 7, 2016 4:44 PM
To: Peter Bowen <pzb at amzn.com>
Cc: Andrew Ayer <agwa at andrewayer.name>; Doug Beattie <doug.beattie at globalsign.com>; Dean Coclin <Dean_Coclin at symantec.com>; CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] SHA1 options for payment processors



On Thu, Apr 7, 2016 at 1:30 PM, Peter Bowen <pzb at amzn.com<mailto:pzb at amzn.com>> wrote:
I would posit that it might be acceptable to even allow a short window (say now until May 31, 2016) to log SHA-1 or SHA-2 certificates that will be eligible for “cloning” to SHA-1 certificates.

That might work. There's a part of me that would like a "no backdating" ballot before that, but since that would equally rely on trusting the auditors to catch it (in the future), and since it wouldn't cover CAs that immediately started backdating once Andrew sent his email (Sorry, we have to assume an adversarial model), maybe it's not essential for this - and just separately good.

 However I would want to get an update from the team that published the free-start collision to see if they have made progress to a full collision before committing to that.

I've tried reaching out to the team to get feedback on your proposal, and will share whatever I hear from them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160411/67ac71d8/attachment-0003.html>