[cabfcert_policy] WG Charter, Scope, Deliverables and Project Plan

Tue Nov 25 04:03:08 MST 2014

BTW, I don´t know how we´re doing with this. But, have you taken into account the document I created mapping ETSI, RFC, NIST and CABF? 

The holes are because it´s been said that the main task in the CABF docs are the validation methods (EV guidelines is mainly focus on that).

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: policyreview-bounces at cabforum.org [mailto:policyreview-bounces at cabforum.org] En nombre de Ben Wilson
Enviado el: viernes, 07 de noviembre de 2014 16:37
Para: 'policyreview at cabforum.org'
Asunto: [cabfcert_policy] WG Charter, Scope, Deliverables and Project Plan

On our call yesterday we discussed the need to refine and focus on our charter, scope, deliverables and project plan.  On our website, we say, "The CA/Browser Forum has chartered a Certificate Policy Working Group to harmonize its guidelines and requirements with frameworks used by other organizations."

Ballot 128 states - Scope: The CP Review Working Group will (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount.

Deliverables: The Working Group will produce topics of discussion and proposed ballots that improve the CA infrastructure based on existing standards and documents.  The Working Group will also make a recommendation on whether to finish the 3647 conversion.

Go to Ballot 128 and let's discuss - https://cabforum.org/2014/07/09/ballot-128-cp-review-working-group/ 

For further insight, here are bits and pieces of information from our minutes that have led us to charter the working group:

·         NIST Document - The audit programs used in the past have not been strong enough to find the security weaknesses. This effort is part of an effort to push for stronger CA security practices. [Andy] said that we should all be working towards the same goal. It is his hope that a well-written set of baseline requirements in the standard RFC 3647 format will advance CA statements of policies and practices that will improve audits.

·         Dean said that since the NIST document isn't available yet, we'd be focusing just on the Network Security document and getting those requirements incorporated into the Baseline Requirements. Arno said that before we move forward on that, someone needs to perform a delta comparison on what is missing and what needs to be filled in. Ben said it would be good to have a project plan for the RFC3647 conversion project. Jeremy said that part of the project requires that we have the NIST reference CP to review and address Don's points about some of them being too prescriptive. The current plan is to transfer the BRs and EV Guidelines into the RFC 3647 framework and to fill in gaps left by NIST (and not necessarily accepting everything in NIST's reference CP). [In his email of 7-Nov-2013, Iñigo also indicated that adopting NIST's CP would be problematic and applying RFC3647 would cause serious delays to its ongoing work. ETSI has its own outline and uses RFC 3647 as an informative reference.]

·         RFC 3647 Formatting of Guidelines

o   Jeremy:  On 7 November, I sent around the BRs re-formatted to RFC 3647, and I wanted to get feedback on what everyone felt and what we should do next.  I have done this for the EV Guidelines as well, but I want to get feedback on the BRs first.

o   Kirk:  Could you remind us about why we are doing this?  I remember that we decided to do this, but I can't remember why, and it is a lot of work.

o   Jeremy:  RFC 3647 is the prescribed format for CPs and CPSs, and the Guidelines and Requirements are really CPs.  Doing so will make it easier for auditors and others to compare what is already required for CAs to do and against other industry standards written in 3647 framework, like NIST and others, and the CABF is an anomaly since requires others to do it, but we don't have ours in that outline.  It will also help us to identify gaps in the BRs and EV Guidelines where we haven't adequately described what CA practices need to be in place.  This decision was made in Turkey, after Tom made his presentation, in which he compared NIST's CP with the BRs.

o   The first phase is not to make any changes in the language but to move the language over.  I've created a spreadsheet to track the changes.  The next stage would be to reconcile the language, but I want to make sure everyone is OK with this approach before we proceed.

o   Ben:  We need feedback on this, but we also need to keep moving forward.

o   Ryan S.:  Reviewing this is high on my list of priorities, I just haven't got to it yet.  I just need to find the time among other competing projects.

o   Ben:  So how should we proceed?

o   Jeremy:  Once everyone is OK with this, we would then proceed making changes and inserting "no stipulation" where appropriate.

o   Ben:  Since we have a snapshot, we should be less concerned about moving forward because we can always go back and look at that snapshot to see how things changed.

o   Tom:  It's still a priority for me.  We should move forward carefully on this and discuss it at our next face-to-face meeting.  Microsoft has an added resource now to work on it with the February meeting as an objective.

o   Ben:  That's a good idea.  Let's everyone thoroughly review it without additionally editing it, but provide comments to it and marking it up from where it is now.

·         Minutes of 19 December  2013- Jeremy:  The first step was to create an outline for mapping and have people approve it, and now the step after that would be to revise some of the wording, and I did start that in the second draft I sent around to write it more like a CP than what we currently do.  I'll need to fill in the missing sections, and there are a lot, but I'll send around the EV one first because I want to make sure that everyone is on board with what I'd done before and if it is then I'll send around the EV one.

·         Minutes of January 2014 - Ben:  We have gone over our time on this topic, but we should look at the RFC 3647 as part of the new year.  Is there a committee so we can make progress from call to call.  We need to make progress.

o   Jeremy:  If we need to make progress, all we need is someone to review the documents.

o   Ben:  We need someone to take up the responsibility to take a look at it.

o   Ryan:  I think Tom and I committed to taking a look at it in the new year leading up to the face-to-face meeting in February.

o   Ben:  I don't want to flood the list with discussion of the RFC 3647 format, so just to keep a dialog going, maybe those interested like Tom, Ryan, Jeremy, me and others can keep this moving forward.

·         Minutes of Mountain View F2F - Jeremy: we have the format, but there are certain members who question whether it's worth pursuing due to already having our established format. CABF guidelines traditionally focused on validation (nothing else) - 90% validation.

o   It was suggested that we use sections 4-5-6 from the NIST document and put that into our guideline documents.

o   A mapping table was suggested, converting NIST and other guidance into the CABF's current language was suggested as an alternative.

o   Much of it is security related.

o   Two main takeaways: 1. Find out from broad group if we want to convert to 3647 or give up and leave alone (convert, map, or do nothing) 2. Should we create a group like the security practices group and take a look at NIST document, find things that we haven't addressed, and put those items into the CABF's format?

o   Tom: Yes.  It would be good to have a mapping between ETSI and RFC 3647.   Then we go back to the NIST document and just lift out what we want (would meet requirement).

o   Ben: That's where we left it. What does the big group think?

o   One idea is that if we want to follow some sort of framework, it's an option. RFC 3647 is not a perfect tool, but may work well for some areas. There is consistency across ETSI and NIST documents since they have a common genesis. Another approach is to take things from 3647 but try to follow mapping between Webtrust/ETSI.

o   Kirk: Are there things in 3647 we aren't doing, because Jeremy says we're trying to decide if we want to form a WG to answer that as well as for other industry standards like the NIST document.

o   Ben: If browsers want to go through a CA's CP/CPS, it helps them to have a common framework. Commonality would reduce workload.

o   Jeremy: A good argument for conversion is that it would be easier to compare CP/CPS for compliance to the BRs. There may be mistakes in CP/CPS due to oversight or mistaken interpretations.

·         March 2014 - For the time being, those working on the RFC 3647 comparison will use a mapping approach that does not force the existing CAB Forum documents into an RFC 3647 format.  

·         June 2014 F2F - We decided to form a new working group to review the NIST Reference CP, along with ETSI documents, and to integrate sections 4 through 6 into the Baseline Requirements, including security, and to consider reordering the Baseline Requirements and EV Guidelines to match the RFC 3647 format. The WG would be open to Interested Parties, and would make recommendations to the Forum on what to do.  Forum representatives who volunteered to serve on the new WG were Jeremy Rowley, Robin Alden, Ben Wilson, Moudrick Dadashov, and Dean Coclin.

·         September 2014 - CP Review Working Group: We had a call, and one of the goals/tasks that we're working on is a matrix for everything that is in the BRs and comparing it to RFC 3647 and the things that NIST had populated in the network security area of its model CP-there are places where we don't have certain things. Ben will go through and fill in those gaps with a blurb of why there is a gap and what we might do to fill it. We are going to try to make sure that they are not new and additional and unreasonable and they fit in with actual practice. Also, for things like password policies, we're going to try not to create crazy password rules, etc.-we'll be going back through the network security document.

·         Sept. 2014 F2F - The group discussed how to best align the numbering among RFC 3647, the Baseline Requirements, WebTrust and ETSI. Atilla said that alignment may not work in the end because there is not a one-to-one correspondence. Jeremy said he thinking it can be done because he already has converted the Baseline Requirements over to the RFC 3647 format. There was a question about how soon NIST IR 7924 would be available. Jeremy said he would circulate the reformatted version and that we can prioritize work on where there are gaps or holes that Iñigo's chart identifies. Ben said that because Iñigo's chart only covers the upper level of an outline, such as "6.5," one might infer that there isn't a gap, but when you go down one level (6.5.1) or two levels (6.5.1.1), it might reveal very clear gaps, so we'll have to be careful in our initial review.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20141125/5015a725/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
Url : https://cabforum.org/pipermail/policyreview/attachments/20141125/5015a725/attachment-0001.png 