[cabfpub] Definition of an SSL certificate

Stephen Davidson S.Davidson at quovadisglobal.com
Thu Dec 19 16:52:57 UTC 2013

>  Are qualified certs issued from the same root as BR certs?






From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Thursday, December 19, 2013 12:51 PM
To: i-barreira at izenpe.net; public at cabforum.org
Subject: Re: [cabfpub] Definition of an SSL certificate



1)      Qualified certs CAN be used for TLS Server Authentication since they
may include anyEKU or serverAuth in the EKU extension

2)      Qualified Certs do NOT comply with the BRs, they comply with the
appropriate ESTI standard.  

3)      Qualified certs are only distinguishable from BR certs because
qualified certs assert a QCStatement


Is this a fair summary? 


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of i-barreira at izenpe.net
Sent: Thursday, December 19, 2013 9:25 AM
To: jeremy.rowley at digicert.com; public at cabforum.org
Subject: Re: [cabfpub] Definition of an SSL certificate


Yes, but with some additional points


-          Mark Jansen is right albeit it depends on national legislation.
In Spain, you have to indicate what EKU is to be used.

-          DV or OV will never be considered Qualified certs. EV possibly
and will have some impacts



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



Descripción: Descripción: Descripción: firma_izenpe_navid-OK-2


De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En
nombre de Jeremy Rowley
Enviado el: jueves, 19 de diciembre de 2013 17:06
Para: CABFPub
Asunto: [cabfpub] Definition of an SSL certificate


We are looking to clarify the scope of the BRs.  Right now the BR scope is
very loose and subjective: “This version of the Requirements only addresses
Certificates intended to be used for authenticating servers  accessible
through the Internet.”


This loose definition excludes internal names (which are not typically
accessible through the Internet), a type of certificate the BRs are clearly
designed to regulate (see 11.1.4).  In addition, a CA could easily issue a
certificate outside of the BRs  that could later be used in a TLS/SSL attack
simply because the certificate wasn’t intended to be used for SSL.  


Issuance of certificates outside the BRs may not be intentional, especially
by CAs who aren’t regularly issuing SSL certificates.  These CAs may not be
aware that the BRs apply to their certificates and may not realize their
client certificates could be used for SSL since “authenticating servers” is
not a well-defined term.  


Clarifying the scope will ensure that every CA is aware of the minimum
standards and what they cover.  Originally, the idea was to tie the scope to
the values in the EKU.  Unfortunately, there are several obstacles to this

1)      Grid Certificates require serverAuth in the EKU.  It’s unclear
whether these certs should be covered.

2)      Per 5280, browsers treat the absence of an EKU and the anyEKU as
serverAuth, meaning they are enabled for TLS Server Authentication.

3)      The FBCA requires anyEKU in several certificates.  These are clearly
client certificates and are outside the BR scope.

4)      Qualified certificates in the EU have either the anyEKU present or
omit the EKU.  They are client certs and clearly not covered by the BRs.
However, they can be used  for server authentication.


For qualified certificates, Moudrick provided the following guidance:

“Certificates using applications MAY require that the extended key usage
extension be present and that a particular purpose be indicated in order for
the certificate to be acceptable to that application.


If a CA includes extended key usages to satisfy such applications, but does
not wish to restrict usages of the key, the CA can include the special
KeyPurposeId anyExtendedKeyUsage ***in addition to the particular key
purposes required by the applications***.


So a QC pretending to be RFC 5280/BR and ETSI (web server QCs) compliant
would have to at least have:


QC + [anyEKU] + id-kp-serverAuth + {DV/OV/EV}


I'm quite confident that the absolute majority of QCs issued so far (that
have anyEKU, see Mark Janssen's 08/08/2013 - thank you Stephen) do not
contain any DV/OV/EV policy IDs, so why not accept them as BR compliant but
not sufficient for TSL/SSL establishment?


In order for a QC to have a TSL/SSL capability, BR may require:


QC + {{id-kp-serverAuth and/or id-kp-clientAuth} + {DV/OV/EV}} (optionally
no anyKEY allowed).


A practical interpretation: a WEB server that also does some web site
related document/content signing.”


There appears to be a significant conflict between the CAB Forum’s work and
the standards set by other bodies.  In particular, their use of the anyEKU
or omission of an EKU is permitting the realm of client certs to overlap SSL
certs.  Approaching each government body to stop this practice is not
feasible and will take a very long time to complete


Hopefully this summary helps inspire ideas on where we can go from here.
I’m looking forward to ideas. 







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131219/d7dc6f75/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9129 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131219/d7dc6f75/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5494 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131219/d7dc6f75/attachment-0001.p7s>

More information about the Public mailing list