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

[Ben Wilson]

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/20141107/d41f10c8/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4998 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20141107/d41f10c8/attachment-0001.bin