[cabfpub] Cert Policy Working Group activity

[Dean Coclin]

Thanks Ryan.  The group is interested in hearing what these objections might 
be so if you can be ready to discuss these at or before the F2F it would be 
appreciated.





From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, September 15, 2015 3:56 PM
To: Dean Coclin
Cc: richard.smith at comodo.com; Gervase Markham; public at cabforum.org
Subject: Re: [cabfpub] Cert Policy Working Group activity







On Tue, Sep 15, 2015 at 12:39 PM, Dean Coclin <Dean_Coclin at symantec.com> 
wrote:

The comments essentially break down into 2 types:
1. Insuring that any new language added is reviewed and perhaps balloted by
the entire forum (comments from Bruce, Rick, Kirk)
2. Determining whether the network security guidelines should be merged
(Gerv's comment)



Apologies that silence may be seen as no feelings, but Google definitely 
agrees with Gerv regarding a preference for non-integration.



During the Google-hosted Mountain View F2F in February of last year, I 
highlighted several of the practical concerns and problems with these 
documents. While the adoption of the documents within the CA/B Forum was 
handled via Ballot 83 ( 
https://cabforum.org/2012/08/03/ballot-83-adopt-network-and-certificate-system-security-requirements/ ) 
, the requirements themselves are problematic for a variety of reasons, though 
well-intentioned.



As Gerv suggested, I owe the Forum a more detailed write-up of these concerns 
if we are going to treat them as "Good". The non-adoption/non-requirement by 
root programs, at the time, left me largely ambivalent as to the need or 
importance of communicating these, but the unfortunate integration into both 
ETSI and the WebTrust guidelines perhaps makes this a more necessary function.



Regardless of their integration status in audits, they're not something we 
(Google) expect CAs to follow, and have been growing concerned with their 
interpretation and application, preventing what we view as more secure ways of 
managing networks from being explored.



In the interim, it would be quite beneficial to these aims to NOT integrate 
the NetSec requirements, and to take advantage of the opportunities presented 
in #1, which as we discussed during the Zurich F2F, there is more than enough 
ample opportunity to improve things. For example, the Policy WG could consider 
some of the recent Policy Reviews that have occurred on the 
mozilla.dev.security.policy mailing list ( 
https://groups.google.com/forum/#!forum/mozilla.dev.security.policy ) 
regarding issues with the structure and quality of CP/CPS for applicants and 
renewals within the Mozilla Root Program as points that the Forum may provide 
appropriate guidance on.



Example policy reviews:

* SECOM - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/LRLkWliCIec/EAGOTubkFwAJ

* WISeKey - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/U_uy68U7E7o/PIM9tFTdGAAJ

* SSC - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ

* LuxTrust - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ

* Certinomis - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/B44zk_YO9zE/lyfaXpVXP4MJ



Many of these concerns I echo'd during the Policy WG discussions, but perhaps 
this provides a more convenient venue for member CAs and for members of the 
Policy WG to consider.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150916/b728ea29/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150916/b728ea29/attachment-0001.p7s>