[cabf_netsec] Notes from Today's NetSec Call

[Dimitris Zacharopoulos]

On 27/4/2018 7:24 πμ, Ben Wilson via Netsec wrote:
>
> During today’s call we reviewed the terminology we’ve been using and 
> terms defined in the NCSSRs. We discussed the need for a better 
> architectural framework for CAs, an understanding of data flows, and 
> the interconnectivity among systems.
>
> We’re still looking for a better model that we can follow.
>
> Tobias noted that the way we’re trying to update the NCSSRs is really 
> tedious.  We might want to consider making bigger steps, although 
> changing from the existing NCSSRs might be too disruptive.  Should we 
> try decoupling from the existing NCSSRs?  We need a model of how to 
> operate a CA in a secure fashion and then work from there.
>
>
>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec

Sorry I missed yesterday's meeting. Making bigger steps, as historically 
demonstrated, is not an achievable goal. The NCSSRs have been used not 
just for CAs issuing SSL Certificates but for all kinds. They have been 
integrated in International audit standards (WebTrust, ETSI, who knows 
what else). I would recommend sticking to existing decisions and goals 
that were set both from the WG and from the larger Forum. We also agreed 
from the very beginning that we would try to tackle with the 
non-controversial issues first before moving to the more controversial 
ones. I don't think we are ready to handle more controversial issues 
before dealing with the non-controversial.

Just to remind everyone, it was agreed at the latest F2F that the 
_threat-based model_, presented by the sub-group for Root CA Management 
Systems as a proof-of-concept, was welcomed by everyone including 
auditors present. During that sub-group process, we had repeated 
discussions about how to operate a Root CA management system in a secure 
fashion in 2017-2018, identified threats and vulnerabilities and 
recommended compensating controls to limit the associated risks and 
impact. At some point, these compensating controls *should enter the 
NCSSRs* and revise existing, remove unnecessary or add new controls.

We have an agreed-upon roadmap which people consider effective, 
efficient and to the right direction. If WG members would like to 
explore new models, I would recommend following a similar path with the 
"threat-analysis for Root CA Management Systems" sub-group. Work in 
parallel, and if things reach a working and presentable result, bring it 
back to the larger Working Group for assessment. Then the WG could 
present it to the larger Forum at an upcoming F2F.

I will try to summarize the plan I had in mind (coming from past 
discussions/decisions) and please correct me if I miss anything.

 1. Introduction of 2FA and enforcing it for connection initiated
    outside a SZ or HSZ: Ballot 221 about the 2FA is still in the
    discussion phase.
 2. Fix as many of the ambiguous definitions and follow these principles:
     1. have simpler definitions that would cause less confusion,
     2. use Peter's suggestion for definition "quality control" by
        replacing the definition text in the requirements and see if the
        result makes sense,
     3. avoid entering Normative requirements in the definitions and
        move them in the requirements section instead of the definition
        itself.
 3. Address logging issues more specifically about integrity and
    availability,
 4. Address or at least discuss the feedback we received from the
    WebTrust Task Force on March 29th 2018 and respond with either
    clarifications or plan to address these issues,
 5. Update the NCSSRs with specific requirements for the Root CA
    Management Systems
 6. Perform a similar threat analysis for Issuing CA Management Systems
    (this is probably when we will hear about modern security and
    current best practices in Issuing CA management Systems, like we did
    with the Root CA management systems)

Of course the order could change if deemed necessary.

I hope all this makes sense. It would be nice to indicate individual 
positions in order to help determining the next steps. Let's reach to 
accomplish a couple of milestones first before radically changing course :)


Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20180427/3377f0a6/attachment-0001.html>