<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 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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 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:"\@Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-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.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";}
p.Body1, li.Body1, div.Body1
{mso-style-name:"Body 1";
margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Helvetica","sans-serif";
color:black;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
p.Textodeglobo, li.Textodeglobo, div.Textodeglobo
{mso-style-name:"Texto de globo";
mso-style-link:"Texto de globo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{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;}
/* List Definitions */
@list l0
{mso-list-id:2;
mso-list-template-ids:-1991317388;}
@list l0:level1
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level2
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level3
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level4
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level5
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level6
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level7
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level8
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
@list l0:level9
{mso-level-start-at:0;
mso-level-text:"";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0cm;
text-indent:0cm;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Inigo,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>As I said, I don’t dispute the requirements of the regulations, what I was querying was why would a website operator choose a Qualified website certificate rather than sticking with an EV cert ? In particularly, what basis do you have for saying that they would be <b>required</b> to have a Qualified website cert ?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Richard<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Times New Roman","serif";color:black'>------------------------------------<br>Richard Trevorah<br>Technical Manager<br>tScheme Limited<br><br>M: +44 (0) 781 809 4728<br>F: +44 (0) 870 005 6311<br><br></span><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D'><a href="http://www.tscheme.org" target="_blank">http://www.tscheme.org</a><br></span><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:black'>------------------------------------<br><br>The information in this message and, if present, any attachments are intended solely for the attention and use of the named addressee(s). The content of this e-mail and its attachments is confidential and may be legally privileged. Unless otherwise stated, any use or disclosure is unauthorised and may be unlawful.<br><br>If you are not the intended recipient, please delete the message and any attachments and notify the sender as soon as practicable</span><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='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>i-barreira@izenpe.net<br><b>Sent:</b> 16 July 2012 09:06<br><b>To:</b> richard.trevorah@tScheme.org<br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> [cabfpub] RE: RE: Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28 June 2012<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=ES style='color:#1F497D'>Richard,<o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'>Article 37 of the new EU regulation indicates the requirements for qualified certificates for website authentication and the qualified certificates can only be issued by qualified TSP as indeicated in article 3, definitions.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'>This EU regulation is for all EU countries, this is not about different legislation in different countries, so this will apply the same to the UK TSPs than spanish or German ones. There won´t be any difference between member states.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'>OTOH, this is a draft and have many concerns, and, for example, ETSI ESI have been discussing them from a Technical point of view and for example, I raised some concerns of what can happen to comercial CAs, the CABF members, etc. These, and others, have been included in a document that is going to be sent to the EU commission. I think there will be some other new drafts before the final version will be approved.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal style='line-height:9.75pt'><b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'><o:p> </o:p></span></b></p><p class=MsoNormal style='line-height:9.75pt'><b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'>Iñigo Barreira</span></b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'><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";color:black'>945067705</span><span lang=ES-TRAD style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=ES style='color:#1F497D'><img border=0 width=585 height=111 id="Imagen_x0020_1" src="cid:image001.png@01CD6351.F9629260"></span><span lang=ES-TRAD style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='line-height:9.75pt'><span lang=ES style='font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#888888'>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 lang=ES style='color:#888888'><br></span><span lang=ES style='font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#888888'>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 lang=ES style='font-size:12.0pt;color:navy'><o:p></o:p></span></p></div><p class=MsoNormal><span lang=ES style='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=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"'> tScheme Technical Manager [<a href="mailto:richard.trevorah@tScheme.org">mailto:richard.trevorah@tScheme.org</a>] <br><b>Enviado el:</b> miércoles, 11 de julio de 2012 15:16<br><b>Para:</b> Barreira Iglesias, Iñigo<br><b>CC:</b> 'CABFPub'<br><b>Asunto:</b> RE: [cabfpub] Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28 June 2012<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Hi Inigo,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>On what basis did you say that “</span><span lang=EN-US>European Web sites would be required to have a qualified certificate</span><span style='color:#1F497D'>” ?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I agree that the regulation would allow UK TSPs to claim that they issue ‘Qualified website certificates’ and they would have to meet the same standards as any such providers based in other Member States. That is not the same as saying that commercial providers/users must use such products.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>As always it is likely to be the commercial imperative of recognition by browser trust stores that will drive adoption not legislation – at least in the UK, I can’t answer for Spain etc.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Best regards<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Richard<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Times New Roman","serif";color:black'>------------------------------------<br>Richard Trevorah<br>Technical Manager<br>tScheme Limited<br><br>M: +44 (0) 781 809 4728<br>F: +44 (0) 870 005 6311<br><br></span><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D'><a href="http://www.tscheme.org" target="_blank">http://www.tscheme.org</a><br></span><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:black'>------------------------------------<br><br>The information in this message and, if present, any attachments are intended solely for the attention and use of the named addressee(s). The content of this e-mail and its attachments is confidential and may be legally privileged. Unless otherwise stated, any use or disclosure is unauthorised and may be unlawful.<br><br>If you are not the intended recipient, please delete the message and any attachments and notify the sender as soon as practicable</span><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='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"'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Tim Moses<br><b>Sent:</b> 04 July 2012 17:19<br><b>To:</b> CABFPub<br><b>Subject:</b> [cabfpub] Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28 June 2012<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=Body1><span lang=EN-US>Notes of meeting<o:p></o:p></span></p><p class=Body1><span lang=EN-US>CA/Browser Forum<o:p></o:p></span></p><p class=Body1><span lang=EN-US>Gj</span><span lang=EN-US style='font-family:"Arial Unicode MS","sans-serif"'>ø</span><span lang=EN-US>vik, Norway<o:p></o:p></span></p><p class=Body1><span lang=EN-US>26-28 June 2012<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>1. Introductions<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tim Moses, Don Sheehy, David Rockvam, Bruce Morton, Ryan Koski, John Johansen, Mads Henriksveen, Sissel Hoel, Simon Labramm, Jens Bender, Kerstin Sch</span><span lang=EN-US style='font-family:"Arial Unicode MS","sans-serif"'>ö</span><span lang=EN-US>nherr, Rick Andrews, Ben Wilson, Jon Callas, Kirk Hall, Gerv Markham, Arno Fiedler, Robin Alden, Moudrick Dadashov, Tom Albertson, Dean Coclin, Yngve Pettersen, Inigo Barreira, Jeremy Rowley, Brad Hill, H</span><span lang=EN-US style='font-family:"Arial Unicode MS","sans-serif"'>å</span><span lang=EN-US>vard Mollard<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>Bruce read the anti-trust statement.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>2. In the news<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve said that Opera 12 has been released, with some certificate-related updates. He brought up renewed concerns about the security of MD5 resulting from the "Flame" incident.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Gerv said that CNNIC has applied to have its root included. He said that it is already included in Windows and Opera. Rick asked whether it would make sense to (for instance) remove Chinese CAs from the list of CAs trusted by default by US users. Gerv said that the idea of localized trust-stores has been consider. But, problems exist. He thought that CA-pinning would provide a better solution. Jens mentioned problems with pinning, such as the "initial trust" problem, key roll-over and multiple certificates per domain. Gerv said that "large-scale surveillance" helps with the initial trust problem.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Brad said that the installed OS language pack could determine which CAs to trust by default. Gerv said that some portion of users would be adversely affected. And some CAs need to be able to operate in multiple regions.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tom said that Microsoft has merged its root programs for Windows and Windows Phone.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Microsoft has introduced an accelerated CA-disablement mechanism that will allow them to disable a CA within 24 hours. It is effective for both roots and Sub-CAs. They are hesitant to extend the mechanism to end-entity certificates.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Microsoft will stop accepting RSA keys shorter than 1024-bits in August. There will be an exception for keys of length 1023-bits.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Robin said that CAA has passed working group last-call. However, BR v1.1 will be ratified too soon to incorporate CAA.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve said that Apple has upgraded iOS to require 1024-bits. Gerv said that Mozilla is likely to do the same. Yngve mentioned that IBAN still uses a 768-bit ciphersuite.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Rick mentioned that the DANE RFC has been ratified. He is concerned that browsers may grant self-signed certificates the same UI treatment as TTP certificates. Gerv said that Mozilla may consider a DANE key as equivalent to a DV certificate. Tim pointed out that this would mean that DANE keys would be rated equivalently to an OV certificate.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Kirk asked if Mozilla would require DNSSEC operators to submit to audit. Brad pointed out that DV certificates are just as reliant on correct operation of DNS as DANE is.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Rick suggested preparing a profile of DANE that leveraged TTP certificates, and he asked for interested CAs to contact him.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tom said that (some time ago) he had had contact with DANE proponents. He had explained to them Microsoft's key-reliance assurance requirements. The proponents did not consider those requirements appropriate to DANE. Tom said that he couldn't predict how browsers would treat DANE keys.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>3. WebTrust<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Don said that WebTrust for CAs v2.0 will come into force on 1 July 2012. The task force has developed an exposure draft for the Baseline Requirements. It is proposed that an audit covering Baseline Requirements will result in a report separate from the WebTrust for CAs report.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>The task force will meet sometime in the last two weeks of July to address comments received from CICA and AICPA on the exposure draft. They expect to have a functional version by September 2012. At that point it will be practical for root programs to require BR compliance. But, audit to these criteria will require the CA to have operated in accordance with the Baseline Requirements for the duration of the audit period. Network security requirements will be addressed in a future version.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Gerv said that an audit letter should indicate which version of the criteria were used in the evaluation.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Don said that WebTust for CAs v2.0 is organized in accordance with ISO21188. He said that some WebTrust clients don't issue publicly-trusted certificates, so WebTrust for CAs cannot be replaced by the Baseline Requirements criteria. However, the task force is considering combining the two criteria in a single document.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Don said that the Network Security Requirements are now in a condition that is much more suitable for auditing purposes. They will ultimately be incorporating into WebTrust for CAs v2.1. Inigo said that ETSI is monitoring the Network Security Requirements project.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Don thanked Ben for his assistance in the development of the network secure criteria.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>4. ETSI<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Arno made a presentation on TS 102 042 v2.1.1 that was issued in Dec 2011. It will become a European Norm. ETSI is also working on TR 101 564 that was issued in September 2011, containing guidance to auditors when conducting EV audits.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>TS 119 403 v1.1.1 (issued in March 2012) defines qualification requirements for auditors.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Each European country has its own scheme for managing audits and accrediting auditors. National accreditation bodies are listed under “European Co-operation for Accreditation”. And qualified TSPs are listed in the Trust Service Status List. The list is a signed XML document.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tom observed that the list does not indicate against which standard the conformance was assessed. Inigo said that it would depend upon the country; but all are “qualified”. Arno said that this deficiency is recognized. Jens said that the list relates to qualified signatures, and (by law) all such signatures are considered equivalent. But, the same cannot be said of SSL certificates.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Arno said that TS 102 042 v2.3.1 incorporates the Forum’s Baseline Requirements. There is a corresponding TR being prepared. It will be practical to conduct a v2.3.1 audit by October 2012.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Arno reported on new regulations that are being prepared to replace the Electronic Signature Directive. Unlike the original directive, the new regulation will SUPERSEDE national legislation. It would require clear supervision of TSPs and require annual audit. It will also introduce “qualified” Web server certificates.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Arno mentioned plans to hold another CA Day in Berlin on 28 and 29 November 2012. He offered the possibility of a joint meeting with CABForum.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Inigo mentioned that a draft of the new regulation has been published:-<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><a href="http://ec.europa.eu/information_society/policy/esignature/eu_legislation/regulation/index_en.htm"><span lang=ES>http://ec.europa.eu/information_society/policy/esignature/eu_legislation/regulation/index_en.htm</span></a></span><span style='color:black'><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='color:black'> </span><span style='color:black'><o:p></o:p></span></p><p class=Body1><span lang=EN-US>It talks about Trust Service Providers, rather than CAs. It covers person signatures, Web-servers, time-stamps, and email. It defines electronic seals and advanced electronic seals.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>The regulation admits TSPs from non-member countries. Apparently, Adobe is considering using the EU trust list instead of managing its own root store.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Inigo was asked if European Web sites would be required to have a qualified certificate; he said yes. However, Jens said that he read the regulation differently. Qualified certificates will be identifiable by a policy identifier; a certificate that claims to be qualified must be qualified.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>It is hoped that the regulation will come into effect on or before 2014.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>5. BSI (Germany’s Federal Office for Information Security)<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jens presented on the BSI’s plans in relation to Web server certificates. He noted a shift in attack strategy away from individual targets towards infrastructure targets.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>He discussed the Diginotar incident and noted that Diginotar was considered trusted on the basis of a PWC audit to ETSI standards. Diginotar also posted a false WebTrust seal on account of a qualified EV audit report (also conducted by PWC). The ETSI audit discovered no major invalidities. Jens noted that some mobile devices still trust the Diginotar root.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jens said that Diginotar suffered well-understood IT security flaws. And the audit didn’t work as expected. The audit should cover network architecture. The flaws should have been uncovered in both the ETSI and WebTrust audits.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>He concluded that the SSL PKI can only work if it is seen to be trustworthy. So, we need to rebuild trust in the SSL PKI. As part of this we need a trustworthy audit process. But, currently, there is no comparability between audits. Penetration testing should be part of the framework. And, there should be a common base of security regardless of the application (Web, email, etc.).<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Germany is working on requirements, based on ISO 27001 and common criteria. There will be generic requirements for all CAs and “building blocks’ per application. They plan to impose the requirements wherever they can and promote them in other countries.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>6. Governance<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy noted that there are currently five proposals. One of the goals for governance reform is increased transparency. Gerv said that he is preparing a clearer proposal on transparency that he will bring forward for ballot.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy pointed out the major axes upon which the proposals differ. These are: broad versus narrow scope; Division into working groups versus not; IPR committed at the WG level versus Forum level; and voting limited to CAs and browsers versus including other interested parties.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy suggested a straw poll to choose one proposal for a ratification ballot.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Brad said that the revocation topic is an example of a topic that fits the broader scope definition.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>There was some discussion of a suitable procedure for selecting amongst three or more options. Kirk moved that we conduct a series of elimination ballots. But, no one endorsed the motion.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tim made the following motion and Gerv and Ben endorsed it.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>--- MOTION BEGINS ---<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>The Forum instructs the chair as follows:<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>1. Arrange for the proposals developed by the Governance Reform Working Group to be posted on the Forum's public Web site.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>2. As soon as it appears that the membership set will be stable for the duration of steps 3-7 (below), announce a ballot with the following steps.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>3. A 7-day review period.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>4. A 7-day voting period.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>5. An instant run-off ballot to eliminate all but two of the proposals; "no change" is to be included as one of the choices.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>6. A two week period during which the authors of the two remaining proposals may modify their proposals while keeping to the spirit of the proposal that he or she posted in step 1 (above).<o:p></o:p></span></p><p class=Body1><span lang=EN-US>7. Announce a simple-majority ballot to select between the two remaining proposals, comprising a 7-day review period and a 7-day voting period.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>8. A period of undefined duration during which the author of the successful proposal shall refine the proposal in order to ensure its completeness, while keeping within the spirit of the proposal that he or she posted in step 1 (above).<o:p></o:p></span></p><p class=Body1><span lang=EN-US>9. A ballot conducted in accordance with established Forum procedures to ratify the proposal that emerged from step 8 (above).<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Note: The instant run-off ballot shall be conducted as follows.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Where there are 'n' initial proposals, each voting member may assign the numbers 1 to n to the proposals in order of preference (1 indicating their most preferred choice). Each member who votes shall (at least) assign the number '1', and may assign further numbers up to and including 'n'.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Votes ranked '1' shall be counted and the proposal with the fewest votes shall be eliminated. The votes of the corresponding members shall be reassigned to the proposal ranked '2' by those members. Where a member has not identified a proposal with rank '2', his or her vote shall not be reassigned.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>This procedure shall be repeated, counting reassigned votes, until just two proposals remain.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>--- MOTION ENDS ---<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>The results were as follows:<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yes: DigiCert, Izenpe, Opera, Entrust, Symantec, Microsoft, SSC, Comodo, Mozilla, Go Daddy, Trend Micro, GlobalSign, BuyPass.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>No: none.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Abstain: none.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Result: approved.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>7. IPR<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy provided a summary of the situation. 25 of the 50 existing members have entered into the agreement. Some others said that they would sign, but they require more time. The most contentious issue is RAND versus RANDZ.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>He listed some issues with the policy:<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:0cm;mso-list:l0 level2 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>It is unclear whether blanket exclusions are acceptable;<o:p></o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:0cm;mso-list:l0 level2 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>Different approaches are needed for applications and issued patents;<o:p></o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:0cm;mso-list:l0 level2 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>We need to clarify whether and how the policy applies to observers;<o:p></o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:0cm;mso-list:l0 level2 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>We need to clarify how the provisions apply to acquiring entities; <o:p></o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:0cm;mso-list:l0 level2 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>We need to clarify how the provisions apply to affiliates; and<o:p></o:p></span></p><p class=Body1 style='margin-left:0cm;text-indent:0cm;mso-list:l0 level2 lfo2'><![if !supportLists]><span lang=EN-US><span style='mso-list:Ignore'><span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-US>The treatment of new members could be considered a restraint on trade.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy said that, if we are determined to overturn the recent emergency ballot, then we need to ballot a new motion by 18 July.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Revisions to the policy have been proposed by both Jeremy and Jon. Jon’s proposal emphasized “disclosure”.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Gerv raised the question of revising the existing policy versus starting from scratch. Tom said that revisions have to be considered by the IPR working group.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve said that an inventor should be required to explain how their patent applies to the Forum’s work product. Ben said that this is not realistic.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Gerv suggested that we handle each proposed change in isolation in order to gauge the extent of its impact. Tom also suggested that each change proposal be accompanied by an explanation.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Kirk suggested that a “covenant not to sue” would be preferable to the existing obligation.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Arno said that ETSI has standard clauses to deal with these issues.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jon said that it would be practical to adapt the existing policy. He thought that the treatment of affiliates and blanket exclusion were the main problems.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Kirk said that the onus for action should be on the IP holder, not on members as a whole.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>It was generally agreed that observers should be subject to a very lightweight process; we should not erect barriers to receiving input from other experts.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy said that the treatment of new members was likely an oversight. Tom said that he thought it was intentional. Jon said that the fact that a review period is specified suggests that it is an oversight.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Ben said that members should not be allowed to avoid the provisions of the policy by creating an IP holding company.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Jeremy proposed that we reconstitute the IP working group and instruct it to propose minimum changes to accommodate hold-outs. This was agreed.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Gerv asked whether we should abandon the existing policy or leave it in place while revisions are considered. Ben suggested that we extend the deadline for signing the agreement to 1 Jan 2013. Jon argued that the policy be suspended until such time as revisions have been agreed.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>It was agreed that the existing policy would come into force on 1 Aug and the IP working group would be asked to propose minimum revisions to accommodate Entrust’s concerns. Entrust would be invited to participate in those discussions even though its membership will lapse on 1 Aug.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tim was asked to send email to all current members who have not entered into the agreement pointing out that their membership will lapse on 1 Aug.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>8. BR Issues list.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 1. Gerv said that Kathleen Wilson has been conducting a discussion, but a clear answer has yet to emerge. Tom said that v1.1 should not be held up as a result.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 5. Yngve said that he is still working this issue within PKIX. A “Revoked” response would have to be signed. And, we need to avoid the need for real-time signing.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Rick said that we should consider demanding changes in browser behaviour.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>It was decided to disallow the “Good” response in the case where the OCSP responder for a particular CA does not know if that CA issued the certificate.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Inigo said that we should seek clarification from PKIX on the use of certificate suspension.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 6. Yngve said that his email of 20 June contains a proposal. Some further refinement is required. It was decided that proposals should be documented in the issues list.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 7. Rick said that some customers demand smaller certificates. Gerv said that CAs should be given discretion in this regard. So, it shouldn’t be a “MUST”. Perhaps this issue should be balloted separately.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 8. Ryan argued that revoking a subCA requires more time. Gerv suggested that we only specify a requirement for end-entity certificates. Bruce agreed to champion a new issue related to revocation of subCAs.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 10. Yngve said that this is addressed in his proposal. Rick said that we should seek the guidance of cryptographers. Yngve said that he would look for guidance from NIST.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 14. It was agreed to disallow individual names in the CN attribute. With that modification, the ballot is ready to proceed.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 15. Bruce said that he combined this issue with a later one and made a proposal. Brad said that CAs should be required to revoke a certificate when its private subject TLD becomes public.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Brad suggested that CABForum consider lodging objections to commonly-used TLDs. Gerv said that ICANN should reserve TLDs that already in common use.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>CAs were asked to analyze their current certificates for TLDs that will become public. Rick offered to consolidate the results. Brad said that (in case CAs are concerned about disclosing to Symantec) he would be willing to do the consolidation.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Brad said that CAs should start notifying affected customers immediately.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 16. Has been superseded.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 17. The proposal was in Ballot 78, which was approved.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 18. This will not be advanced in v1.1.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 20. Withdrawn.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 23. Mozilla has an exception on the topic of qualified audits. Microsoft is removing its allowance of ISO21188. Apple disallows it.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Robin asked that his name be removed from the issue. Jeremy agreed to take leadership of the issue.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 24. Jeremy said that the wording could be clearer. He will suggest a revision.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Issue 30. The issue is resolved and can be included in an upcoming ballot.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>9. Qualified CSPs<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tom said that this is not an issue today, as Qualified CSPs do not necessarily issue SSL certificates. Jens agreed; today, SSL certificates are not qualified. Tom said that he would be meeting with Stephane Santeson in July to discuss the implications of the BRs for Qualified CSPs.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>10. Network Security Controls<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Ben walked through the current draft. Changes were made and agreed.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>In the case of password management, it was agreed to identify and refer to an existing standard.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>It is understood that these requirements will be implemented as part of the WebTrust and ETSI processes.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>It was agreed to go to ballot with a motion along the lines of the BR v1.0 motion.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>11. Revocation<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Rick went through the current draft. It recommends adherence to RFC 5019 over RFC 2560. It recommends using GET as opposed to POST. The client could fall back to POST in case GET is not supported by the server. There were some questions over what error would be returned in this case.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Some performance results are available.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Rick said that it is important to achieve consistent behaviour amongst OCSP clients.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>The document recommends support for stapling.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve said that Opera does not cache OCSP responses, but it does request session-resume.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Ryan said that Go Daddy OCSP responses are valid for six hours and are updated every three hours.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>There was some discussion of the size of OCSP responses and how they might drive over a packet boundary.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve suggested that there should be a companion document with recommendations for Web servers, addressing (amongst other things) session resumption. A significant number of servers don’t support this feature. Session resumption may depend on shared state across a back-end network or a session ticket cookie. Ryan said that the former would be rare. Load balancers may ensure that clients continue to be served by the same server.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Ryan asked about the purpose of the project. Gerv said that there is value in a “best practices” statement from the Forum to help prioritize Mozilla’s development program. Yngve agreed.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Robin pointed out that a client may have good connectivity to a Web-server, but poor connectivity to the CA’s OCSP responder.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Some felt that Google’s CRL Set solution may not be suitable for all browsers.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tom said that Microsoft’s new “disallowed CTL” is not meant to replace CA revocation schemes.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>There appeared to be broad agreement that stapling is the best solution. Nevertheless, there is value in recording other recommendations (such as retry and preference for GET).<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve raised the question of how long a certificate should be relied upon when an OCSP response cannot be obtained.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>There was also some discussion concerning client support for multiple URIs, which is offered in Windows, but not in other clients.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Robin mentioned the “must staple” proposal. But, it was acknowledged that this only defends against certain attack vectors.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Ryan raised the question of revocation for subCAs and the long validity time that is allowed. Rick said that he would address this question in a future version of the document.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>There was some discussion of the need for accurate (though not precise) time at the client. This is a requirement for short-lived certificates, as much as for short-validity revocation information. Gerv pointed out that it would not be acceptable for a browser to modify the platform’s clock. It was pointed out that the browser could keep its own record of the offset.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>There was also some discussion of nonces. Yngve said that Opera does not use nonces. And Rick said that Symantec does not respond to nonces.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Yngve asked for guidance on how to respond to certain HTTP errors.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tim suggested that the document should include a section on threats, indicating which threats are addressed by the recommendations and which are not.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Brad said that advancing stapling was probably the highest priority. He said that it should be mandatory to include revocation information in certificates (except short-lived certificates). Clients can use the policy identifier to identify certificates for which revocation information MUST be present.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tim said that the revocation document should be on the Wiki. Rick agreed to post it.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Tim asked whether it would make sense to style this document as an Internet BCP. He said that he would open up discussions with the IETF Operations and Management Area directors in order to consider whether the Forum’s technical documents could be managed there.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>12. 2013 meeting calendar<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>The following tentative calendar was agreed.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US>Feb-Mar. Mozilla, Mountain view, USA.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>May-Jun. Izenpe, Bilbao, Spain.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>Or<o:p></o:p></span></p><p class=Body1><span lang=EN-US>Symantec, Reading, UK.<o:p></o:p></span></p><p class=Body1><span lang=EN-US>Sep-Oct. Entrust, Dallas, USA.<o:p></o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=Body1><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>T: +1 613 270 3183<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div></body></html>