[cabfpub] LV Certificates

Richard Wang richard at wosign.com
Mon Dec 21 06:39:37 MST 2015


+1

Put the world internet in danger just because they are big Internet company?


Regards,

Richard

> On Dec 21, 2015, at 21:30, Doug Beattie <doug.beattie at globalsign.com> wrote:
> 
> 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
>  
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151221/43a0e418/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7208 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151221/43a0e418/attachment-0001.bin 


More information about the Public mailing list