[cabfpub] Public Digest, Vol 54, Issue 2

Virginia Fournier vfournier at apple.com
Mon Oct 3 17:52:55 UTC 2016


Gerv,

Regarding question (1) below, we would be adamantly opposed to such a change to the IPR policy, for at least the following reasons:

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 before voting on changes to the Guidelines.

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.

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.

1) IPR process. Is there any appetite in the Forum for changing the IPR
rules to allow post-vote review (and, if the review turns up something,
having the ballot be put in abeyance) rather than the current pre-vote
review? I feel this would make the work of the Forum proceed much faster
(as IPR review can happen in parallel with CAs preparing to implement
the change), and it optimises for the common case, which is that no IPR
declarations are filed.

This could be discussed in the IPR WG but perhaps it would be better
discussed in the whole forum to see if there was sufficient interest in
making this change. Perhaps members could consult their legal counsel
before the meeting to see what issues this might raise and how they
could be solved.

Best regards,

Virginia Fournier
Senior Standards Counsel
 Apple Inc.
☏ 669-227-9595
✉︎ vmf at apple.com





On Oct 3, 2016, at 7:26 AM, public-request at cabforum.org wrote:

Send Public mailing list submissions to
	public at cabforum.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://cabforum.org/mailman/listinfo/public
or, via email, send a message with subject or body 'help' to
	public-request at cabforum.org

You can reach the person managing the list at
	public-owner at cabforum.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Public digest..."


Today's Topics:

  1. Re: Potential F2F Topics (Gervase Markham)
  2. Re: Potential F2F Topics (Gervase Markham)
  3. Re: SHA-1 exception request (Dean Coclin)


----------------------------------------------------------------------

Message: 1
Date: Mon, 3 Oct 2016 15:05:27 +0100
From: Gervase Markham <gerv at mozilla.org>
Subject: Re: [cabfpub] Potential F2F Topics
To: Peter Bowen <pzb at amzn.com>, CABFPub <public at cabforum.org>
Message-ID: <406ac402-f657-2e70-535f-b2c585d7587d at mozilla.org>
Content-Type: text/plain; charset=utf-8

On 01/10/16 17:00, Peter Bowen wrote:
> The Network and Certificate Systems Security Requirements (NCSSR)
> were discussed at the last F2F but it was kind of dropped.  What
> challenges are CAs finding?  Are there places where they are not
> clear or where they can be interpreted to ban practices the Forum
> feels are appropriate?  As they are a separate document from the BRs,
> do trust store maintainers expect that all CAs (whether for SSL or
> not) are audited as meeting the requirements or do they only apply to
> ?SSL? CAs?

Mozilla's current view on this document is that we are not convinced
that the CAB Forum is the right body to be maintaining a document with
these contents. We feel network security is very important, but best
practices change much faster than the document has.

If anyone wanted to take up the task, we would support replacing it with
references to guides maintained by better-qualified parties.

Gerv


------------------------------

Message: 2
Date: Mon, 3 Oct 2016 15:26:23 +0100
From: Gervase Markham <gerv at mozilla.org>
Subject: Re: [cabfpub] Potential F2F Topics
To: CABFPub <public at cabforum.org>
Message-ID: <f054cc0e-a46f-4e11-7cc5-16e18725c2b3 at mozilla.org>
Content-Type: text/plain; charset=utf-8

On 01/10/16 17:00, Peter Bowen wrote:
> I haven?t seen much recent activity on topics for the F2F.  It looks
> like we still have most of the second day with placeholders to be
> filled in.

I would like to discuss the following topics:

1) IPR process. Is there any appetite in the Forum for changing the IPR
rules to allow post-vote review (and, if the review turns up something,
having the ballot be put in abeyance) rather than the current pre-vote
review? I feel this would make the work of the Forum proceed much faster
(as IPR review can happen in parallel with CAs preparing to implement
the change), and it optimises for the common case, which is that no IPR
declarations are filed.

This could be discussed in the IPR WG but perhaps it would be better
discussed in the whole forum to see if there was sufficient interest in
making this change. Perhaps members could consult their legal counsel
before the meeting to see what issues this might raise and how they
could be solved.

2) CAA. Again. I think that we need to get to a place where we decide to
have a ballot on CAA, and it should be the ballot with the greatest
chance of passing. If it fails, it fails, but at the moment we just keep
revisiting the issue and having to have the discussion again from
scratch. So I'd like to have some time with the explicit goal of working
out what form of CAA ballot is most likely to command the support of the
forum. (TBH, if only 20 sites in the Alexa top 1M are using it, I doubt
any CA should worry that it will end up being a restraint of trade!)

3) I'd like to hear from Google if they have any update on the timing of
their plans for requiring CT in other parts of the ecosystem. As they
are the ones running a large proportion of the servers, and whose
browser has the most advanced implementation, we expect them to be the
first to make such a requirement. I'd also, for my own interest, love to
hear about their and others' experiences running CT logs, how difficult
it has proved to be in practice to run one with 99%+ uptime, whether
people are meeting various performance criteria and so on.


Of course, saying I'd like these matters discussed doesn't necessarily
mean I'm the right person to be responsible for the discussion. I'd be
happy to lead 1), but 2) and 3) would be someone else.

It's good that we now have an established practice of nominating
discussion leaders for each slot. It would be good if the discussion
leader for each slot could, _before_ we assemble, state in a couple of
sentences what the goal of that slot is. If the chairman could perhaps
try and elicit such statements from the relevant people, I feel sure
that would enhance our efficiency.

I would also note that there is currently an item on the agenda
"Potential change to browser UI for Subject DN". It is a long-accepted
truth that the CAB Forum does not place requirements on browser UI. It
may be worth making that clear again now, so that we can use that time
for other items.

Gerv



------------------------------

Message: 3
Date: Mon, 3 Oct 2016 14:26:47 +0000
From: Dean Coclin <Dean_Coclin at symantec.com>
Subject: Re: [cabfpub] SHA-1 exception request
To: Gervase Markham <gerv at mozilla.org>, CABFPub <public at cabforum.org>
Cc: "Halliday, Morgan" <Morgan.Halliday at firstdata.com>, "Sidoriak,
	Evan S" <Evan.Sidoriak at firstdata.com>
Message-ID:
	<BY2PR16MB01524CBE2A017082B20A8349FAC20 at BY2PR16MB0152.namprd16.prod.outlook.com>
	
Content-Type: text/plain; charset="utf-8"

Gerv,
I am posting responses on behalf of First Data below. Symantec has also answered the 2 questions indicated:


* 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.

FD Response: We tested a private root and determined that this would not work for all affected clients.
Modern POS systems would not have the pulled root and would need to manually add the private root. 
The level of effort involved would be similar to if not greater than just upgrading or replacing Non SHA-2 compliant devices. 

FD verified that POS devices do perform expiration checking and will fail if expired SHA-1 certificates are in use. 

Changing the clock on the POS devices will not work.  PCI compliance mandates that POS clocks are synchronized. 

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. 

* 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.

FD Response: FD initially communicated a June 30th deadline which would have provide a four month buffer before final expiry of existing certificates. 

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.   

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. 

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. 

* This seems not to be a case of "we didn't know" or "we weren't told"
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.
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.

FD Response:  There are valid circumstances that would prevent communications from reaching the end user.  

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.  

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.

Please also see the response to the last question below on efforts proposed to accelerate user compliance.


* 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.

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.

* 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.)

Symantec:  Precedent exists to provide expiration dates after Jan 1, 2017.    

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   

* 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.


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.   

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.   




Thanks,
Dean

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Friday, September 30, 2016 4:56 AM
To: Dean Coclin <Dean_Coclin at symantec.com>; CABFPub <public at cabforum.org>
Cc: Halliday, Morgan <Morgan.Halliday at firstdata.com>; Sidoriak, Evan S <Evan.Sidoriak at firstdata.com>
Subject: Re: [cabfpub] SHA-1 exception request

Hi Dean,

On 29/09/16 19:52, Dean Coclin wrote:
> In accordance with the SHA-1 Exception Request procedure, we hereby 
> submit the attached request on behalf of our client.

I've been considering this application, with reference to https://github.com/awhalley/docs-for-comment/blob/master/SHA1RequestProcedure.MD
, which I believe is the latest version.

* 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.

* 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.

* This seems not to be a case of "we didn't know" or "we weren't told"
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.
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.

* 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.

* 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.)

* 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.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20161003/d2f769b5/attachment.bin 

------------------------------

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public


End of Public Digest, Vol 54, Issue 2
*************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161003/412e3735/attachment-0002.html>


More information about the Public mailing list