<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<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 name=Generator content="Microsoft Word 14 (filtered medium)"><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:Cambria;
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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Cambria","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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{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: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-family:"Arial","sans-serif"'>Notes of meeting - CAB Forum - 27 June 2013 - Version <span style='color:#1F497D'>2</span><o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>1. Present: Rich Smith, Atsushi Inaba, Ben Wilson, Mads Henriksveen, Dean Coclin, Geoff Keating, Jeremy Rowley, Stephen Davidson, Kirk Hall, Robin Alden, Eddy Nigg, Steve Roylance, Kelvin Yiu, <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>2. Agenda review: Approved as published.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>3. Minutes: Approve Minutes of 30 May 2013: Approved for publication. On the minutes from the Munich face-to-face, it was decided that those would be converted from Word to wiki format because it will be easier to edit typos, grammar, etc. in that format. Then we urge everyone to review and edit them as needed to give more clarity if needed. We’ll add a notice to the top of the final version to indicate that the different presentation styles are due to the fact that the notes were taken by different individuals, rather than because of any other reason. A deadline was set for the meeting that follows August 1 at which time they would be presented for approval. <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>4. Ballots: Ballot 100 has been withdrawn and Steve R. is working on a new ballot with Kathleen and Stephen to address name constraints. There was no objection to posting version 1.1.5 of the BRs and version 1.4.2 of the EVGs as a result of Ballots 101 and 102. Ben will create a proposed ballot for SHA2, and Mads will create a ballot to remove version numbers from EVG 8.2, 17.1, and 17.4 and BR 3 and 17.1. Ben is willing to endorse that proposed ballot, but another endorser is needed, and he wondered whether any clarifying language was needed. Kirk suggested that the final language of the ballots (and the redlined versions) be circulated for review as a next step. <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>Steve R. explained that he has worked on a replacement for Ballot 100 that addresses concerns and comments about name constraints and technical constraints. To summarize, the proposal is that if you technically constrain the sub CA you do not need to address the OCSP response issue in the short term. This is similar to Google’s approach that if you use Certificate Transparency there is less risk. So, if you constrain a sub CA you buy time, and you would not need to do as much as compliance effort as if you were a full CA. Dean asked whether technical documentation would be available soon. Steve said it would and that they had received some good feedback from several persons, and that the primary issue now has to do with EKUs because EKUs in sub CAs are not RFC-compliant. <span style='color:#1F497D'> </span><i><span style='background:yellow'>(Post 1<sup>st</sup> draft Minutes follow up: Steve has clarified - RFC5280 states that EKU's generally appear in End Entities only, rather than being specifically disallowed in SubCAs (See 4.2.1.12 of RFC 5280))</span></i>. In other words, the use of client and server authentication EKUs cause problems with Microsoft, and so he is working with Microsoft on that issue. The proposal also replaces the OCSP EKU with language to the effect that “other EKUs may be included.” The subCA constraints are applicable not just for SSL, so you may want to include other EKUs in the subCA, such as keyArchival, etc.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>Dean noted that Microsoft’s current root CA policy is not in harmony with the Mozilla policy or this approach to audits because it (Section F.3) currently does not provide a clear exception for this type of technical constraint approach. Dean said that Rick has also raised concerns in the recent past about other aspects of the Baseline Requirements and the Microsoft Technical Requirements regarding minimum key length sizes and other issues that cannot be easily controlled by Root CAs over external sub CAs. Dean also said that Rick was concerned about Apple clients, who would still be exposed to security risks because the Apple client does not handle name constraints. Steve said he had talked to Rick about this latter point. Steve’s hope is that Apple will see how name constraints are going to be used and that as a result they will address this issue with their client. He also said that on things like key size, he proposes that this be handled with legal and compliance requirements for agreements between the CA and external sub CA. Kelvin said that he would talk to Tom and that they would review that Microsoft policy requirement. Dean and Steve agreed that this would need to be reviewed and addressed.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>Kelvin asked for an update on the status of commercial OCSP responders that cannot comply with the prohibition on responding “good” for non-issued certificates. Steve explained that the proposal would postpone this issue until 2014 for CAs that implement name constraints / technical constraints. Ben said that he is concerned that the August 1 deadline is approaching fast. There are several parties out there who are concerned about making this date, including Wells Fargo. Stephen Davidson said we need to be aware of the situation with off-the-shelf OCSP responder systems. While we may know the situation for Microsoft, CoreStreet, Ascertia, EJBCA, we do not know the status for systems such as SafeLayer, Nexus, and others that small European CAs may be using. Kelvin agreed that it was important point because we need to know the compliance status of all of these providers because we should not re-set the deadline for another year just to find out that it was insufficient. Ben said that he had to cut off discussion on this topic because we had gone over time, but we should make sure that there is some communication with / among the providers who are all in the same boat on this issue. <i><span style='background:yellow;mso-highlight:yellow'>(Post </span><span style='background:yellow'>1<sup>st</sup> draft </span><span style='background:yellow;mso-highlight:yellow'>minutes follow up: Iņigo states that Safelayer is patched/compliant.)</span><o:p></o:p></i></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>5. News/Announcements: Ben noted that we need to take a look at the WPKOPS Trust Model Paper and comment on it as needed. Jeremy noted that Iņigo and Bruce had published papers that should be reviewed and commented on. He also said there has been some discussion on the scope of the WPKOPS charter and what is within or outside of the charter. <i><span style='background:yellow;mso-highlight:yellow'>(Post </span><span style='background:yellow'>1<sup>st</sup> draft </span><span style='background:yellow;mso-highlight:yellow'>minutes follow up: Iņigo states the WPKOPS scope is just for browsers and SSL certs (which I discussed saying thatīs covered by the CAB Forum). So the trust models document will not include web services or users with smart cards authenticating to web sites, i.e. just HTTPS.)</span> </i>Ben said that we should capture any discussions that we see are important, and if something is eliminated from WPKOPS discussions because of scope, then the CAB Forum should take them on. Jeremy also noted that the ICANN draft on Registration Directory Service (RDS) has been proposed as a replacement for WHOIS with additional controls on information that will be made available. We should review the link posted by Rob Stradling and provide comments as appropriate. Finally, Ben said that he would follow up on the questions from Eneli Kirme of Sertifitseerimiskeskus just to make sure that the questions have been adequately answered by Jeremy and Geoff.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>6. Overview of Project Lifecycle: Ben said that the Project Lifecycle document needs to be kept up to date in light of changes to the guidelines, adoption of the IPR and because of our recent discussions over guidelines, audits, and browser program requirements. He will provide a revised draft of the Project Lifecycle, but just at a high level, the document needs to address “proposals” and not just “project proposals.” Some proposals will need work groups, others will not. Proposals should go through a CA/Browser meeting discussion before presentation as a forum draft. There is now greater public disclosure because of the public email list, but there are proposals of such a nature that we should also post them to the CA/Browser Forum web site and perform outreach to the greater PKI community. After a guideline is adopted, we also need to send out the IPR notice. All of these things should be outlined in the lifecycle document. Also, once we implement the annual hand-over process for audit criteria development, that should be described, as well as browser implementation and the process by which browsers begin requiring compliance with guideline revisions/audit criteria. <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>7. Discuss status on web site assignments: Dean said we need to make progress on this by setting a deadline for having each of these pages on the wiki by July 31. Ben said that he will bird-dog this by sending email reminders to people assigned on a weekly basis and ask about their status toward completion, effort remaining, etc. He will also send people the existing content so they know what already exists and has been written.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>8. Any other business: <o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>Oracle: Dean said that he had talked to Oracle and they are interested in joining the CA/Browser Forum, especially as it concerns the Code Signing Working Group. However, they need to discuss it further internally and then will be getting back to us.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>Code Signing Working Group: The Code Signing Working Group has its call next week.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>9. Next teleconference: Next call will be in two weeks – Thursday, July 11<sup>th</sup> .<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div></body></html>