[cabfpub] EV Code Signing maximum validity

Dean Coclin Dean_Coclin at symantec.com
Fri Apr 12 08:37:55 MST 2013


CA Issued certs are allowed as long as they are not public CA certs that are also embedded in browsers.


Dean

 

From: Brown, Wendy (10421) [mailto:wendy.brown at pgs.protiviti.com] 
Sent: Friday, April 12, 2013 11:37 AM
To: Dean Coclin; Rick Andrews
Cc: ben at digicert.com; richard.smith at comodo.com; public at cabforum.org
Subject: RE: [cabfpub] EV Code Signing maximum validity

 

I understand that android allows self-signed certs, but are CA issued certs not allowed?  Is it totally out of scope of this group to try to influence a potential platform to be willing to accept EV code-signing certificates?

 

From: Dean Coclin [mailto:Dean_Coclin at symantec.com] 
Sent: Friday, April 12, 2013 10:29 AM
To: Rick Andrews
Cc: Brown, Wendy (10421); ben at digicert.com; richard.smith at comodo.com; public at cabforum.org
Subject: Re: [cabfpub] EV Code Signing maximum validity

 

You are referring to android Reqts which can be self signed. They do not require a public root and hence these rules don't apply

 

Dean

Sent from my iPhone


On Apr 12, 2013, at 10:16 AM, "Rick Andrews" <Rick_Andrews at symantec.com> wrote:

I’m not familiar with the Google Play requirement, but that seems odd. If the code signature includes a signed timestamp, the code remains valid even after the code signing certificate expires.

 

-Rick

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Brown, Wendy (10421)
Sent: Friday, April 12, 2013 6:57 AM
To: ben at digicert.com; richard.smith at comodo.com; public at cabforum.org
Subject: Re: [cabfpub] EV Code Signing maximum validity

 

I would love to hear from some of the vendors that will be validating code-signing certificates on this issue – because I believe a requirement to get into the Google Play Store is code signed with an even longer certificate – they recommend 25 years or at least past October 2033.

 

I agree that code-signing and SSL are sufficiently different that they do not require the same maximums, but something more reasonable than 25 years.

 

   wendy

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, April 12, 2013 9:08 AM
To: richard.smith at comodo.com; public at cabforum.org
Subject: Re: [cabfpub] EV Code Signing maximum validity

 

Thanks.  I’ll allow others to chime in, but my hope in not bringing your point up previously was that with added scrutiny and the hardware requirement of EV code signing there would be adequate balance when compared with non-EV code-signing industry practices, which allow 10-year certificates.  If there are going to be baselines for code signing that cut validity periods down from 10 years, then maybe you have a point.

 

From: Rich Smith [mailto:richard.smith at comodo.com] 
Sent: Friday, April 12, 2013 6:59 AM
To: ben at digicert.com; public at cabforum.org
Subject: RE: [cabfpub] EV Code Signing maximum validity

 

Ben,

We could leave it alone, but IMO there are several compelling reasons not to, and really no good reason that we should.  

 

A code signing cert is a higher risk product than an SSL cert, especially one labeled as EV.  At least the EV SSL is tied to a specific FQDN.  An EV Code Signing cert can sign code that shows up anywhere, is very portable and can be stolen and put to fraudulent use much more easily.  As such if only one is going to be allowed a 39 month validity, I would be MUCH more inclined to allow that for an EV SSL than an EV Code Signing cert.    IMO the decision to allow longer validity for EV Code Signing just doesn't add up unless the decision is that a 39 month limit is deemed good enough across the board.

 

If 39 months was not really discussed and a conscious decision made that it was enough, then this would appear to be an arbitrary decision, that just didn't get picked up until now, and to my mind that's an even better reason to fix it.

 

I also think that since both are labeled as EV the standards between them SHOULD be consistent where ever possible and unless there is a VERY compelling reason for them to be, so as to maintain clarity of purpose to Forum members, non-member CAs and to the public at large.

 

-Rich

 

From: Ben Wilson [mailto:ben at digicert.com] 
Sent: Friday, April 12, 2013 8:41 AM
To: richard.smith at comodo.com; public at cabforum.org
Subject: RE: [cabfpub] EV Code Signing maximum validity

 

Or we could leave them “as is”, since code signing and SSL are certificates used for different purposes.

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith
Sent: Friday, April 12, 2013 6:22 AM
To: public at cabforum.org
Subject: [cabfpub] EV Code Signing maximum validity

 

In preparing to begin issuing EV Code Signing certificates, we noticed that the maximum validity for EV Code Signing is 39 months as per the BRs, not 27 months as per the EV Guidelines.

 

My guess is that this is due to the fact that the EV Guidelines maximum validity was set before there were any other rules in place limiting the validity of certificates, but that since the EV Code Signing guidelines were put in place after the BRs had set max validity to 39 months that it was determined that the BR limit was enough.

 

If that is indeed the case, and in the interest of consistency, how would the members feel about lifting the 27 month restriction on EV SSL certificates and settling on 39 month restriction across the board.  If it is determined that moving to a 39 month restriction for EV SSL is not acceptable, then IMO EV Code Signing should also be restricted to 27 months.

 

-- 

Regards,

Rich Smith

Validation Manager

Comodo

 <http://www.comodo.com/> http://www.comodo.com

 

 

_______________________________________________
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/20130412/1020ff2c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6083 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130412/1020ff2c/attachment-0001.bin 


More information about the Public mailing list