[cabfpub] EV Code Signing fixes

Jeremy Rowley jeremy.rowley at digicert.com
Sat Mar 1 01:12:25 UTC 2014


Thanks Inigo.  Is there a second endorser?

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of i-barreira at izenpe.net
Sent: Wednesday, February 19, 2014 10:05 AM
To: jeremy.rowley at digicert.com; public at cabforum.org
Subject: Re: [cabfpub] EV Code Signing fixes

 

I will endorse it

 

 

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

 

Descripción: cid:image001.png at 01CE3152.B4804EB0

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea.
Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki
idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna.
KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la
que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
error le agradeceriamos que no hiciera uso de la informacion y que se
pusiese en contacto con el remitente.

 

De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En
nombre de Jeremy Rowley
Enviado el: miércoles, 19 de febrero de 2014 8:53
Para: CABFPub
Asunto: [cabfpub] EV Code Signing fixes

 

There are two issues with the EV code signing guidelines that need
correction:

 

1.  Section 9.2.2 of the EV code signing guidelines recommends that CAs not
include the SAN extension in an EV certificate.  However, section 9.7
requires that an EV certificate include subjectAltName:permanentIdentifier.
Because the main concern is a CA including a domain names in the SAN
extension, we should specify that this practice is not allowed and recognize
that other information may be present. 

 

2.  Section 9.2.3 of the EV code signing guidelines deprecates the CN field.
The code signing working group received a report that this field is still
required by code signing applications. We should still include the CN in
code signing certificates even if the field is deprecated for SSL
certificates.  

 

I am looking for endorsers for (or suggestions on) the following proposal:

 

a.       Replace section 9.2.2 with the following: 

“9.2.2    Subject Alternative Name Extension

This field MUST be present and MUST contain the permanentIdentifier
specified in Section 9.7. This field MUST NOT contain a Domain Name or IP
Address.”

 

b.      Amend section 9.2.3 as follows:

“9.2.2    Subject Common Name Field

Certificate field: subject:commonName (OID 2.5.4.3)

Required/Optional: Required

Contents: This field MUST contain the Subject’s legal name as verified under
Section 11.2. “

 

Thanks!

Jeremy

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140228/a44171d5/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140228/a44171d5/attachment-0002.png>


More information about the Public mailing list