Below are a few things I’ve seen.  I’m happy to put my name to them, so I’m 
posting to the public list:

1) Offline CAs are treated the same as online CAs.  For example, a system for 
CA that is based on HSMs stored in safes theoretically needs individual user 
logins with multi-factor access control.  For systems where the HSMs has multi 
person access control, this is highly redundant.

2) Root CAs are not required to be air gapped at all times.

3) The scope is far larger than probably intended — it could be viewed as being 
as far reaching as including CDNs used to distribute CRLs and OCSP responses 
which have no ability to generate or modify the responses and systems the relay 
emails to domain contacts which are outside of the CA system

4) The segmentation requirements are confusing (and possibly contradictory): 
networks or zones based on their functional, logical, and physical (including 
location) relationship

5) It assumes passwords are the core authentication credential and does not 
align with current NIST guidance.  Authentication requirements could probably 
be put in terms of NIST SP 800-63 AAL.

6) It fails to define “multi-factor authentication”

7) It fails to define “remote” (used as part of “remote administration or 
access”); Is remote anything other then using a keyboard and monitor physically 
attached to the system motherboard?

8) Certificate Management System and Security Support System definitions are 
both very broad.  At least one interpretation prevents usage of any system 
accessible to persons who are not in Trusted Roles, even if such usage is not 
critical to system security. For example, the CA might have a corporate policy 
to send logs to a central log server in addition to CA specific log servers.  
It is not clear this is allowed.

9) It has no concept of compensating controls; for example, a CA might want to 
implement channel authentication as an alternative to physical network 
segmentation (for example using TLS over VLANs rather than physically 
segmenting LANs).

The list goes on, but this should be a good start.

Thanks,
Peter

> On Jun 9, 2017, at 2:29 PM, Kirk Hall via Public <[email protected]> wrote:
> 
> Yes, we have also noticed “90 days” versus quarterly – Most quarters have 
> more than 90 days.
>  
> Thanks.
>  
> From: Dean Coclin [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: Friday, June 9, 2017 2:09 PM
> To: CA/Browser Forum Public Discussion List <[email protected] 
> <mailto:[email protected]>>
> Cc: Kirk Hall <[email protected] 
> <mailto:[email protected]>>
> Subject: [EXTERNAL]Re: [cabfpub] Send us you list of current problems with 
> the Network Security Guidelines
>  
> One specific complaint from the auditors I believe was the specific time 
> requirements in the document. For example, if it said you have to change the 
> password at 90 days, and you did it on day 91, it would be an audit failure. 
> I think Don has better examples but that's one I recall. 
> 
> Sent from my iPhone
> 
> On Jun 9, 2017, at 4:35 PM, Kirk Hall via Public <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> Bruce and I want to collect a preliminary list of current problems with the 
> Network Security Guidelines (technically, the Network and Certificate System 
> Security Requirements), so we can have a good discussion of possible new 
> directions at the upcoming F2F.
>  
> To that end – please send Bruce and me a list of the specific requirements 
> (and/or definitions) in the NetSec requirements that you think are most 
> problematic and which should be changed or dropped.  If possible, give us the 
> following data for each problematic issue:
>  
> 1.       Section or definition of the NetSec Requirements that creates the 
> problem
> 2.       What is the problem?
> 3.       What is a possible solution (drop, amend, supplement), with 
> suggested language.
>  
> Bruce and I will combine all suggestions received and report anonymously to 
> the whole group for a discussion in Berlin.  That may give the new Working 
> Group some useful guidance for its ongoing work after that.
>  
> Thanks.
> <Network_Security_Controls_V1.pdf>
> _______________________________________________
> Public mailing list
> [email protected] <mailto:[email protected]>
> https://clicktime.symantec.com/a/1/f8a6ATZl_MnLwe29_m42V-mYnSdtACxRZX0POAv19Vo=?d=Yz3SpbucMfHwCGRoOuzLmlu9Wpr_caTWy3ILlB_IoLHc8KA0wZ9ZIIE0tt6_40GuyUeYNqwIwidNiKaKMu-5OhJUpI-0YmfQlXF6WVerqU-ErugytgRRUvyO4rzY8NCkhG397tCFH2roGFp5G4M7Xr7HurgCIsLKvk_CMVy_W33a8G7xs-zP44TZmNNnklelkmp9rYeMxGizl_l43PaLWEPq3okEBqK1ZLhxicxRW5Q-DJpP7uamThvBEDxql9A4GfwEQidWB4-Z4LlFYTHzdzZ1KHdONbJspvsEhltqHQiSSKHqcjPVfopD6S_b1Il_kJ7UeffHCM2fbGuZM3-ATtW4erUTkCsgco80th_9K1GTEs0Ligy4OOIZyCqOKL88l3ZOGCvzMBdsibgW7vTwBA2LhcZdTn_Nqiq7Lfh2iJXO2hDVk8yYzplKWu7J_J7XdsTZJuufN_61qCXKBjZC5VS3fw%3D%3D&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic
>  
> <https://clicktime.symantec.com/a/1/f8a6ATZl_MnLwe29_m42V-mYnSdtACxRZX0POAv19Vo=?d=Yz3SpbucMfHwCGRoOuzLmlu9Wpr_caTWy3ILlB_IoLHc8KA0wZ9ZIIE0tt6_40GuyUeYNqwIwidNiKaKMu-5OhJUpI-0YmfQlXF6WVerqU-ErugytgRRUvyO4rzY8NCkhG397tCFH2roGFp5G4M7Xr7HurgCIsLKvk_CMVy_W33a8G7xs-zP44TZmNNnklelkmp9rYeMxGizl_l43PaLWEPq3okEBqK1ZLhxicxRW5Q-DJpP7uamThvBEDxql9A4GfwEQidWB4-Z4LlFYTHzdzZ1KHdONbJspvsEhltqHQiSSKHqcjPVfopD6S_b1Il_kJ7UeffHCM2fbGuZM3-ATtW4erUTkCsgco80th_9K1GTEs0Ligy4OOIZyCqOKL88l3ZOGCvzMBdsibgW7vTwBA2LhcZdTn_Nqiq7Lfh2iJXO2hDVk8yYzplKWu7J_J7XdsTZJuufN_61qCXKBjZC5VS3fw%3D%3D&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic>_______________________________________________
> Public mailing list
> [email protected] <mailto:[email protected]>
> https://cabforum.org/mailman/listinfo/public 
> <https://cabforum.org/mailman/listinfo/public>
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to