[cabfpub] SHA1 options for payment processors

[Ryan Sleevi]

On Mon, Apr 11, 2016 at 5:39 AM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

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

I can't guarantee that there will be any feedback, nor should we gate it.


> Is this an accurate summary of where we are?
>

I don't believe so. You seem to have introduced several new requirements,
and also omitted several others - such as the previously discussed
public-discussion and set of questions. As expressed previously, this is
for us something that is mandatory to even consider such issuance.


>
>
> 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.
>

You've seemingly introduced this as a new requirements. As I've expressed
multiple times in the Forum, I think it would be fairly inappropriate to
mandate, via the CA/Browser Forum, any dependency on Google infrastructure,
much like it would likely be inappropriate to mandate any dependency on
Microsoft, Apple, Mozilla, Opera, or Qihoo360.


> - 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.
>

This omitted several steps from past discussion.


> - 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.
>

This also omits the previous discussion of all such audits becoming
qualified audits.


> 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
>

This isn't the same as what was discussed previously, and introduces new
attack surface via unspecified extensions.

And while this was floated as an option, I'm not sure it's necessarily an
appealing one, because of this. The unease caused by this, and opportunity
for abuse, perhaps should mandate that you simply must use the pre-existing
certificate, and if unavailable, that the issuance of SHA-1 may not be
available. This is objective and vendor-neutral, but it does mean that some
CAs may not be able to offer such services, just as some CAs may not offer
EV certificates.


> 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?
>

Unfortunately, I think this gets to the heart of why such discussions about
SHA-1 extensions are problematic - because now you're exploring ways to
indefinitely issue them, which directly undermines the ability of the
CA/Browser Forum to set any reasonable policies in the future, or sunset
anything on an effective timetable. At some point, enough is enough - and
if you didn't realize by Jan 1, 2016 - despite years of warning - and
didn't realize by May 31, 2016 - despite half a year of effort - I don't
believe it's reasonable to expect or accept you're being a responsible
participant in the Web PKI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160411/b27bd2b6/attachment-0001.html