[cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework

[kirk_hall at trendmicro.com]

Ben, out of curiosity – did the Working Group consider simply making cross reference tables correlating the current BRs (and EVGL) and the RFC 3647 CPS framework?  So that if a browser wanted to see which BR sections were relevant to a CPS in RFC 3647 format (and vice versa), they could just consult the table?

It seems that would have been a simpler approach, and would recognize that a lot of the BRs are not relevant to a CA’s CPS or CPS format.

From: Ben Wilson [mailto:ben.wilson at digicert.com]
Sent: Wednesday, February 25, 2015 8:16 AM
To: i-barreira at izenpe.net; Kirk Hall (RD-US); Dean_Coclin at symantec.com; public at cabforum.org
Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework

Iñigo,
The Working Group did consider your previous comments during its deliberations.  We’re willing to help out in whatever way we can with transitioning the necessary cross-references in ETSI documents to the new section numbers.  Once this has been accomplished, though, I don’t’ think we’ll be doing this kind of moving sections around again.
Ben

From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net]
Sent: Wednesday, February 25, 2015 12:55 AM
To: kirk_hall at trendmicro.com; Dean_Coclin at symantec.com; Ben Wilson; public at cabforum.org
Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework

This is something that I complained time ago basically due to the timing needed to adopt the EN, which is not the same than the TS.
BTW, ETSI also mandates that the CP/CPS shall be structured according to the RFC 3647


Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net<mailto:i-barreira at izenpe.net>
945067705

[Descripción: cid:image001.png at 01CE3152.B4804EB0]
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: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] En nombre de kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Enviado el: martes, 24 de febrero de 2015 18:56
Para: Dean Coclin; Ben Wilson; CABFPub
Asunto: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC3647 Framework

Fair point, but here is another consideration.  Right now, all the WebTrust (and ETSI?) documents are laid out more or less in the same order as the current BRs and EVGL, and include references to the current numbering.  If all numbering is changed, they will have to amend the WebTrust (and ETSI?) internal references – maybe not a big deal – but the order of the WebTrust requirements will no longer correspond to the order of the BRs.

From: Dean Coclin [mailto:Dean_Coclin at symantec.com]<mailto:[mailto:Dean_Coclin at symantec.com]>
Sent: Tuesday, February 24, 2015 8:59 AM
To: Kirk Hall (RD-US); Ben Wilson; CABFPub
Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

Some of the beneficiaries are Browser root programs and relying parties. Having the BRs in this format makes it easier for Jody, Kathleen and others to review CPS’ and compare to the sections in the BRs for compliance.

Jeremy has already taken a pass at doing this and a draft has been circulated.

Dean

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org]<mailto:[mailto:public-bounces at cabforum.org]> On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Tuesday, February 24, 2015 11:52 AM
To: Ben Wilson; CABFPub
Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

Ben – first of all, thanks for the hard work on this one.

I’m trying to figure out the benefit of locking the Forum into the RFC 3647 framework for the purpose of listing BR requirements.  Is there really a benefit?  Does it add to understanding and make CA compliance any easier?  Or will it force us to put rules in odd places that actually make understanding a bit harder?

I note the BR 8.2 already requires CAs to put their CPS into the format of RFC 2527 or 3647.  See the first two sections of BR 8.2 below.  That can facilitate comparison between the CPSs of different CAs, if anyone cares to do that.  But is there any corresponding benefit from restructuring the BRs to an RFC 3647 format?  What if a rule spans two or more different sections of the RFC 3647 format?

I see that in your new organization of the BRs you have moved old BR 8.2.2 to a new Section 2.1 Repositories, not to new Section 2.2 Publication of Information.  How did you make that choice?  And is there an expectation that CAs will publish their CAA disclosure in new Sec. 2.2 of their CPS?

I’m just afraid we will be handcuffing ourselves with these changes, and that there could be errors in internal cross-references.  It is also a lot of work for everyone to review a complete rewrite of the BRs.

Can you give us a convincing argument of why this is worth doing?  Sorry I didn’t ask this question earlier, but I hadn’t really understood this was what the working group was doing – I thought you were just looking for GAPS in the BRs as compared to the RFC 3647 where we could ADD new provisions to the BRs – not a wholesale restructuring of the BRs.

Thanks.

BR 8.2.2 Disclosure
The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an
appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose
its CA business practices to the extent required by the CA’s selected audit scheme (see Section 17.1). The
disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in
accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA's Certificate
Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state
whether the CA reviews CAA Records, and if so, the CA’s policy or practice on processing CAA Records for Fully
Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice.

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Tuesday, February 24, 2015 7:22 AM
To: CABFPub
Subject: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework
The Certificate Policy Review Working Group was chartered by Ballot 128 to (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 [of work involved]. One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014.
The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that merely moves existing content from the Baseline Requirements and the Network and Certificate System Security Requirements into the RFC 3647 format.
Attached is an RFC-3647-formatted Certificate Policy for Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Comments embedded in the document contain either the source of the text (for content copied from the Baseline Requirements) or the current text (for provisions incorporated by reference from the Network and Certificate System Security Requirements ("NetSec"). It was decided that it was better to incorporate the NetSec requirements by reference rather than copying and pasting them in. In some limited instances the phrase "these Requirements" has been replaced with "this CP." However, "these Requirements" is mostly left in to preserve consistency with the current Baseline Requirements.
Ben Wilson of DigiCert made the following motion, from and from have endorsed it.
Motion Begins
Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Certificate Policy v.1.2.5, effective immediately.
Motion Ends
The review period for this ballot shall commence at 2200 UTC on March 2015 and will close at 2200 UTC on March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on March 2015.
Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ‘yes’ in the response. A vote against the ballot must indicate a clear ‘no’ in the response. A vote to abstain must indicate a clear ‘abstain’ in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted.
Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members– at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid.




TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential

and may be subject to copyright or other intellectual property protection.

If you are not the intended recipient, you are not authorized to use or

disclose this information, and we request that you notify us by reply mail or

telephone and delete the original message from your mail system.






TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential

and may be subject to copyright or other intellectual property protection.

If you are not the intended recipient, you are not authorized to use or

disclose this information, and we request that you notify us by reply mail or

telephone and delete the original message from your mail system.




<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150225/ee092f2e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150225/ee092f2e/attachment-0003.png>