<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 14 (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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I don’t think anyone disagrees that server certs <i>should</i> have the serverAuth EKU. However, this discussion is primarily about how to address the anyEKU and omission of EKU issue. Both types are treated like serverAuth certs by browsers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Chema López González<br><b>Sent:</b> Wednesday, January 08, 2014 5:15 AM<br><b>To:</b> Rob Stradling<br><b>Cc:</b> Mads Egil Henriksveen; public@cabforum.org; Brown, Wendy (10421)<br><b>Subject:</b> Re: [cabfpub] Definition of an SSL certificate<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><br>First things first:<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>But BR also accepts that only the clientAuth EKU bit is set, and this sounds strange to me when the BR scope is ‘<i>authenticating servers’</i>.</span><o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>+1<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?</span><o:p></o:p></p></blockquote><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p></div><div><p class=MsoNormal>I have to disagree with Moudrick but this is not consistent across European Countries and this is not mandatory at all.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>On the other hand, the <a href="http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML">European Directive on Electronic Signature</a> states (ANNEX II) that:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-left:30.0pt;margin-right:0in'><div><p class=MsoNormal><i><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>(d) verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued;</span></i><o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>but the <a href="https://www.boe.es/buscar/act.php?id=BOE-A-2003-23399">Spanish law on electronic signature</a> (ES) is a little bit more restrictive, and states (Art. 12):<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-left:30.0pt;margin-right:0in'><div><p class=MsoNormal>"<i>b) Verify that the information contained in the certificate is accurate and contains all the details prescribed for a qualified certificate.</i>"<o:p></o:p></p></div></blockquote><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>So we can not expect that a Certification Services Provider that issues QC (Qualified Trust Services Provider) is audited by some ETSI. Nevertheless, at the end, the majority of CSP is audited either WebTrust for CA or ETSI TS 101456/102042/102023.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Said that, I can not imagine a certificate authenticating a server without the serverAuth EKU.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></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><o:p> </o:p></p><div><p class=MsoNormal>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></p></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jan 6, 2014 at 11:05 AM, Rob Stradling <<a href="mailto:rob.stradling@comodo.com" target="_blank">rob.stradling@comodo.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>On 06/01/14 09:54, Moudrick M. Dadashov wrote:<br>> On 1/3/2014 11:58 PM, Rob Stradling wrote:<br>>> On 03/01/14 21:09, Moudrick M. Dadashov wrote:<o:p></o:p></p></div><p class=MsoNormal><snip><o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>>>> Jeremy, to my understanding RFC 5280 accepts anyEKU only in combination<br>>>> with any other EKU but not as the only EKU:<br>>>><br>>>> “Certificates using applications MAY require that the extended key usage<br>>>> extension be present and that a particular purpose be indicated in order<br>>>> for the certificate to be acceptable to that application.<br>>><br>>> But RFC5280 also says:<br>>> "Applications that require the presence of a<br>>> particular purpose MAY reject certificates that include the<br>>> anyExtendedKeyUsage OID but not the particular OID expected for the<br>>> application.<br>>><br>>> That's MAY, not MUST.<br>><br>> Rob, that's right, but isn't about application behavior only?<o:p></o:p></p></div><p class=MsoNormal>Yes, that's correct.<o:p></o:p></p><div><p class=MsoNormal><br>> The reference below explains when/why CA may need anyEKU and it says "CA<br>> can include...".<br>> I may have missed something though..<o:p></o:p></p></div><p class=MsoNormal><snip><o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>>>> If a CA includes extended key usages to satisfy such applications, but<br>>>> does not wish to restrict usages of the key, the CA can include the<br>>>> special KeyPurposeId anyExtendedKeyUsage ***in addition to the<br>>>> particular key purposes required by the applications***.<o:p></o:p></p></div><p class=MsoNormal>I don't read that "If" as an "Iff" (If and only if). In other words, I<br>don't think this statement limits when anyEKU can be used. It simply<br>points out one scenario where it might be useful to use anyEKU.<o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>>>> So based on this:<br>>>> SSL server: = SAN + serverAuth + [anyEKU+EKU]<br>>>> SSL client:= [SAN] +clientAuth + [anyEKU+EKU]<br>>>><br>>>> Thanks,<br>>>> M.D.<br>>>><br>>>>> Although the definition needs word smithing, it captures the<br>>>>> certificates of primary concern (those containing domain names)<br>>>>> without excluding internal server name certs. Thoughts?<br>>>>><br>>>>> Jeremy<br>>>>><br>>>>> *From:*Brown, Wendy (10421) [mailto:<a href="mailto:wendy.brown@protiviti.com">wendy.brown@protiviti.com</a>]<br>>>>> *Sent:* Friday, January 03, 2014 12:08 PM<br>>>>> *To:* Jeremy Rowley; 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';<br>>>>> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>>>>> *Subject:* RE: [cabfpub] Definition of an SSL certificate<br>>>>><br>>>>> The requirement to verify is in the CP – the details of How goes in<br>>>>> the CPS.<br>>>>><br>>>>> *From:*Jeremy Rowley [mailto:<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>]<br>>>>> *Sent:* Friday, January 03, 2014 2:03 PM<br>>>>> *To:* Brown, Wendy (10421); 'Mads Egil Henriksveen'; 'Moudrick M.<br>>>>> Dadashov'; <a href="mailto:public@cabforum.org">public@cabforum.org</a> <mailto:<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>>>>> *Subject:* RE: [cabfpub] Definition of an SSL certificate<br>>>>><br>>>>> Thanks Wendy for the clarification. However, I didn’t see anything<br>>>>> specifying how the CA is supposed to verify the domain.<br>>>>><br>>>>> *From:*Brown, Wendy (10421) [mailto:<a href="mailto:wendy.brown@protiviti.com">wendy.brown@protiviti.com</a>]<br>>>>> *Sent:* Friday, January 03, 2014 11:55 AM<br>>>>> *To:* Jeremy Rowley; 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';<br>>>>> <a href="mailto:public@cabforum.org">public@cabforum.org</a> <mailto:<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>>>>> *Subject:* RE: [cabfpub] Definition of an SSL certificate<br>>>>><br>>>>> The FBCA and Common Policy CPs actually require all information<br>>>>> included in a certificate to be verified – so that would include any<br>>>>> domain names, see 3.2.4.<br>>>>><br>>>>> Thanks,<br>>>>><br>>>>> Wendy<br>>>>><br>>>>> Wendy Brown<br>>>>><br>>>>> FPKIMA Technical Liaison<br>>>>><br>>>>> Protiviti Government Services<br>>>>><br>>>>> <a href="tel:703-299-4705">703-299-4705</a> (office) <a href="tel:703-965-2990">703-965-2990</a> (cell)<br>>>>><br>>>>> <a href="mailto:wendy.brown@fpki.gov">wendy.brown@fpki.gov</a> <mailto:<a href="mailto:wendy.brown@fpki.gov">wendy.brown@fpki.gov</a>><br>>>>><br>>>>> <a href="mailto:wendy.brown@protiviti.com">wendy.brown@protiviti.com</a> <mailto:<a href="mailto:wendy.brown@protiviti.com">wendy.brown@protiviti.com</a>><br>>>>><br>>>>> *From:*<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a><br>>>>> <mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>><br>>>>> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] *On Behalf Of *Jeremy Rowley<br>>>>> *Sent:* Friday, January 03, 2014 11:19 AM<br>>>>> *To:* 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';<br>>>>> <a href="mailto:public@cabforum.org">public@cabforum.org</a> <mailto:<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>>>>> *Subject:* Re: [cabfpub] Definition of an SSL certificate<br>>>>><br>>>>> Many of the trusted QC issuers (and other community issuers) are not<br>>>>> involved in the CAB Forum. Although you are aware of the<br>>>>> requirements, I don’t think this knowledge is global. For example, I<br>>>>> don’t think the NIST CP or FBCA CP ever mentions domain validation. A<br>>>>> CA following either CP for client certs wouldn’t necessarily validate<br>>>>> an included domain.<br>>>>><br>>>>> Jeremy<br>>>>><br>>>>> *From:*<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a><br>>>>> <mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>><br>>>>> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] *On Behalf Of *Mads Egil<br>>>>> Henriksveen<br>>>>> *Sent:* Friday, January 03, 2014 4:52 AM<br>>>>> *To:* Moudrick M. Dadashov; Jeremy Rowley; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>>>>> <mailto:<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>>>>> *Subject:* Re: [cabfpub] Definition of an SSL certificate<br>>>>><br>>>>> Hi Moudrick<br>>>>><br>>>>> There might not be a real use case for including a domain name in a<br>>>>> QC, but as a trusted CA we take the responsibility for the accuracy of<br>>>>> information in all certs we issue. And that was my point and why I am<br>>>>> not very concerned about the described attack scenario.<br>>>>><br>>>>> Regards<br>>>>><br>>>>> Mads<br>>>>><br>>>>> *From:*<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a><br>>>>> <mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>><br>>>>> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] *On Behalf Of *Moudrick M.<br>>>>> Dadashov<br>>>>> *Sent:* 3. januar 2014 11:51<br>>>>> *To:* Mads Egil Henriksveen; Jeremy Rowley; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>>>>> <mailto:<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>>>>> *Subject:* Re: [cabfpub] Definition of an SSL certificate<br>>>>><br>>>>> Mads,<br>>>>><br>>>>> On 1/3/2014 11:49 AM, Mads Egil Henriksveen wrote:<br>>>>><br>>>>> The attack scenario assumes that the QC can be chained to a root<br>>>>> cert in a trusted CA root store. This means that the CA should<br>>>>> know the root store requirements and should be aware of the risk<br>>>>> issuing any cert that could be used as an SSL certificate.<br>>>>><br>>>>> Buypass do issue both QC and SSL certificates and with the<br>>>>> DigiNotar attack back in 2011 we realized that the browsers do<br>>>>> accept a lot of certificates as SSL certificates. Since then we<br>>>>> have had strict controls to ensure that no certificate is issued<br>>>>> with an unverified domain name. I guess most of the trusted QC<br>>>>> issuers who also issue SSL certificates are aware of this, I would<br>>>>> not be very concerned about this attack scenario.<br>>>>><br>>>>> What is the use case when in a QC we'd need a [any/unverified] domain<br>>>>> name? (aren't CAs responsible for the accuracy of information in the<br>>>>> QCs they issue?).<br>>>>><br>>>>> However, I do support the idea of a technical definition of an SSL<br>>>>> certificate and I like the proposal from Ryan Hurst requiring the<br>>>>> BR/EV OIDs.<br>>>>><br>>>>> Under ETSI framework compliance assumes two things: compliance with<br>>>>> the corresponding requirements plus certificate profile compliance.<br>>>>> These two categories exist as separate documents (under their own ETSI<br>>>>> IDs).<br>>>>> Ryan's proposal is definitely a good step forward, I'd vote with my<br>>>>> both hands if we go even further, and like ETSI, have separate BR/EV<br>>>>> profile specifications.<br>>>>><br>>>>> Thanks,<br>>>>> M.D.<br>>>>><br>>>>> NOTICE: Protiviti is a global consulting and internal audit firm<br>>>>> composed of experts specializing in risk and advisory services.<br>>>>> Protiviti is not licensed or registered as a public accounting firm<br>>>>> and does not issue opinions on financial statements or offer<br>>>>> attestation services.<br>>>>><br>>>>> This electronic mail message is intended exclusively for the<br>>>>> individual or entity to which it is addressed. This message, together<br>>>>> with any attachment, may contain confidential and privileged<br>>>>> information. Any views, opinions or conclusions expressed in this<br>>>>> message are those of the individual sender and do not necessarily<br>>>>> reflect the views of Protiviti Inc. or its affiliates. Any<br>>>>> unauthorized review, use, printing, copying, retention, disclosure or<br>>>>> distribution is strictly prohibited. If you have received this message<br>>>>> in error, please immediately advise the sender by reply email message<br>>>>> to the sender and delete all copies of this message. Thank you.<br>>>>><br>>>>><br>>>><br>>>><br>>>><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><br>>>><br>>><br>><br>><o:p></o:p></p></div></div><div><p class=MsoNormal>--<br>Rob Stradling<br>Senior Research & Development Scientist<br>COMODO - Creating Trust Online<br>Office Tel: <a href="tel:%2B44.%280%291274.730505">+44.(0)1274.730505</a><br>Office Fax: <a href="tel:%2B44.%280%291274.730909">+44.(0)1274.730909</a><br><a href="http://www.comodo.com" target="_blank">www.comodo.com</a><br><br>COMODO CA Limited, Registered in England No. 04058690<br>Registered Office:<br> 3rd Floor, 26 Office Village, Exchange Quay,<br> Trafford Road, Salford, Manchester M5 3EQ<br><br>This e-mail and any files transmitted with it are confidential and<br>intended solely for the use of the individual or entity to whom they are<br>addressed. If you have received this email in error please notify the<br>sender by replying to the e-mail containing this attachment. Replies to<br>this email may be monitored by COMODO for operational or business<br>reasons. Whilst every endeavour is taken to ensure that e-mails are free<br>from viruses, no liability can be accepted and the recipient is<br>requested to use their own virus checking software.<o:p></o:p></p></div><div><div><p class=MsoNormal>_______________________________________________<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></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>