<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Gerv,</div><div class=""><br class=""></div>Regarding question (1) below, we would be adamantly opposed to such a change to the IPR policy, for at least the following reasons:<div class=""><br class=""></div><div class="">1. Such a change would be contrary to one of the stated objectives of the CAB Forum, which is to make sure members have all available information about essential claims and licensing terms <u class="">before</u> voting on changes to the Guidelines.</div><div class=""><br class=""></div><div class="">2. Members implementing Guidelines before the IP review period is complete would be at risk of IP infringement, and could have to undo all the implementation work done during the IP review period if an exclusion notice is filed. Because of this risk, many members would wait until the IP review period was complete and the ballot was approved before implementing anyway.</div><div class=""><br class=""></div><div class="">If a member desires to accept the risk of IP infringement and start implementing before the IP review is complete, that is a decision that member should make with their own counsel. However, this should be an individual member’s choice, and should not be forced on all members by the process.</div><div class=""><div class=""><br class=""></div><div class=""><font color="#006d8f" class="">1) IPR process. Is there any appetite in the Forum for changing the IPR<br class="">rules to allow post-vote review (and, if the review turns up something,<br class="">having the ballot be put in abeyance) rather than the current pre-vote<br class="">review? I feel this would make the work of the Forum proceed much faster<br class="">(as IPR review can happen in parallel with CAs preparing to implement<br class="">the change), and it optimises for the common case, which is that no IPR<br class="">declarations are filed.<br class=""><br class="">This could be discussed in the IPR WG but perhaps it would be better<br class="">discussed in the whole forum to see if there was sufficient interest in<br class="">making this change. Perhaps members could consult their legal counsel<br class="">before the meeting to see what issues this might raise and how they<br class="">could be solved.</font><br class=""><div class=""><br class="">Best regards,<br class=""><br class="">Virginia Fournier<br class="">Senior Standards Counsel<br class=""> Apple Inc.<br class="">☏ 669-227-9595<br class="">✉︎ <a href="mailto:vmf@apple.com" class="">vmf@apple.com</a><br class=""><br class=""><br class=""><br class=""><br class=""></div><br class="">On Oct 3, 2016, at 7:26 AM, <a href="mailto:public-request@cabforum.org" class="">public-request@cabforum.org</a> wrote:<br class=""><br class="">Send Public mailing list submissions to<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:public@cabforum.org" class="">public@cabforum.org</a><br class=""><br class="">To subscribe or unsubscribe via the World Wide Web, visit<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://cabforum.org/mailman/listinfo/public<br class="">or, via email, send a message with subject or body 'help' to<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public-request@cabforum.org<br class=""><br class="">You can reach the person managing the list at<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public-owner@cabforum.org<br class=""><br class="">When replying, please edit your Subject line so it is more specific<br class="">than "Re: Contents of Public digest..."<br class=""><br class=""><br class="">Today's Topics:<br class=""><br class=""> 1. Re: Potential F2F Topics (Gervase Markham)<br class=""> 2. Re: Potential F2F Topics (Gervase Markham)<br class=""> 3. Re: SHA-1 exception request (Dean Coclin)<br class=""><br class=""><br class="">----------------------------------------------------------------------<br class=""><br class="">Message: 1<br class="">Date: Mon, 3 Oct 2016 15:05:27 +0100<br class="">From: Gervase Markham <gerv@mozilla.org><br class="">Subject: Re: [cabfpub] Potential F2F Topics<br class="">To: Peter Bowen <pzb@amzn.com>, CABFPub <public@cabforum.org><br class="">Message-ID: <406ac402-f657-2e70-535f-b2c585d7587d@mozilla.org><br class="">Content-Type: text/plain; charset=utf-8<br class=""><br class="">On 01/10/16 17:00, Peter Bowen wrote:<br class=""><blockquote type="cite" class="">The Network and Certificate Systems Security Requirements (NCSSR)<br class="">were discussed at the last F2F but it was kind of dropped. What<br class="">challenges are CAs finding? Are there places where they are not<br class="">clear or where they can be interpreted to ban practices the Forum<br class="">feels are appropriate? As they are a separate document from the BRs,<br class="">do trust store maintainers expect that all CAs (whether for SSL or<br class="">not) are audited as meeting the requirements or do they only apply to<br class="">?SSL? CAs?<br class=""></blockquote><br class="">Mozilla's current view on this document is that we are not convinced<br class="">that the CAB Forum is the right body to be maintaining a document with<br class="">these contents. We feel network security is very important, but best<br class="">practices change much faster than the document has.<br class=""><br class="">If anyone wanted to take up the task, we would support replacing it with<br class="">references to guides maintained by better-qualified parties.<br class=""><br class="">Gerv<br class=""><br class=""><br class="">------------------------------<br class=""><br class="">Message: 2<br class="">Date: Mon, 3 Oct 2016 15:26:23 +0100<br class="">From: Gervase Markham <gerv@mozilla.org><br class="">Subject: Re: [cabfpub] Potential F2F Topics<br class="">To: CABFPub <public@cabforum.org><br class="">Message-ID: <f054cc0e-a46f-4e11-7cc5-16e18725c2b3@mozilla.org><br class="">Content-Type: text/plain; charset=utf-8<br class=""><br class="">On 01/10/16 17:00, Peter Bowen wrote:<br class=""><blockquote type="cite" class="">I haven?t seen much recent activity on topics for the F2F. It looks<br class="">like we still have most of the second day with placeholders to be<br class="">filled in.<br class=""></blockquote><br class="">I would like to discuss the following topics:<br class=""><br class="">1) IPR process. Is there any appetite in the Forum for changing the IPR<br class="">rules to allow post-vote review (and, if the review turns up something,<br class="">having the ballot be put in abeyance) rather than the current pre-vote<br class="">review? I feel this would make the work of the Forum proceed much faster<br class="">(as IPR review can happen in parallel with CAs preparing to implement<br class="">the change), and it optimises for the common case, which is that no IPR<br class="">declarations are filed.<br class=""><br class="">This could be discussed in the IPR WG but perhaps it would be better<br class="">discussed in the whole forum to see if there was sufficient interest in<br class="">making this change. Perhaps members could consult their legal counsel<br class="">before the meeting to see what issues this might raise and how they<br class="">could be solved.<br class=""><br class="">2) CAA. Again. I think that we need to get to a place where we decide to<br class="">have a ballot on CAA, and it should be the ballot with the greatest<br class="">chance of passing. If it fails, it fails, but at the moment we just keep<br class="">revisiting the issue and having to have the discussion again from<br class="">scratch. So I'd like to have some time with the explicit goal of working<br class="">out what form of CAA ballot is most likely to command the support of the<br class="">forum. (TBH, if only 20 sites in the Alexa top 1M are using it, I doubt<br class="">any CA should worry that it will end up being a restraint of trade!)<br class=""><br class="">3) I'd like to hear from Google if they have any update on the timing of<br class="">their plans for requiring CT in other parts of the ecosystem. As they<br class="">are the ones running a large proportion of the servers, and whose<br class="">browser has the most advanced implementation, we expect them to be the<br class="">first to make such a requirement. I'd also, for my own interest, love to<br class="">hear about their and others' experiences running CT logs, how difficult<br class="">it has proved to be in practice to run one with 99%+ uptime, whether<br class="">people are meeting various performance criteria and so on.<br class=""><br class=""><br class="">Of course, saying I'd like these matters discussed doesn't necessarily<br class="">mean I'm the right person to be responsible for the discussion. I'd be<br class="">happy to lead 1), but 2) and 3) would be someone else.<br class=""><br class="">It's good that we now have an established practice of nominating<br class="">discussion leaders for each slot. It would be good if the discussion<br class="">leader for each slot could, _before_ we assemble, state in a couple of<br class="">sentences what the goal of that slot is. If the chairman could perhaps<br class="">try and elicit such statements from the relevant people, I feel sure<br class="">that would enhance our efficiency.<br class=""><br class="">I would also note that there is currently an item on the agenda<br class="">"Potential change to browser UI for Subject DN". It is a long-accepted<br class="">truth that the CAB Forum does not place requirements on browser UI. It<br class="">may be worth making that clear again now, so that we can use that time<br class="">for other items.<br class=""><br class="">Gerv<br class=""><br class=""><br class=""><br class="">------------------------------<br class=""><br class="">Message: 3<br class="">Date: Mon, 3 Oct 2016 14:26:47 +0000<br class="">From: Dean Coclin <Dean_Coclin@symantec.com><br class="">Subject: Re: [cabfpub] SHA-1 exception request<br class="">To: Gervase Markham <gerv@mozilla.org>, CABFPub <public@cabforum.org><br class="">Cc: "Halliday, Morgan" <Morgan.Halliday@firstdata.com>, "Sidoriak,<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Evan S" <Evan.Sidoriak@firstdata.com><br class="">Message-ID:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><BY2PR16MB01524CBE2A017082B20A8349FAC20@BY2PR16MB0152.namprd16.prod.outlook.com><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class="">Content-Type: text/plain; charset="utf-8"<br class=""><br class="">Gerv,<br class="">I am posting responses on behalf of First Data below. Symantec has also answered the 2 questions indicated:<br class=""><br class=""><br class="">* The answer to question 3 is not complete, in that it does not explain whether alternative measures such as issuing from a pulled root have been tried and if so, what the outcome was, and if not, why not.<br class=""><br class="">FD Response: We tested a private root and determined that this would not work for all affected clients.<br class="">Modern POS systems would not have the pulled root and would need to manually add the private root. <br class="">The level of effort involved would be similar to if not greater than just upgrading or replacing Non SHA-2 compliant devices. <br class=""><br class="">FD verified that POS devices do perform expiration checking and will fail if expired SHA-1 certificates are in use. <br class=""><br class="">Changing the clock on the POS devices will not work. PCI compliance mandates that POS clocks are synchronized. <br class=""><br class="">Given the size and diversity of the POS device population there are no pulled roots that would remediate a significant portion of the 300,000 clients at risk. <br class=""><br class="">* It seems pretty amazing that, given that this company was not unaware of the relevant deadlines that they only bothered in August 2016 to check and see how effective their attempts at getting the ecosystem to upgrade were.<br class=""><br class="">FD Response: FD initially communicated a June 30th deadline which would have provide a four month buffer before final expiry of existing certificates. <br class=""><br class="">Several large merchants and banks working on remediation plans through efforts such as contacting clients, upgrading POS software and/or deploying new compliant POS hardware requested that we extend the deadline to August 1st, which we did. <br class=""><br class="">We had to wait until our August deadline had passed to evaluate client readiness in order to avoid impacting clients who were in the process of becoming compliant. <br class=""><br class="">As stated in the response to question #8 ?Additional steps in the future would be to conduct readiness tests much farther in advance.? We would definitely consider this a lesson learned and will be moving our internal deadlines up much further in the future. <br class=""><br class="">* This seems not to be a case of "we didn't know" or "we weren't told"<br class="">by First Data, but a case of "we were told but we didn't listen" by First Data's community of software vendors, VARs and gateway providers.<br class="">This makes me less sympathetic - either these companies have failed to communicate to their customers the importance of the impending deadline, or the customers have simply ignored the communications. And they have no-one to blame but themselves.<br class=""><br class="">FD Response: There are valid circumstances that would prevent communications from reaching the end user. <br class=""><br class="">Most of these clients are small merchants with limited IT industry knowledge. Many of them have bought/sold their businesses, inheriting the POS device. Some have changed banking relationships. Others don?t have an active relationship with their POS vendor, or for many other reasons, may not even know who administers their POS system. <br class=""><br class="">FD believes that these businesses, which by their nature are not technically sophisticated, should not be put to experience an extended business disruption that would result from the inability to extend SHA-1 certificates for the period requested.<br class=""><br class="">Please also see the response to the last question below on efforts proposed to accelerate user compliance.<br class=""><br class=""><br class="">* Do the proposed certificates "correspond to an Existing Certificate..." as outlined in the section "Existing Certificate Information" in the procedure doc? If they do, can crt.sh links be provided for the existing certificates? If not, is that because matching certs existed but were not logged, or because other changes have been made? If the latter, can it be explained why the additional changes to the certificate contents are needed? In general, it seems that while the answers to the initial questions have been provided, the data requested by this section has not.<br class=""><br class="">Symantec: Links to the crt.sh entries were provided at the top of each certificate's disclosure in the second email. Each of the candidate toBeSigned certificates match the logged certificates they replace with the exception of the serial number and validity period. Matching was preserved to the extent of using T61String encoding, SGC EKU, and BR compliance policy OIDs from our arc rather than the CABF's.<br class=""><br class="">* The procedure doc says that validity of exceptional certificates may not extend beyond 31st December 2016. First Data is asking for 15th March 2017, which is impermissible as the doc stands. (The CAB Forum has regularly had discussions about how the end of a calendar year is a bad time for deadlines; however, in this case, the actual deadline was a year ago, so I don't think this complaint can be made in this case.)<br class=""><br class="">Symantec: Precedent exists to provide expiration dates after Jan 1, 2017. <br class=""><br class="">As was pointed out in a previous application the risk is at issuance and is not affected by validity period. See link: https://cabforum.org/pipermail/public/2016-July/008007.html <br class=""><br class="">* Given that above, I wonder whether, if the only way to make the affected retailers pay attention is if their devices actually stop working, it's best for that to happen in October/November rather than on December 31st, in the middle of the Christmas period.<br class=""><br class=""><br class="">FD Response: FD proposes an alternative that can highlight the need to address this issue without causing a sustained impact that would be more disruptive to merchant businesses. <br class=""><br class="">Beginning in the first week of October, FD is planning to conduct what we are calling ?Short Burst? upgrades. We will regularly and continually upgrade to SHA-2 for short intervals on varying dates and times of day. Non-compliant clients will be unable to process during these burst upgrade periods which should induce corrective measures. <br class=""><br class=""><br class=""><br class=""><br class="">Thanks,<br class="">Dean<br class=""><br class="">-----Original Message-----<br class="">From: Gervase Markham [mailto:gerv@mozilla.org] <br class="">Sent: Friday, September 30, 2016 4:56 AM<br class="">To: Dean Coclin <Dean_Coclin@symantec.com>; CABFPub <public@cabforum.org><br class="">Cc: Halliday, Morgan <Morgan.Halliday@firstdata.com>; Sidoriak, Evan S <Evan.Sidoriak@firstdata.com><br class="">Subject: Re: [cabfpub] SHA-1 exception request<br class=""><br class="">Hi Dean,<br class=""><br class="">On 29/09/16 19:52, Dean Coclin wrote:<br class=""><blockquote type="cite" class="">In accordance with the SHA-1 Exception Request procedure, we hereby <br class="">submit the attached request on behalf of our client.<br class=""></blockquote><br class="">I've been considering this application, with reference to https://github.com/awhalley/docs-for-comment/blob/master/SHA1RequestProcedure.MD<br class="">, which I believe is the latest version.<br class=""><br class="">* The answer to question 3 is not complete, in that it does not explain whether alternative measures such as issuing from a pulled root have been tried and if so, what the outcome was, and if not, why not.<br class=""><br class="">* It seems pretty amazing that, given that this company was not unaware of the relevant deadlines, that they only bothered in August 2016 to check and see how effective their attempts at getting the ecosystem to upgrade were.<br class=""><br class="">* This seems not to be a case of "we didn't know" or "we weren't told"<br class="">by First Data, but a case of "we were told but we didn't listen" by First Data's community of software vendors, VARs and gateway providers.<br class="">This makes me less sympathetic - either these companies have failed to communicate to their customers the importance of the impending deadline, or the customers have simply ignored the communications. And they have no-one to blame but themselves.<br class=""><br class="">* Do the proposed certificates "correspond to an Existing Certificate..." as outlined in the section "Existing Certificate Information" in the procedure doc? If they do, can crt.sh links be provided for the existing certificates? If not, is that because matching certs existed but were not logged, or because other changes have been made? If the latter, can it be explained why the additional changes to the certificate contents are needed? In general, it seems that while the answers to the initial questions have been provided, the data requested by this section has not.<br class=""><br class="">* The procedure doc says that validity of exceptional certificates may not extend beyond 31st December 2016. First Data is asking for 15th March 2017, which is impermissible as the doc stands. (The CAB Forum has regularly had discussions about how the end of a calendar year is a bad time for deadlines; however, in this case, the actual deadline was a year ago, so I don't think this complaint can be made in this case.)<br class=""><br class="">* Given that above, I wonder whether, if the only way to make the affected retailers pay attention is if their devices actually stop working, it's best for that to happen in October/November rather than on December 31st, in the middle of the Christmas period.<br class=""><br class="">Gerv<br class="">-------------- next part --------------<br class="">A non-text attachment was scrubbed...<br class="">Name: smime.p7s<br class="">Type: application/pkcs7-signature<br class="">Size: 5723 bytes<br class="">Desc: not available<br class="">Url : https://cabforum.org/pipermail/public/attachments/20161003/d2f769b5/attachment.bin <br class=""><br class="">------------------------------<br class=""><br class="">_______________________________________________<br class="">Public mailing list<br class="">Public@cabforum.org<br class="">https://cabforum.org/mailman/listinfo/public<br class=""><br class=""><br class="">End of Public Digest, Vol 54, Issue 2<br class="">*************************************<br class=""><br class=""></div></div></body></html>