[cabfcert_policy] WG Charter, Scope, Deliverables and Project Plan-Minutes and planned face to face mtg

Thu Jan 8 07:24:26 MST 2015

I’ll be there.  My ticket is booked.

Robin

From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Dean Coclin
Sent: 06 January 2015 17:35
To: Ben Wilson; Bruce Morton; 'policyreview at cabforum.org'; Tim Hollebeek
Subject: Re: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan-Minutes and planned face to face mtg

The confirmed date is Tuesday, Jan 27th

Dean

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Tuesday, January 06, 2015 11:46 AM
To: Bruce Morton; Dean Coclin; 'policyreview at cabforum.org'; Tim
Hollebeek
Subject: RE: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan-Minutes and planned face to face mtg

I’m ticketing my flight today, so it would be good to know.  

From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Bruce Morton
Sent: Tuesday, January 6, 2015 9:12 AM
To: Dean Coclin; 'policyreview at cabforum.org'
Subject: Re: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan-Minutes and planned face to face mtg

Dean,

Is 28 January the confirmed date?

Thanks, Bruce.

From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Dean Coclin
Sent: Wednesday, December 10, 2014 8:13 PM
To: Ben Wilson; 'policyreview at cabforum.org'
Subject: Re: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan-Minutes and planned face to face mtg

Tim Hollebeek asked for the 28th rather than the 27th.  Tim- could you
make it work on the 27th due to Ben’s conflict below?

Thanks
Dean

From: Ben Wilson [mailto:ben.wilson at digicert.com] 
Sent: Wednesday, December 10, 2014 4:40 PM
To: Dean Coclin; 'policyreview at cabforum.org'
Subject: RE: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan-Minutes and planned face to face mtg

Dean,

There is an IDESG Plenary Meeting in Atlanta, January 28-30, if we can
work around that.

Thanks,

Ben

From: Dean Coclin [mailto:Dean_Coclin at symantec.com] 
Sent: Thursday, December 4, 2014 8:51 AM
To: Ben Wilson; 'policyreview at cabforum.org'
Subject: RE: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan-Minutes and planned face to face mtg

Minutes: Dec 4, 2014

Attendees: Bruce, Dean Robin

On today’s call we discussed if we should move Task 3 ahead of Task 1.
There was discussion about the benefits of moving to the RFC format and
further research was needed. 

I suggested that in order to make significant progress, we need to meet
face to face. I offered to host everyone in my office outside of Boston
on Jan 27th or 28th (the week that Robin is in the US). I think we could
use the day to work together and subdivide, where appropriate, the tasks
into manageable chunks. 

How do others feel about doing that? Are the dates/location workable?

Thanks,
Dean 

From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Wednesday, November 19, 2014 5:17 PM
To: 'policyreview at cabforum.org'
Subject: Re: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan

Here is another resource to consider under Task 1 – it’s the Cloud
Security Alliance’s Control Matrix -
https://cloudsecurityalliance.org/download/cloud-controls-matrix-v3/ 

From: policyreview-bounces at cabforum.org
[mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Monday, November 10, 2014 1:20 PM
To: 'policyreview at cabforum.org'
Subject: Re: [cabfcert_policy] WG Charter, Scope, Deliverables and
Project Plan

Task 1 - consider existing and proposed standards (CABF, WebTrust, ETSI,
ISO, X9.79, NIST IR 7924, IETF, ITU, etc. (see link below))

Task 2 – create a list of potential improvements based on a review of
the above

Task 3 – Evaluate a transition to 3647 format based on the amount of
work needed (i.e. complexity that will accrue)

Task 4 – Prepare a list of topics to be discussed by the Forum

Task 5 – Prepare ballots that will improve the CA infrastructure based
on existing standards

Task 6 -  Prepare a recommendation on whether to convert to 3647

So, the 3647 conversion does appear to be a final determination after we
have done these other tasks, for which using rfc3647 headings as a “key”
might help keep our discussions and comparisons organized.  Alternatives
for the organization “key” for these topics include:  WebTrust, ETSI,
NIST 800-53,  ISO 27000, COSO/COBIT, etc – see
http://www.unifiedcompliance.com/matrices-protected/ebooks/soc_users/ind
ex_Left.htm#CSHID=Introduction%2FThe_major_frameworks_used_for_establish
ing_IT_controls.htm|StartTopic=Content%2FIntroduction%2FThe_major_framew
orks_used_for_establishing_IT_controls.htm 

From: Ben Wilson 
Sent: Friday, November 7, 2014 8:37 AM
To: 'policyreview at cabforum.org'
Subject: 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/20150108/46fbff11/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5857 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20150108/46fbff11/attachment-0001.bin 