<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=iso-8859-1"><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: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:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texto de globo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.EstiloCorreo17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
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 bgcolor=white lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi,<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><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Something to add to what Mou´s pointing out and that has been mentioned several times at different F2F meetings.<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'>Regarding the BRs the current TS 102 042 and the next to come, EN 319 411-4, have 2 new policies:<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'>OVCP: Organization Validation Certificate Policy<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'>DVCP: Domain Validation Certificate Policy<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'>(There´s a new one coming up called QWSCP: Qualified Web Site Certificate Policy in the EN regarding the EU regulation draft but we don´t know how this will end up)<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'>These 2 new policies are based on the BRs, and created because of these requirements, and are intended only for SSL certs. That´s it.<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 problem is what Mark has mentioned and Kelvin has re-organized, is what to do with those that are “kind of” SSL certs but have (or have not) the same profile.<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 think the BRs are just for server authentication and I like the new definition Mark proposed, very similar to what Jeremy stated.<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 CABF only dedicates to SSL certificates basically (up to now EV, OV, DV) and some others like code signing, s/mime are yet to come. (Well, EV code signing exists and it used EVCP+ policy, which is the one for those issued in SSCDs)<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'>These certs are not related IMO to qualified certs that we issue in Europe (QCP) but can fall into the NCP and they deviations, but that´s why these new policies were created, just to fit the CABF guidelines, EV and BR but only for SSL certificates. Other type of certificates, for example, non qualified certificates for legal entities, or natural persons use these other policies, LCP, NCP.<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'>Hope this clarifies ETSI position.<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'><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><div><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='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">i-barreira@izenpe.net</a><o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif"'>945067705</span><span lang=ES-TRAD style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><img border=0 width=585 height=111 id="Imagen_x0020_1" src="cid:image001.png@01CE947A.7AA29780" alt="Descripción: cid:image001.png@01CE3152.B4804EB0"></span><span lang=ES-TRAD style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='line-height:9.75pt'><span style='font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#888888;mso-fareast-language:ES-TRAD'>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!</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#888888;mso-fareast-language:ES-TRAD'><br></span><span style='font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#888888;mso-fareast-language:ES-TRAD'>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.</span><span style='font-family:"Calibri","sans-serif";color:navy;mso-fareast-language:ES-TRAD'><o:p></o:p></span></p></div><p class=MsoNormal><span 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 style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>De:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>En nombre de </b>Moudrick M. Dadashov<br><b>Enviado el:</b> jueves, 08 de agosto de 2013 20:12<br><b>Para:</b> Kelvin Yiu<br><b>CC:</b> 'CABFPub'<br><b>Asunto:</b> Re: [cabfpub] Ballot 108: Clarifying the scope of the baselinerequirements<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you, Kelvin, IMO this is a very constructive approach.<br><br>With this sense in mind I'd suggest the Forum to take a step forward and recognize/accept following policy applicability framework.<br><br>Today European policy framework defines following models:<br><br>1. LCP - Lightweihgt Certificate Policy;<br>2. NCP - Normalized Certificate Policy (also NCP+);<br>3. QCP - Qualified Certificate Policy (also QCP+);<br>4. EVCP - Extended Validation Certificate Policy (EVCP+).<br><br>Each model above has a ~formal set of requirements that might have been summarized by a formally accepted Profile or Certificate Template.<br><br>As we know the QCP Profile already exists (ETSI).<br>The EVCP Profile is more or less clear however has no formally approved form (to my best knowledge). But EVCP is de facto based on Forum's EVG.<br>If we agree/accept that NCP is a BR like model, then here comes Kelvin's approach and we end up with a NCP profile. As NCP is not just SSL we an call it e.g. NCP SSL Profile (BR Profile). <br><br>So the proposal is to accept the above model as a basis in further developing BR and EVG. Opinions?<br><br>Thanks,<br>M.D. <br><br>On 8/8/2013 8:10 PM, Kelvin Yiu wrote:<br>> One way to make progress is<o:p></o:p></p><p class=MsoNormal> perhaps for browsers to summarize the<br><br><o:p></o:p></p><p class=MsoNormal> > certificate profile (e.g. required fields and extensions)<o:p></o:p></p><p class=MsoNormal> that their<br><br><o:p></o:p></p><p class=MsoNormal> > browsers accept as SSL, code signing, or any other public<br><br><o:p></o:p></p><p class=MsoNormal> > certificates they accept. For example, I believe IE expects<o:p></o:p></p><p class=MsoNormal> SSL<br><br><o:p></o:p></p><p class=MsoNormal> > certificates require at least the following: (I will need to<o:p></o:p></p><p class=MsoNormal> do some<br><br><o:p></o:p></p><p class=MsoNormal> > research to confirm)<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > 1. Either no EKU extension, anyEKU, or the server auth EKU in<o:p></o:p></p><p class=MsoNormal> all<br><br><o:p></o:p></p><p class=MsoNormal> > certificates in the chain. IE may still accept the old SGC<o:p></o:p></p><p class=MsoNormal> olds as<br><br><o:p></o:p></p><p class=MsoNormal> > well 2. Valid DNS name in either the CN field in the subject<o:p></o:p></p><p class=MsoNormal> name, or<br><br><o:p></o:p></p><p class=MsoNormal> > one or more dNSNames or IPv4 address in the SubjectAltName<o:p></o:p></p><p class=MsoNormal> extension <br><br><o:p></o:p></p><p class=MsoNormal> > 3. Root CA must be enabled for server auth<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > For code signing certificates:<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > 1. Either no EKU extension, anyEKU, or the code signing auth<o:p></o:p></p><p class=MsoNormal> EKU in<br><br><o:p></o:p></p><p class=MsoNormal> > all certificates in the chain. 2. Root CA must be enabled for<o:p></o:p></p><p class=MsoNormal> code<br><br><o:p></o:p></p><p class=MsoNormal> > signing 3. Subject name must have either CN, or O, (and maybe<o:p></o:p></p><p class=MsoNormal> OU)<br><br><o:p></o:p></p><p class=MsoNormal> > field.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > Hence, OV SSL certificates that do not have an EKU extension<o:p></o:p></p><p class=MsoNormal> (or<br><br><o:p></o:p></p><p class=MsoNormal> > include the anyEKU OID) are valid for both SSL and code<o:p></o:p></p><p class=MsoNormal> signing.<br><br><o:p></o:p></p><p class=MsoNormal> > Arguably it is probably not the intention of the CA to issue<o:p></o:p></p><p class=MsoNormal> SSL<br><br><o:p></o:p></p><p class=MsoNormal> > certificates that can be also used for code signing.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > At a high level from the MS perspective, I want all CAs that<o:p></o:p></p><p class=MsoNormal> issue<br><br><o:p></o:p></p><p class=MsoNormal> > certificates that would be interpreted as SSL, code signing,<o:p></o:p></p><p class=MsoNormal> or<br><br><o:p></o:p></p><p class=MsoNormal> > whatever other usages allowed by the root program) to be in<o:p></o:p></p><p class=MsoNormal> scope of<br><br><o:p></o:p></p><p class=MsoNormal> > the discussion. The high level principle here is to prevent<o:p></o:p></p><p class=MsoNormal> or at<br><br><o:p></o:p></p><p class=MsoNormal> > least minimize unintended certificate usages that opens up<o:p></o:p></p><p class=MsoNormal> security<br><br><o:p></o:p></p><p class=MsoNormal> > vulnerabilities.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > So if while PIV certificates may include the anyEKU but do<o:p></o:p></p><p class=MsoNormal> not<br><br><o:p></o:p></p><p class=MsoNormal> > contain any valid DNS name, browsers may reject it for SSL so<o:p></o:p></p><p class=MsoNormal> they<br><br><o:p></o:p></p><p class=MsoNormal> > can be considered out of scope.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > I agree the much harder problem to resolve is whether to<o:p></o:p></p><p class=MsoNormal> include CAs<br><br><o:p></o:p></p><p class=MsoNormal> > with no EKUs that are capable of issuing SSL certificates,<o:p></o:p></p><p class=MsoNormal> but I<br><br><o:p></o:p></p><p class=MsoNormal> > don't have a good answer yet.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > Kelvin<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > -----Original Message----- From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a><br><br><o:p></o:p></p><p class=MsoNormal> > [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] On Behalf Of Jeremy<o:p></o:p></p><p class=MsoNormal> Rowley Sent:<br><br><o:p></o:p></p><p class=MsoNormal> > Thursday, August 8, 2013 9:04 AM To: 'Gervase Markham' Cc:<o:p></o:p></p><p class=MsoNormal> 'CABFPub' <br><br><o:p></o:p></p><p class=MsoNormal> > Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of<o:p></o:p></p><p class=MsoNormal> the<br><br><o:p></o:p></p><p class=MsoNormal> > baseline requirements<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > Yes - I am officially withdrawing the ballot pending further<br><br><o:p></o:p></p><p class=MsoNormal> > consideration.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > I'm not sure how to overcome these obstacles since: 1) PIV-I<o:p></o:p></p><p class=MsoNormal> in the<br><br><o:p></o:p></p><p class=MsoNormal> > US space requires the anyEKU 2) Qualified Certs may require<o:p></o:p></p><p class=MsoNormal> no EKU 3)<br><br><o:p></o:p></p><p class=MsoNormal> > Certificates without an EKU or the anyEKU may be used as SSL<br><br><o:p></o:p></p><p class=MsoNormal> > certificates 4) All SSL certificates should be covered by the<o:p></o:p></p><p class=MsoNormal> BRs 5)<br><br><o:p></o:p></p><p class=MsoNormal> > Qualified and PIV-I Certs cannot be covered by the BRs since<o:p></o:p></p><p class=MsoNormal> they<br><br><o:p></o:p></p><p class=MsoNormal> > lack a FQDN 6) SSL Certificates without an FQDN are<o:p></o:p></p><p class=MsoNormal> considered local<br><br><o:p></o:p></p><p class=MsoNormal> > host and explicitly covered by the BRs<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > I think the best option might be to simply acknowledge the<br><br><o:p></o:p></p><p class=MsoNormal> > inconsistency and change the definition as follows:<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > "All root certificates included in a browser's trust store,<o:p></o:p></p><p class=MsoNormal> all<br><br><o:p></o:p></p><p class=MsoNormal> > subordinate CA certificates signed by one of these root<o:p></o:p></p><p class=MsoNormal> certificates,<br><br><o:p></o:p></p><p class=MsoNormal> > and all end-entity certificates that either lack any Extended<o:p></o:p></p><p class=MsoNormal> Key<br><br><o:p></o:p></p><p class=MsoNormal> > Usage extension or contain an Extended Key Usage extension<o:p></o:p></p><p class=MsoNormal> that<br><br><o:p></o:p></p><p class=MsoNormal> > contain (i) either an Internal Server Name or a FQDN and (ii)<o:p></o:p></p><p class=MsoNormal> one of<br><br><o:p></o:p></p><p class=MsoNormal> > the following: - Server Authentication (1.3.6.1.5.5.7.3.1) -<br><br><o:p></o:p></p><p class=MsoNormal> > anyExtendedKeyUsage (2.5.29.37.0) - Netscape Server Gated<br><br><o:p></o:p></p><p class=MsoNormal> > Cryptography (2.16.840.1.113730.4.1) - Microsoft Server Gated<br><br><o:p></o:p></p><p class=MsoNormal> > Cryptography (1.3.6.1.4.1.311.10.3.3) are expressly covered<o:p></o:p></p><p class=MsoNormal> by these<br><br><o:p></o:p></p><p class=MsoNormal> > requirements."<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > Jeremy<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > -----Original Message----- From: Gervase Markham<br><br><o:p></o:p></p><p class=MsoNormal> > [<a href="mailto:gerv@mozilla.org">mailto:gerv@mozilla.org</a>] Sent: Thursday, August 08, 2013<o:p></o:p></p><p class=MsoNormal> 9:20 AM To:<br><br><o:p></o:p></p><p class=MsoNormal> > <a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a> Cc: 'CABFPub' Subject: Re:<o:p></o:p></p><p class=MsoNormal> [cabfpub]<br><br><o:p></o:p></p><p class=MsoNormal> > Ballot 108: Clarifying the scope of the baseline requirements<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > On 02/08/13 12:19, Jeremy Rowley wrote:<br><br><o:p></o:p></p><p class=MsoNormal> >> There is a potential conflict that I think needs more<o:p></o:p></p><p class=MsoNormal> data and<br><br><o:p></o:p></p><p class=MsoNormal> >> discussion:<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > We agree; hence Mozilla votes NO on the ballot in its current<o:p></o:p></p><p class=MsoNormal> form.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > We would like to see it withdrawn until further information<o:p></o:p></p><p class=MsoNormal> can be<br><br><o:p></o:p></p><p class=MsoNormal> > gathered. We very much support the goal of this ballot; we<o:p></o:p></p><p class=MsoNormal> want the<br><br><o:p></o:p></p><p class=MsoNormal> > BRs to cover all certs capable of being used by SSL servers.<o:p></o:p></p><p class=MsoNormal> But we<br><br><o:p></o:p></p><p class=MsoNormal> > need to figure out whether this requires a change in the<o:p></o:p></p><p class=MsoNormal> definition<br><br><o:p></o:p></p><p class=MsoNormal> > of what the BRs cover, or a change (e.g. on clients) in the<br><br><o:p></o:p></p><p class=MsoNormal> > definition of "capable of being used by SSL servers". Or<o:p></o:p></p><p class=MsoNormal> something<br><br><o:p></o:p></p><p class=MsoNormal> > else.<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > Gerv<br><br><o:p></o:p></p><p class=MsoNormal> > <br><br><o:p></o:p></p><p class=MsoNormal> > _______________________________________________ Public<o:p></o:p></p><p class=MsoNormal> mailing list <br><br><o:p></o:p></p><p class=MsoNormal> > <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></p><p class=MsoNormal> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a> <br><br><o:p></o:p></p><p class=MsoNormal> > _______________________________________________ Public<o:p></o:p></p><p class=MsoNormal> mailing list <br><br><o:p></o:p></p><p class=MsoNormal> > <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p></div></body></html>