[cabfpub] Definition of an SSL certificate

i-barreira at izenpe.net i-barreira at izenpe.net
Thu Jan 9 12:43:10 UTC 2014


Rick,

 

Actually ETSI has 2 different standards for this, the TS 101 456 is for auditing CAs that issue QCs, and the ETSI TS 102 042 is for CAs that issue public key certificates.

These, as said some times, will be changed and will be different ENs that will have effect soon.

 

 

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

945067705

 

 

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 Rick Andrews
Enviado el: viernes, 03 de enero de 2014 19:09
Para: Mads Egil Henriksveen; Moudrick M. Dadashov; Jeremy Rowley; public at cabforum.org
Asunto: Re: [cabfpub] Definition of an SSL certificate

 

Mads, Moudrick,

 

Are CAs that issue QCs audited by some ETSI audit equivalent to BRs, in which the auditors check that the CA verified any domain names that appear in QCs?

 

Also, to respond to Mads' earlier question about the id-kp-clientAuth EKU bit: Symantec generally sets both clientAuth and serverAuth EKU bits, because we have many customers who use the certificate for server-to-server communication. Each endpoint has an SSL cert, and one acts as the client while one acts as the server, and they use their certs to authenticate each other.

 

-Rick

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Mads Egil Henriksveen
Sent: Friday, January 03, 2014 3:52 AM
To: Moudrick M. Dadashov; Jeremy Rowley; public at cabforum.org
Subject: Re: [cabfpub] Definition of an SSL certificate

 

Hi Moudrick

 

There might not be a real use case for including a domain name in a QC, but as a trusted CA we take the responsibility for the accuracy of information in all certs we issue. And that was my point and why I am not very concerned about the described attack scenario.  

 

Regards

Mads

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Moudrick M. Dadashov
Sent: 3. januar 2014 11:51
To: Mads Egil Henriksveen; Jeremy Rowley; public at cabforum.org
Subject: Re: [cabfpub] Definition of an SSL certificate

 

Mads,

On 1/3/2014 11:49 AM, Mads Egil Henriksveen wrote:

	 

	The attack scenario assumes that the QC can be chained to a root cert in a trusted CA root store. This means that the CA should know the root store requirements and should be aware of the risk issuing any cert that could be used as an SSL certificate. 

	 

	Buypass do issue both QC and SSL certificates and with the DigiNotar attack back in 2011 we realized that the browsers do accept a lot of certificates as SSL certificates. Since then we have had strict controls to ensure that no certificate is issued with an unverified domain name. I guess most of the trusted QC issuers who also issue SSL certificates are aware of this, I would not be very concerned about this attack scenario. 

What is the use case when in a QC we'd need a [any/unverified] domain name? (aren't CAs responsible for the accuracy of information in the QCs they issue?). 

 

However, I do support the idea of a technical definition of an SSL certificate and I like the proposal from Ryan Hurst requiring the BR/EV OIDs. 

Under ETSI framework compliance assumes two things: compliance with the corresponding requirements plus certificate profile compliance. These two categories exist as separate documents (under their own ETSI IDs).
Ryan's proposal is definitely a  good step forward, I'd vote with my both hands if we go even further, and like ETSI, have separate BR/EV profile specifications.

Thanks,
M.D.

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


More information about the Public mailing list