[cabf_netsec] Threat model approach for "Root CA System"

[Ben Wilson]

I hope your sub-group has been able to make some progress.  I fear that
trying to enumerate the threats and risks might take us in the direction of
"boiling the ocean".  Hopefully you've been able to narrow the scope of
discussion.  (One approach to narrow the scope that we used before was the
DigiNotar incident.  We used DigiNotar as the model on which to write up the
NCSSRs.)


-----Original Message-----
From: Netsec [mailto:netsec-bounces at cabforum.org] On Behalf Of Dimitris
Zacharopoulos via Netsec
Sent: Friday, September 22, 2017 8:12 AM
To: CA/Browser Forum Network Security WG List <netsec at cabforum.org>
Subject: [cabf_netsec] Threat model approach for "Root CA System"


Dear NetSec WG members,

In yesterday's WG meeting, we introduced the idea of approaching the "Root
CA System" in a "threat model" way and see how that turns out. The
justification behind trying this approach is that the current Network
Security Requirements include some very specific security requirements and
controls but don't actually describe what are the threats they try to
prevent from happening or which vulnerabilities they try to mitigate. 
Also, defining a reasonable "security perimeter" for a "Root CA System" 
is a challenge and each CA might see it in a number of ways. Knowing what we
want to protect against can help CAs better define this "security
perimeter".

If we list specific threats and vulnerabilities, even obvious ones, then we
can try to map the current NSR controls to these risks and see if they do a
reasonable job in 2017. If they don't, we will try improving or replacing
existing controls or even add new ones so that the "Root CA System" is
"reasonably" protected. As we all know, there is no 100% security but
"reasonably" for a Root CA System should be pretty close to that! We'll also
try to talk about what threats we will explicitly not try to defend against!

As a note from yesterday's meeting, this threat-model approach might end up
with different requirements to what CAs are currently being audited against.
This shouldn't work as a deterrent for improving the security of these
systems and once this process matures, there will be adequate time for CAs
to adapt to the updated security requirements.

If anyone is interested in working with such an approach, please join me,
Neil Dunbar (TrustCor) and Tom Ritter (Mozilla) by sending me a private
e-mail. We will work independently and present our work to the NetSec WG so
the same IPR policy applies.

If this approach improves the Network Security Requirements update process,
we might expand it to other concepts of the Network Security Requirements
like the "Certificate Issuing System", maybe introduce a separate
"Registration and enrollment System", we'll see.


Best regards,
Dimitris.


_______________________________________________
Netsec mailing list
Netsec at cabforum.org
http://cabforum.org/mailman/listinfo/netsec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20171002/3fea059d/attachment.p7s>