[cabfpub] Definition of an SSL certificate

Fri Jan 3 19:32:55 UTC 2014

Sorry - I got the discussion a bit off-track. The issue is not whether
domain names are vetted, but the fact that the BRs do not clearly define
what certs are covered.  There is a significant gray area on when
certificates are exempt from the BRs.

If requiring the BR/EV OID is not a possibility, I'd define the scope as any
certificate that either (i) specifies a domain name in the CN field or
subjectAltName extension and includes the anyEKU or serverAuth or omits an
EKU or (ii) is intended to enable SSL/TLS, as evidenced by inclusion of the
serverAuth EKU.  

Although the definition needs word smithing, it captures the certificates of
primary concern (those containing domain names) without excluding internal
server name certs. Thoughts?

Jeremy

From: Brown, Wendy (10421) [mailto:wendy.brown at protiviti.com] 
Sent: Friday, January 03, 2014 12:08 PM
To: Jeremy Rowley; 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';
public at cabforum.org
Subject: RE: [cabfpub] Definition of an SSL certificate

The requirement to verify is in the CP - the details of How goes in the CPS.

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com] 
Sent: Friday, January 03, 2014 2:03 PM
To: Brown, Wendy (10421); 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';
public at cabforum.org
Subject: RE: [cabfpub] Definition of an SSL certificate

Thanks Wendy for the clarification.  However, I didn't see anything
specifying how the CA is supposed to verify the domain.  

From: Brown, Wendy (10421) [mailto:wendy.brown at protiviti.com] 
Sent: Friday, January 03, 2014 11:55 AM
To: Jeremy Rowley; 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';
public at cabforum.org
Subject: RE: [cabfpub] Definition of an SSL certificate

The FBCA and Common Policy CPs actually require all information included in
a certificate to be verified - so that would include any domain names, see
3.2.4.

Thanks,

Wendy

Wendy Brown

FPKIMA Technical Liaison

Protiviti Government Services

703-299-4705 (office)    703-965-2990 (cell)

wendy.brown at fpki.gov

wendy.brown at protiviti.com

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

Many of the trusted QC issuers (and other community issuers) are not
involved in the CAB Forum.  Although you are aware of the requirements, I
don't think this knowledge is global.  For example, I don't think the NIST
CP or FBCA CP ever mentions domain validation. A CA following either CP for
client certs wouldn't necessarily validate an included domain.

Jeremy

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Mads Egil Henriksveen
Sent: Friday, January 03, 2014 4: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.

NOTICE: Protiviti is a global consulting and internal audit firm composed of
experts specializing in risk and advisory services. Protiviti is not
licensed or registered as a public accounting firm and does not issue
opinions on financial statements or offer attestation services. 

This electronic mail message is intended exclusively for the individual or
entity to which it is addressed. This message, together with any attachment,
may contain confidential and privileged information. Any views, opinions or
conclusions expressed in this message are those of the individual sender and
do not necessarily reflect the views of Protiviti Inc. or its affiliates.
Any unauthorized review, use, printing, copying, retention, disclosure or
distribution is strictly prohibited. If you have received this message in
error, please immediately advise the sender by reply email message to the
sender and delete all copies of this message. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140103/90232299/attachment-0003.html>