[cabfcert_policy] WG Charter, Scope, Deliverables and Project Plan
Ben Wilson
ben.wilson at digicert.com
Tue Nov 25 10:26:01 MST 2014
Agreed. I think we might need to shift gears, taking into account the
discussions weve had over the past two years. As youll recall, I think it
was during one of the meetings in California, we talked about not looking at
sections 1-4 of the RFC 3647 framework (which include identity validation)
and focusing instead on a comparison of provisions in sections 5
(Management, Operational, and Physical Control) and 6 (Technical Security
Controls). Can we all agree that a review of items within the scope of
those two sections is what well limit ourselves to?
From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net]
Sent: Tuesday, November 25, 2014 4:03 AM
To: Ben Wilson; policyreview at cabforum.org
Subject: RE: [cabfcert_policy] WG Charter, Scope, Deliverables and Project
Plan
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 <mailto: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>
[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 lets 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 isnt available yet, wed 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 Dons 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 NISTs reference CP). [In his email of 7-Nov-2013, Iñigo also
indicated that adopting NISTs 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 cant 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 dont have ours in that outline. It will also help us to identify gaps
in the BRs and EV Guidelines where we havent 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 NISTs CP with the BRs.
o The first phase is not to make any changes in the language but to move
the language over. Ive 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
havent 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: Its 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: Thats a good idea. Lets 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. Ill need to fill in the missing sections, and there are a lot, but
Ill send around the EV one first because I want to make sure that everyone
is on board with what Id done before and if it is then Ill 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 dont 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 its 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 CABFs 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 havent addressed, and put those items into
the CABFs 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: Thats where we left it. What does the big group think?
o One idea is that if we want to follow some sort of framework, its 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 arent doing, because Jeremy says
were 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 CAs 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 were 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 CPthere are places where we dont
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, were
going to try not to create crazy password rules, etc.well 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ñigos chart identifies. Ben said
that because Iñigos chart only covers the upper level of an outline, such
as 6.5, one might infer that there isnt 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
well have to be careful in our initial review.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20141125/4fb6158b/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 19121 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20141125/4fb6158b/attachment-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20141125/4fb6158b/attachment-0001.bin
More information about the Policyreview
mailing list