<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Century Gothic";
panose-1:2 11 5 2 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=NO-BOK link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The alternative of expanding the definition is also acceptable, but I do not understand why noEKU should be included in the definition of an SSL certificate (I might have missed this in an earlier thread). According to RFC 5280 the TLS WWW server authentication key usage could be defined either with the id-kp-serverAuth bit set in EKU or with the anyEKU option. I do not see why noEKU should be included. Could anyone clarify?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>When reading the BR it appears to be an inconsistency between the BR scope and the requirements for Certificate extensions:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In section 1 of BR (Scope) the current text is:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-US style='font-size:10.0pt'>This version of the Requirements only addresses Certificates intended to be used for <u>authenticating servers</u> accessible through the Internet.</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>And in Appendix B (3) Subscriber certificate, the requirement is:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><b><span style='font-size:10.0pt'>F. extKeyUsage (required)</span></b><b><span lang=EN-US style='font-size:10.0pt'><o:p></o:p></span></b></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-US style='font-size:10.0pt'>Either the value id-kp-serverAuth [RFC5280] <u>or id-kp-clientAuth</u> [RFC5280] or both values MUST be<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:10.0pt'>present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present.</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I don’t think that the id-kp-clientAuth EKU bit should be used for authenticating servers (?).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jeremy has partly addressed this already in his proposed Ballot 108, but I think we also should revisit the EKU requirement in this context. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mads<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Jeremy Rowley<br><b>Sent:</b> 2. januar 2014 18:41<br><b>To:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Definition of an SSL certificate<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We are trying to NOT cover QCs in the BR scope. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Currently, most QCs include the anyEKU, meaning the QC can be used for SSL. An attacker can an QC certificate with a domain name from a trusted QC issuer. Since many QC issuers do not provide SSL certificates on a regular basis, they will not realize the certificate must comply with the BRs and fail to properly vet the domain name included in the certificate. After the certificate issues, the attacker can freely use the certificate to MITM everyone on the included domain. This is a real scenario since many of these standards do not require the CA to verify any domain name included in the certificate.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In this example, the CA did nothing wrong from a standard’s perspective. However, this is little comfort to the affected users. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>One proposal (by Ryan Hurst) is to only require compliance if the certs assert the BR/EV CAB Forum OIDs. The browsers can then require the BR/EV OID before trusting the certificate.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>An alternative is to expand the definition and include a statement that says any certificate that includes a domain name and the anyEKU, noEKU, or serverAuth is considered intended for use in SSL.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jeremy<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:me@chemalogo.com">me@chemalogo.com</a> [<a href="mailto:me@chemalogo.com">mailto:me@chemalogo.com</a>] <b>On Behalf Of </b>Chema López González<br><b>Sent:</b> Thursday, January 02, 2014 10:26 AM<br><b>To:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br><b>Cc:</b> Jeremy Rowley; <a href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a>; Stephen Davidson<br><b>Subject:</b> Re: [cabfpub] Definition of an SSL certificate<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>Dear all,<o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Qualified certificates are intended to identify people, not websites nor servers. There are no hard constrains regarding the usage of EKU KU values, but good practices are to use Non-repudiation and only non-repudiation (see <a href="http://www.ietf.org/rfc/rfc3039.txt">RFC3039</a>, section 3.2.3 in combination with <a href="http://www.etsi.org/deliver/etsi_ts/102200_102299/102280/01.01.01_60/ts_102280v010101p.pdf">ETSI TS 102 280</a>, section 5.4.3 and taking into account that Qualified Certificates are defined with purpose of creation Qualified Electronic Signatures legally binding!)<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>In fact any QC contents personal data (or pseudonym but the CSP MUST have the actual personal data bound to the pseudonym) so I do not think any will want to put her personal data authenticating a public website.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Since the purpose of a QC is quite different of the purpose of a SSL certificate and the first is legally constricted I do really think that BR's do not have to cover QC at all. Maybe it exists but I have never seen a QC authenticating a website.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>IMHO trying to cover QC is going beyond the purpose of the BR, it will mesh up the whole think without adding security to SSL certificates.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div></div><div><p class=MsoNormal><span lang=EN-US><br clear=all><o:p></o:p></span></p><div><div><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><a href="http://www.firmaprofesional.com/" target="_blank"><span style='color:#1155CC;text-decoration:none'><img border=0 id="_x0000_i1025" src="http://www.firmaprofesional.com/images/fp_firmas.png" alt="AC Firmaprofesional S.A."></span></a><o:p></o:p></p></td><td style='padding:.75pt .75pt .75pt .75pt'><p><b><span style='font-family:"Arial","sans-serif";color:#999999'>Chema López González<br> <br>AC Firmaprofesional S.A.</span></b><span style='color:#999999'><o:p></o:p></span></p></td></tr><tr><td style='padding:.75pt .75pt .75pt .75pt'></td><td style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><br><span style='font-family:"Arial","sans-serif";color:#999999'>Av. Torre Blanca, 57.</span> <br><span style='font-family:"Arial","sans-serif";color:#999999'>Edificio ESADECREAPOLIS - 1B13</span><o:p></o:p></p><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#999999'>08173 Sant Cugat del Vallès. Barcelona.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:#999999'>Tel: </span>93.477.42.45<span style='color:#999999'> /</span><span style='color:#3333FF'> 666.429.224</span><o:p></o:p></p></div></td></tr></table><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, le hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si ha recibido este mensaje por error, le agradeceríamos que lo haga saber inmediatamente al remitente y que proceda a destruir el mensaje.<o:p></o:p></span></p></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>On Thu, Dec 19, 2013 at 5:52 PM, Stephen Davidson <<a href="mailto:S.Davidson@quovadisglobal.com" target="_blank">S.Davidson@quovadisglobal.com</a>> wrote:<o:p></o:p></span></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'>> Are qualified certs issued from the same root as BR certs?</span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'>Yes.</span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Jeremy Rowley<br><b>Sent:</b> Thursday, December 19, 2013 12:51 PM<br><b>To:</b> <a href="mailto:i-barreira@izenpe.net" target="_blank">i-barreira@izenpe.net</a>; <a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a></span><span lang=EN-US><o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US><br><b>Subject:</b> Re: [cabfpub] Definition of an SSL certificate<o:p></o:p></span></p></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'>So:</span><span lang=EN-US><o:p></o:p></span></p><div><p><span lang=EN-US style='color:#1F497D'>1)</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> </span><span lang=EN-US style='color:#1F497D'>Qualified certs CAN be used for TLS Server Authentication since they may include anyEKU or serverAuth in the EKU extension</span><span lang=EN-US><o:p></o:p></span></p><p><span lang=EN-US style='color:#1F497D'>2)</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> </span><span lang=EN-US style='color:#1F497D'>Qualified Certs do NOT comply with the BRs, they comply with the appropriate ESTI standard. </span><span lang=EN-US><o:p></o:p></span></p><p><span lang=EN-US style='color:#1F497D'>3)</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> </span><span lang=EN-US style='color:#1F497D'>Qualified certs are only distinguishable from BR certs because qualified certs assert a QCStatement</span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'>Is this a fair summary? </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p></div><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org" target="_blank">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b><a href="mailto:i-barreira@izenpe.net" target="_blank">i-barreira@izenpe.net</a></span><span lang=EN-US><o:p></o:p></span></p><div><div><p class=MsoNormal><span lang=EN-US><br><b>Sent:</b> Thursday, December 19, 2013 9:25 AM<br><b>To:</b> <a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>; <a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a><br><b>Subject:</b> Re: [cabfpub] Definition of an SSL certificate<o:p></o:p></span></p></div></div></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'>Yes, but with some additional points</span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><p><span lang=EN-US style='color:#1F497D'>-</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> </span><span lang=EN-US style='color:#1F497D'>Mark Jansen is right albeit it depends on national legislation. In Spain, you have to indicate what EKU is to be used.</span><span lang=EN-US><o:p></o:p></span></p><p><span lang=EN-US style='color:#1F497D'>-</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> </span><span lang=EN-US style='color:#1F497D'>DV or OV will never be considered Qualified certs. EV possibly and will have some impacts</span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:9.75pt'><b><span lang=EN-US style='font-size:8.5pt;font-family:"Tahoma","sans-serif"'> </span></b><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;line-height:9.75pt'><b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif"'>Iñigo Barreira</span></b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif"'><br>Responsable del Área técnica<br><a href="mailto:i-barreira@izenpe.net" target="_blank">i-barreira@izenpe.net</a></span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif"'>945067705</span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=ES style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=ES style='font-size:9.0pt;font-family:"Century Gothic","sans-serif";color:#244061'><img border=0 width=591 height=88 id="_x0000_i1026" src="cid:image001.jpg@01CF0856.2EF1EC50" alt="Descripción: Descripción: Descripción: firma_izenpe_navid-OK-2"></span></b><span lang=EN-US><o:p></o:p></span></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=ES style='color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=ES style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>De:</span></b><span lang=ES style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org" target="_blank">mailto:public-bounces@cabforum.org</a>] <b>En nombre de </b>Jeremy Rowley<br><b>Enviado el:</b> jueves, 19 de diciembre de 2013 17:06<br><b>Para:</b> CABFPub<br><b>Asunto:</b> [cabfpub] Definition of an SSL certificate</span><span lang=EN-US><o:p></o:p></span></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=ES> </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.”<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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 approach:<o:p></o:p></span></p><p><span lang=EN-US>1)</span><span lang=EN-US style='font-size:7.0pt'> </span><span lang=EN-US>Grid Certificates require serverAuth in the EKU. It’s unclear whether these certs should be covered.<o:p></o:p></span></p><p><span lang=EN-US>2)</span><span lang=EN-US style='font-size:7.0pt'> </span><span lang=EN-US>Per 5280, browsers treat the absence of an EKU and the anyEKU as serverAuth, meaning they are enabled for TLS Server Authentication.<o:p></o:p></span></p><p><span lang=EN-US>3)</span><span lang=EN-US style='font-size:7.0pt'> </span><span lang=EN-US>The FBCA requires anyEKU in several certificates. These are clearly client certificates and are outside the BR scope.<o:p></o:p></span></p><p><span lang=EN-US>4)</span><span lang=EN-US style='font-size:7.0pt'> </span><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>For qualified certificates, Moudrick provided the following guidance:<o:p></o:p></span></p><p><span lang=EN-US>“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.<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>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***.<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>So a QC pretending to be RFC 5280/BR and ETSI (web server QCs) compliant would have to at least have:<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>QC + [anyEKU] + id-kp-serverAuth + {DV/OV/EV}<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>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?<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>In order for a QC to have a TSL/SSL capability, BR may require:<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>QC + {{id-kp-serverAuth and/or id-kp-clientAuth} + {DV/OV/EV}} (optionally no anyKEY allowed).<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>A practical interpretation: a WEB server that also does some web site related document/content signing.”<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>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<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>Hopefully this summary helps inspire ideas on where we can go from here. I’m looking forward to ideas. <o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>Thanks!<o:p></o:p></span></p><p><span lang=EN-US> <o:p></o:p></span></p><p><span lang=EN-US>Jeremy<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US><br>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div></div></body></html>