<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:x="urn:schemas-microsoft-com:office:excel" 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: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: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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.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=MsoPlainText>Gerv,<o:p></o:p></p><p class=MsoPlainText>I've revised the agenda with a little more explanation. You shouldn’t read too much into my examples below for the kinds of things we’ll talk about. Often they’re given just to help explain the general topic. As I mentioned on the call today, this agenda is open to revision.<o:p></o:p></p><p class=MsoPlainText>Ben<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal><b>WORKING GROUPS<o:p></o:p></b></p><p class=MsoNormal>1:30 9:10 10:40 1 <b>RFC 3647 Conversion Group</b> <o:p></o:p></p><p class=MsoNormal>1:30 10:40 12:10 2 <b>SSL Performance Working Group</b>: Certificate Profile Best Practices for Speed (without compromising on security) <o:p></o:p></p><p class=MsoNormal>2:20 12:30 14:50 3 <b>Code Signing Working Group</b> <o:p></o:p></p><p class=MsoNormal>2:10 15:00 17:10 4 <b>Extended Validation Revisions Working Group </b><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><b>DAY 1 - (Wed) 19 February 2014 <o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 9:10 9:40 5 <b>Browser News </b><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:50 9:40 10:30 6 <b>SHA1 Sunsetting / Grandfathering Strategy:</b> Microsoft has indicated that it will stop accepting SHA-1 certificates on January 1, 2017, which means that CAs must deal now with customers who are used to buying 3-year SHA1 certificates. Support for Windows XP ends April 8th, which is one of the reasons why SHA1 certificates have still been needed. Are there other reasons why customers will still need SHA1 certificates? Appendix A of the Baseline Requirements currently states, "*SHA-1 MAY be used with RSA keys until SHA-256 is supported widely by browsers used by a substantial portion of relying-parties worldwide." What does that mean? Do the Baseline Requirements need to be amended? If so, what is the CABF's strategy for sunsetting SHA1 gracefully? Should the CABF adopt a rule similar to Microsoft's SHA1 deprecation policy? What systems are out there that will choke without SHA1 and should they be grandfathered with language such as we have in sections 9.4.1 and 12 of the Baseline Requirements?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 10:45 11:15 7 <b>SSL Performance WG report</b> <o:p></o:p></p><p class=MsoNormal>0:30 11:15 11:45 8 <b>RFC 3647 Working Group report</b> <o:p></o:p></p><p class=MsoNormal>0:20 11:45 12:05 9 <b>Code Signing Working Group report</b> <o:p></o:p></p><p class=MsoNormal>0:20 13:00 13:20 10 <b>EV Guideline Working Group report</b> <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 13:20 13:50 11 <b>Review and discuss technical constraints for Delegated Third Parties:</b> A "Delegated Third Party" is "not the CA but is authorized by the CA to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein." One type of Delegated Third Party is the "Enterprise RA", which is "technically constrained" due to the fact that its Subject FQDN must be within its registered domain namespace. Other types of delegations may exist, and the degree to which these operations fit within the CA's audit framework may vary, depending on the degree to which such external operations are technically constrained or effectively controlled by technical measures implemented by the CA. Technical constraints have been used in the past to argue for exemptions from cost-prohibitive on-site auditing of delegated third parties. Risk can also be mitigated by certificate processing measures implemented by browsers--such as critical name constraints, restricting trust anchors by purpose (SSL, etc.) or geography, enforcing/requiring EKUs in intermediate CAs, processing policy OIDs, etc. This agenda item is to discuss current technical methods to prevent risk caused by third party security breach or potential certificate mis-issuance due to the mistakes of delegated third parties.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 13:50 14:30 12 <b>Review Network and Certificate System Security</b>: The CABF's Network and Certificate System Security Requirements were adopted in 2012. WebTrust has expressed concern that some CAs in browser root programs may not be able to meet WebTrust's interpretation / implementation of the Network Security Requirements. Are any provisions too specific? Currently the Network Security requirements are not integrated into the WebTrust audit criteria. ETSI indicates that they have already been incorporated into TS 102 042. What further work should we do, if any, to translate them into acceptable audit criteria? <o:p></o:p></p><p class=MsoNormal>Beyond review of the current Network and Certificate System Security Requirements, are we ready to look at issues that we put on the back burner when we adopted version 1.0? What about the concepts set forth in NISTIR 7924, which will be released again this year for another comment period?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 14:40 15:20 13 <b>Webtrust for CAs</b>: Don Sheehy and Jeffrey Ward will review current status of Web Trust audit criteria for CAs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 15:20 15:50 14 <b>EV Verification Tasks</b>: Richard Wang of Wosign asked a question about EV requirements and tasks performed by attorneys, accountants, local registration authorities, site visit companies, etc.. We'll discuss this topic to understand his question better and provide clarification, if possible.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 15:50 16:20 15 <b>Current status of WPKOPS, client and server capabilities</b>: We'll discuss preliminary information from the WPKOPS survey from Mozilla and CloudFlare's nginx/openssl responses, information about servers from https://wiki.mozilla.org/Security/Server_Side_TLS, client capabilities information gathered during previous meetings, etc., about server and client support of different algorithms, ciphersuites, chain processing, revocation checking mechanisms, etc.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 16:20 17:00 16 <b>Coordinating Certificate standards with other organizations</b>: Various trading communities and educational, research, and governmental organizations desire interoperability of their systems with the WebPKI (i.e. publicly trusted SSL). Examples include the International Grid Trust Federation, the US Federal PKI, and others. These organizations often have their own certificate requirements, and certificate policy OIDs. Section 8.4 of the BRs is the only place where the "Trust Model" is addressed. It states, a "CA SHALL disclose all Cross Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross Certificate at issue)." CAs that want to provide "dual trust" for servers that operate in two communities sometimes encounter technical questions that require flexibility or clarification of rules/technical standards. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As one example of this dichotomy, how should RFC 5280 or the CABF BRs be applied to an end entity certificate or intermediate CA when the trust anchor in one environment is different than, due to cross certification, the trust anchor or bridge in the other congruent environment? If Policy OIDs vary up and down the chain (they should only be removed as you go down, not added), and browser software does not process policy OIDs in accordance with RFC 5280, how does the CABF address this situation in a way that is flexible but follows good security / technical practice? Is coordination or some form of agreement or guidance from the Forum desirable in these situations? Is better coordination with these types of outside policy groups needed?"<o:p></o:p></p><p class=MsoNormal><b><o:p> </o:p></b></p><p class=MsoNormal><b>DAY 2 - (Thur) 20 February 2014 <o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>1:20 9:00 10:20 17 <b>CT and Google Requirements Discussion:</b> Google to discuss current plans for implementation of Certificate Transparency and root program participation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 10:30 11:10 18 <b>ETSI Presentation</b>: Iņigo Barreira and Arno Fiedler will review status of ETSI's trust service provider assessment criteria and proposed European regulation. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 11:10 11:50 19 <b>Compliance assessment coordination with auditors and browsers:</b> Representatives of CAs, Browsers, and Audit Frameworks will review implementation of CABF guidelines in audit criteria and incorporation into Browser Root Program requirements.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>1:20 12:30 13:50 20 <b>Bylaws Revisions:</b> At the last face-to-face meeting, we resolved to add the following membership categories in the CABF bylaws: Associate Members (formerly known as Observers) and specify that they are invited parties who sign the IPR and have access to wiki and management lists and can attend meetings but cannot vote; Invited Guests, who per the chair's discretion may attend F2F meetings that are local, either as guest speakers or attendees without signing the IPR policy and have no mailing list or wiki access; and Interested Parties, who want to participate in working groups only but must sign the IPR agreement and are added to each working group mailing list with posting privileges.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 14:00 14:40 21 <b>What is an SSL Certificate?</b>: "Should the Baseline Requirements be written to prohibit the use of the ""anyEKU"" EKU and require use of the TLS Server EKU? <o:p></o:p></p><p class=MsoNormal>The Baseline Requirements seek to prohibit “Internal Server Names,” which are defined as “[names] not resolvable using the public DNS.” It has been argued that the Baseline Requirements address anything under a public root, but there are certificates under public roots that will not work as SSL certificates, so are there situations when the Baseline Requirements don’t apply to certificates not intended for public use? Can certain certificate profiles (such as those with an EKU other than TLS server/client) be considered exempt because they are not or cannot be used by people with browsers to connect to a web site? See CABF Minutes of 5 September 2013 and https://cabforum.org/pipermail/public/2013-August/002126.html ; https://cabforum.org/pipermail/public/2013-August/002127.html; and that same discussion thread, which started here: https://cabforum.org/pipermail/public/2013-July/001947.html. <o:p></o:p></p><p class=MsoNormal>We might use this time to also work on the Baseline Requirements definition of “Internal Server Name” for Ballot 112."<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 14:40 15:20 22 <b>Review implementation status of OSCP stapling and multi-stapling (RFC 6961)</b>: Discuss OCSP stapling support and efforts toward supporting RFC 6961 multi-stapling (nginx, Apache, Microsoft, Mozilla, etc.). What percent of current servers, sites, clients, etc., could immediately benefit from stapling? Eventually from multi-stapling? What is the current deployment for OCSP stapling? Where can we obtain the greatest return on efforts?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:40 15:20 16:00 23 <b>New gTLDs Processing and Public Suffix List</b>: Section 11.1.4 of the Baseline Requirements requires CAs to review their issued certificates within 30 days of new gTLD approval and not issue a Certificate with that Domain Name until it confirms control of that name by its customer, and within 120 days CAs are required to revoke such certificates unless the Subscriber controls the Domain Name. Are there ways to automate this? Are there ways to simplify the process or revoke / replace certificates sooner? (i.e. are any amendments to section 11.1.4 needed?) For instance, if the Public Suffix List (PSL) is updated on gTLD approval, could the PSL mechanism be used to determine what is and isn't allowed? If the PSL is a complete map of the public namespace, could it be used by CAs in some automated fashion? <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 16:00 16:30 24 <b>Discuss F2F Meeting 33 in Beijing</b>: Richard Wang of Wosign<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>0:30 16:30 17:00 25 <b>Review accomplishments / list of tasks </b><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] On Behalf Of Gervase Markham<br>Sent: Tuesday, February 11, 2014 4:43 AM<br>To: ben@digicert.com; public@cabforum.org<br>Subject: Re: [cabfpub] Updated Draft Agenda for F2F Meeting 31</p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Hi Ben,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Can you clue me in about some of these items?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>On 10/02/14 21:59, Ben Wilson wrote:<o:p></o:p></p><p class=MsoPlainText>> 0:30 13:20 13:50 11 Review and discuss<o:p></o:p></p><p class=MsoPlainText>> technical constraints for Delegated Third Parties<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>What is the topic here exactly?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> 0:40 13:50 14:30 12 Review Network and<o:p></o:p></p><p class=MsoPlainText>> Certificate System Security<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Is this a general review of the entire "Network and Certificate System Security Requirements" doc, or targetted. If targetted, what particular changes are proposed?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> 0:40 11:10 11:50 19 Compliance assessment<o:p></o:p></p><p class=MsoPlainText>> coordination with auditors and browsers<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>What is the topic here exactly?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Thanks :-)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Gerv<o:p></o:p></p><p class=MsoPlainText>_______________________________________________<o:p></o:p></p><p class=MsoPlainText>Public mailing list<o:p></o:p></p><p class=MsoPlainText><a href="mailto:Public@cabforum.org"><span style='color:windowtext;text-decoration:none'>Public@cabforum.org</span></a><o:p></o:p></p><p class=MsoPlainText><a href="https://cabforum.org/mailman/listinfo/public"><span style='color:windowtext;text-decoration:none'>https://cabforum.org/mailman/listinfo/public</span></a><o:p></o:p></p></div></body></html>