[cabfpub] Ballot 107 - removing version numbers to WebTrust and ETSI standards from CABF Guidelines

Fri Jul 26 17:53:45 UTC 2013

Hi Kirk.

No I can't think of anything and see it's more from the level playing field aspect than a major flaw in the system. 

Thanks as I'm a little clearer now.

Sent from my iPhone

On 26 Jul 2013, at 18:16, "kirk_hall at trendmicro.com" <kirk_hall at trendmicro.com> wrote:

> Part of the problem Don and I are trying to address is when a change to BRs, etc. actually becomes “legally” effective as to all CAs.  The BRs had an effective date of 7/1/2012, but not all CAs implemented the changes as of that date, and no CA was expected by any browser to follow the BRs until Mozilla imposed an audit effective date of mid-February, 2013.
>  
> The other problem we are addressing is trying to sync up when WebTrust and ETSI begin auditing for a given requirement – right now, the dates are totally disparate.
>  
> Do you see any disadvantage to trying to create a cycle for incorporation of BR and EVGL changes into the WebTrust and ETSI standards?  I can’t think of any.
>  
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Steve Roylance
> Sent: Friday, July 26, 2013 9:57 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Ballot 107 - removing version numbers to WebTrust and ETSI standards from CABF Guidelines
>  
> Hi all
>  
> On the back of Kirk's 2nd point and apologies if this was covered in a face to face meeting discussion, but what happens when any requirement (from anywhere, root program, BR, EV, market pressure) becomes necessary for a CA to implement?  I would guess that CAs incorporates it into their internal policies and where appropriate external policy (CP or CPS).,  So in actual fact, does it really matter when audit guidelines are published to auditors?   I would have thought this true for inclusions as well as exclusions to processes as the job of the auditor is to access your policy/process in conjunction with their guidelines but also based on your published documents, therefore if there is a difference and you have valid reasons to be different then you should still pass.  i.e. all interactions are not linked to any particular time frame other than the timeframe of the audit.
>  
> Thanks for any enlightenment on a Friday afternoon as to why we are concerned with this level of alignment..
>  
> Steve
>  
>  
> From: "kirk_hall at trendmicro.com" <kirk_hall at trendmicro.com>
> Date: Friday, 26 July 2013 17:32
> To: Mads Egil Henriksveen <Mads.Henriksveen at buypass.no>, "public at cabforum.org" <public at cabforum.org>
> Subject: Re: [cabfpub] Ballot 107 - removing version numbers to WebTrust and ETSI standards from CABF Guidelines
>  
> Mads, if you need another endorser for Ballot 107, Trend Micro will endorse.
>  
> Don Sheehy and I will also be working on a “calendar cycle” proposal to present to the Forum that will guide us in how we incorporate changes to the BRs , EVGL, etc. into WebTrust and ETSI audit requirements on a regular basis.  We hope to present that to the Forum for discussion in August.
>  
> Kirk
>  
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Mads Egil Henriksveen
> Sent: Wednesday, July 24, 2013 1:32 AM
> To: public at cabforum.org
> Subject: [cabfpub] Ballot 107 - removing version numbers to WebTrust and ETSI standards from CABF Guidelines
>  
> Hi
>  
> During our discussion on coordinating audit and standards cycle in Munich, I suggested to remove the version numbers in CABF Guidelines to specific WebTrust and ETSI version numbers as this creates a circularand inconsistent result.
>  
> This ballot removes the version numbers from EV Guidelines and the Baseline Requirements (BR).
>  
> I have included some additional changes which I consider reasonable; The ETSI TS 102 042 comprises seven different set of policy requirements for different types of certificates, both SSL and non-SSL certificates. I have included the specific CPs for SSL certificates explicitly in the references to TS 102 042 where this is relevant. The following CPs are referenced; Domain Validation (DVCP), Organizational Validation (OVCP), Extended Validation (EVCP) and enhanced Extended Validation (EVCP+).
>  
> I have also deleted some links to explicit documents on the web. Such document links might change, and the interested reader will find the document anyway.
>  
> I am also looking for a second endorser for this motion.
>  
> Find redlined versions of relevant sections from EV Guidelines and Baseline Requirements attached.
>  
> Regards
> Mads
>  
>  
> Ballot 107 – Removing version numbers to WebTrust and ETSI standards from CABF Guidelines (EVG and BR)
>  
> Mads Henriksveen made the following motion, and Ben Wilson from DigiCert and _______ from _______ endorsed it:
>  
> Motion Begins
>  
> Baseline Requirements (BR)
>  
> Document History
>  
> Implementers’ Note: Version 1.1 of these SSL Baseline Requirements was published on September 14, 2012. Version 1.1 of WebTrust’s SSL Baseline Audit Criteria and ETSI Technical Standard Electronic Signatures and Infrastructures (ESI) 102 042 version 2.3.1 incorporate version 1.1 of these Baseline Requirements and are currently in effect. See http://www.webtrust.org/homepage-documents/item27839.aspxand also http://www.etsi.org/deliver/etsi_ts/102000_102099/102042/02.03.01_60/ts_102042v020301p.pdf.
>  
> Section 3. References
>  
> ETSI Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - General Requirements and Guidance, available at: http://www.etsi.org/deliver/etsi_ts/119400_119499/119403/01.01.01_60/ts_119403v010101p.pdf.
>  
> ETSI TS 102 042 V2.1.1,Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates.
>  
> WebTrust Program for Certification Authorities Version 2.0, available at http://www.webtrust.org/homepage-documents/item27839.aspx.
>  
> Section 17.1 Eligible Audit Schemes
>  
> The CA SHALL undergo an audit in accordance with one of the following schemes:
> 1. WebTrust Program for Certification Authorities v2.0 audit;
> 2. A national scheme that audits conformance toETSI TS 102 042 audit including DVCP, OVCP, EVCP or EVCP+;
> 3. A scheme that audits conformance to ISO 21188:2006; or
> 4. If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either (a) encompasses all requirements
>  
> EV Guidelines(EVG)
>  
> Section 8.2.1 Implementation
>  
> (B) Implement the requirements of (i) the then-current WebTrust Program for CAs, and (ii) the then-current WebTrust EV Program or (ii) the then-current ETSI TS 102 042 EV Certificate Policies (EVCP or EVCP+) V2.1.1; and
>  
> Section 8.2.2 Disclosure
>  
> Each CA MUST publicly disclose their EV Policies through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA is also REQUIRED to publicly disclose its CA business practices as required by both WebTrust for CAs and ETSI TS 102 042 V2.1.1. The disclosures MUST be structured in accordance with either RFC 2527 or RFC 3647.
>  
> Section 17.1 Eligible Audit Schemes
>  
> A CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes:
> (i) WebTrust Program for Certification Authorites audit and WebTrust EV Program audit, or
> (ii) ETSI TS 102 042 v2.1.1 audit including EVCP or EVCP+.
>  
> Section 17.4 Pre-Issuance Readiness Audit
>  
> (2) If the CA has a currently valid ETSI 102 042 audit, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI TS 102 042 V2.1.1 EVCP or EVCP+.
> (3) If the CA does not have a currently valid WebTrust Seal of Assurance for CAs or an ETSI 102 042 audit, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete either: (i) a point-in-time readiness assessment audit against the WebTrust for CA Program, or (ii) a point-in-time readiness assessment audit against the WebTrust EV Program, or an ETSI TS 102 042 V2.1.1. audit including EVCP or EVCP+.
>  
> The review period for this ballot shall commence on July 24th, 2013 and will close on July 31, 2013. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at August 7th, 2013. Votes must be cast by posting an on-list reply to this thread.
> 
> Motion Ends
> A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against 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: http://www.cabforum.org/forum.html In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and one half or more of the votes cast by members in the browser category must be in favor. Also, at least seven members must participate in the ballot, either by voting in favor, voting against, or abstaining.
> 
>  
>  
> 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.
> _______________________________________________ Public mailing list Public at cabforum.org https://cabforum.org/mailman/listinfo/public
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130726/68418559/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4041 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130726/68418559/attachment-0001.p7s>