[cabfpub] EV Code Signing maximum validity

i-barreira at izenpe.net i-barreira at izenpe.net
Tue Apr 16 07:56:33 UTC 2013


Jeremy,

Yes, in section 16 there´s a mention of these requirements, but ...

FIPS is commonly used for certifying HSMs and "the equivalent" should be the Common Criteria, which is more often used for certifying smartcards. One key thing in this certification is the definition of the "in-famous" Protection Profile, which drive us into hard debates. One other is what is consider a SSCD (Secure Signing Creation Device) to have a qualified signature. If the EV code signing aims to be a "qualified" certificate in a SSCD to perform "qualified" signatures, then a HSM cannot be valid for this purpose in some countries.
Right now, and we have a good debate in the last ESI workshop on "signing in the cloud" because of the concept whether an HSM is a SSCD, I know only one country, Italy, which they consider some HSMs and depending on what certification has passed a SSCD, because they have an specific body which defines additional requirements on the Common Criteria certification.

FYI, in that public tender my requirements were:
 Common Criteria EAL4 + at least plus accomplish of the Spanish law on electronic signature plus the requirements indicated in the ETSI TS 101 456 and also the ones expressed in the "old" CEN CWA 14169 (this is replacing by new ETSI TS and will become an EN)

So, for EV code signing I´d like to be issued in smartcards rather than HSMs for example.

And regarding code signing, none has answered my last email regarding the differences between 9.7 (B) and 9.2.2. Any thoughts?

One last question, is it possible to be incorporated to the code signing WG?

Regards

-----Mensaje original-----
De: Jeremy Rowley [mailto:jeremy.rowley at digicert.com] 
Enviado el: lunes, 15 de abril de 2013 17:52
Para: Barreira Iglesias, Iñigo; rob.stradling at comodo.com; public at cabforum.org
Asunto: RE: [cabfpub] EV Code Signing maximum validity

There are minimum requirements for the hardware token.  Section 16 specifies that hardware tokens must be FIPS 140-2 Level 2 or the equivalent. 

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of i-barreira at izenpe.net
Sent: Monday, April 15, 2013 3:27 PM
To: rob.stradling at comodo.com; public at cabforum.org
Subject: Re: [cabfpub] EV Code Signing maximum validity

I don´t mind 27 or 39 moths (even in the "guidelines for the issuance and management of extended validation code signing certificates" version 1.1 says in section 9.4 "validity period not exceeding 39 months") but these certs have to be issued in hardware tokens (smartcards or USB tokens) and these hardware tokens should have a minimum requirements. In the EU, most of the CAs that issue certs are familiar with these hardware tokens and impose some requirements to be provided. Recently I launched a public tender with some requirements for smartcards and USB tokens (if someone wants to have nightmares I can provide it) and one of the requisites is that the private key can´t be exported anyhow (this is not new, it´s commonly used) and all the "signing" process is done in the smartcard.

-----Mensaje original-----
De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Rob Stradling Enviado el: viernes, 12 de abril de 2013 21:24
Para: public at cabforum.org
Asunto: Re: [cabfpub] EV Code Signing maximum validity

On 12/04/13 18:56, Eddy Nigg (StartCom Ltd.) wrote:
>
> On 04/12/2013 03:22 PM, From Rich Smith:
>> 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.
>
> I believe it should be 27 month the most - but perhaps remove the 
> hardware token requirement for those certificates which hinders 
> currently adoption for such certificates.

Jeremy wrote "The risk with long-term EV Code Signing certs is primarily a loss of the private key, which is why we required a hardware token."

I have to agree that "loss of the private key" is a significant problem. 
  For example, an article published yesterday [1] claims that:
   "At least 35 gaming developers involved in the MMORPG field (Massive Multi-Player Online Role Playing Games) have been hacked in the last year-and-a-half by the so-called Winnti group, with one of the primary goals being to steal their digital certificates to use in other attacks".

If the private keys of these gaming companies had been held in hardware tokens, the attackers presumably would've been unable to steal the keys by hacking the systems remotely.  Instead, they would've had the harder job of somehow stealing the actual hardware tokens.


[1] http://www.wired.com/threatlevel/2013/04/gaming-company-certs-stolen/

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public




More information about the Public mailing list