[cabfpub] LV Certificates

Doug Beattie doug.beattie at globalsign.com
Mon Dec 21 06:30:49 MST 2015


Hi all,

 

To summarize I see the following changes in this ballot proposal. LV
Certificates must:

  1) use SHA-1

  2) not expire after 31 March 2019

  3) have Serial numbers that contain at least 20 bits of entropy

  4) be OV (or EV?) validated

  5) have a new unique Policy OID in them

  6) be issued under new LV dedicated CAs

  7) be issued only as "replacements" for SHA-2 signed certificates

  8) only be used by the server if the server believes the client of the TLS
session may not support SHA-2.

 

As far as I could tell, there are no penalties if the subscriber serves up
an LV certificate to relying parties that might/can process SHA-2, nor are
there obligations on the CA to enforce compliance with this.  Won't everyone
just ask for SHA-1 certs and use them?  As the browsers ratchet up the
warnings and speed- bumps subscribers will be highly motivated to either use
only SHA-2 or to implement server logic to only serve up SHA-1 to browsers
that don't block or complain about SHA-1.  I don't see the point of the
creating a while new class of certificates for this.  Let the subscribers
decide what hashing algorithm to use and when,

 

This seems like a lot of work for CAs and subscribers "just" to continue the
issuance and use of SHA-1 certificates for this class of customers.  Is
there really a benefit in this proposal over allowing continued issuance of
OV/EV SHA-1 certificates under existing CAs and policies except with the new
maximum certificate expiration date and requiring 20 bits of entropy?

 

a) Why do we not allow issuance for DV (item 4)?  These are commonly used by
web hosting companies and are likely the most widely deployed and used
today.  They should not be precluded.

 

b) Why is there a requirement for a new CA and new OID (items 5 and 6)?  You
can tell which are LV because of their not-before date and hashing
algorithm, so what is driving this requirement?  Are the browsers going to
process this OID and do something different?  Consider a requirement to post
them to CT logs instead if it's important to track issuance.

 

c) Why must they be issued only as replacements for SHA-2 certificates (item
7)?  Some subscribers will need only SHA-1 and know it from the beginning
(legacy backend systems for example), so what's the point of this
requirement?

 

If we're going to allow continued issuance of SHA-1 then let's make sure
we're not vulnerable to known plain-text attacks (add the entropy
requirement) and continue issuing them under the existing CAs and processes.
I don't see the benefit to all of the other proposed changes, so I'm
probably missing something.

 

Doug

 

 

 

 

 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Friday, December 18, 2015 5:22 PM
To: CABFPub <public at cabforum.org>
Subject: [cabfpub] LV Certificates

 

Hi everyone, 

 

Attached is a proposal from Cloudflare and Facebook creating LV certificates
in the baseline requirements.  This is a draft ballot for review that will,
of course, change based on the debate in the forum. Although CAs will stop
issuing SHA-1 on 2016/1/1, there isn't any reason these changes couldn't go
into effect in early January (assuming a passing vote).

 

If adopted, this ballot would permit continued use of SHA1 certificates past
the deprecation deadline (to support older devices) but give newer browsers
an easy way to reject SHA1 for users.  The ballot also increases the
resiliency of SHA1 certs against attacks by requiring higher entropy serial
numbers.

 

I look forward to your comments.

 

Thanks,

Jeremy

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151221/98f14f61/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4289 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151221/98f14f61/attachment-0001.bin 


More information about the Public mailing list