CABForum Baseline Requirements: Public Comment period
Gervase Markham
"Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates" document. Please see http://cabforum.org/
for details (I hope that press release will soon have its own dedicated
URL).
The document itself is here:
http://cabforum.org/Baseline_Requirements_Draft_30b.pdf
Mozilla offered this discussion forum to the CAB Forum to host the
public discussion, and they have accepted our offer. The review period
continues until the end of May.
Please note that this document has been in production for the last two
years. While the public discussion comes at a time when certificate
issuance is under the spotlight, the CAB Forum feels that the timely
adoption of the existing guidelines should not be jeopardized by the
need for extended discussion of what actions to take in response to
particular recent events.
As the release puts it:
"CA and browser members of the CAB Forum acknowledge that the current
version lacks provisions in some key areas, and they anticipate working
in the coming months to overcome these deficiencies. Nevertheless, they
see great value in adopting and enforcing an initial version covering
those areas where agreement has already been achieved. For this reason,
the CAB Forum welcomes well-thought-out, constructive improvements to
the current draft. Proposals for more far-reaching changes will be
considered. However, proposals that may significantly hold-up the
adoption of common requirements for the industry must await a future
revision."
Colloquially, "a bird in the hand is worth two in the bush".
Therefore, please understand that proposals for significant additions to
the requirements may be deferred until next time.
Please post your comments as a new thread, rather than as a comment to
this message!
Gerv
Gervase Markham
> Please post your comments as a new thread, rather than as a comment to
> this message!
Further to this, please note the request in the press release
<http://cabforum.org/> for subject line tagging of comments. Feel free
to split your comments into multiple threads based on the area commented
upon.
Gerv
Stephen Schultze
I'm going to respond directly to this post because it pertains to the
process.
Although I think that it is commendable that the CAB Forum is seeking
public input, I think that the initial posture of the CAB Forum is
significantly less helpful than it could be. They are either open to
public examination and change or not. The notion that they are willing
to make only small adjustments works against true public participation.
The notion that "we'll fix it further down the line" is what led to
the PKIX mess we're in today.
Take, for instance, the existing WebTrust guidelines. The version that
everyone uses today is still the first version ever created more than 10
years ago, which was envisioned as an initial document to be updated but
never was. This is the same document that has a gaping hole in RA
authority... because they preferred a "bird in the hand."
"Fn. 5: As indicated herein, during development of this document, the
AICPA/CICA Electronic Commerce Assurance Task Force considered the
situations in which subscriber registration is performed by the
certification authority (CA) itself or by external registration
authorities (RAs). This document has been written such that the RA
function may be "carved out" or considered outside the scope of the
WebTrust for certification authorities examination when registration
activities are performed by parties external to the CA. For the purpose
of some end users, this approach may not address all requirements for
the independent verification of such end users. The Task Force was aware
of this situation and concluded that the issuance and use of this
document was desirable and that the impact of a third-party registration
function was beyond the scope of this document."
Eddy Nigg
> I'm going to respond directly to this post because it pertains to the
> process.
>
> Although I think that it is commendable that the CAB Forum is seeking
> public input, I think that the initial posture of the CAB Forum is
> significantly less helpful than it could be. They are either open to
> public examination and change or not. The notion that they are
> willing to make only small adjustments works against true public
> participation. The notion that "we'll fix it further down the line"
> is what led to the PKIX mess we're in today.
Not really - let me explain what the considerations were. First of all
the CAB Forum considered what you suggested, but we decided to go ahead
as noted. It took more than two years to get consensus for the proposed
guidelines and we simply didn't wanted to delay this first step
significantly longer.
In the end the CAB Forum agreed that it would be more beneficial to
forge ahead with the guidelines as is and consider public comments in
the next version - this is a work in progress and by no means finished.
But we have to start somewhere and this is also in my opinion the most
important thing.
The EV guidelines have been revised and updated multiple times, so will
the Basic Guidelines too. So for now we don't expect any changes to the
proposal but rather urge support for it by the software vendors. Further
down the road the CAB Forum will work will publish an updated version, a
process that in fact already started.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Ben Wilson
If anyone has constructive comments, I'm sure the CAB Forum and everyone
else on this list would like to hear them. I think the intent is that the
discussion be carefully structured in a way that leads to implementable
requirements that are worded in the appropriate language used by standards
organizations and the assessors who determine compliance. The reason for
structure is so that the commentary can be efficiently captured and
processed by the drafters. Comments that are of better quality are more
likely to be adopted and implemented because they are easier for the
drafters to take and incorporate into the standard. As noted, the suggested
Subject Lines are extensible as long as they follow the numbering used in
the current outline:
BRi-Notices
BR1 -Scope
BR2 -Purpose
BR3 -References
BR4 -Definitions
BR5 -Abbreviations
BR6 -Conventions
BR7 -Warranties & Representations
BR8 -Community & Applicability
BR9 -Certificate Content & Profiles
BR10 -Certificate Application
BR11 -Validation Practices
BR12 -Certificate Status Checking & Revocation
BR13 -Employees & Third Parties
BR13.2 -Deleg. of Functions & Compliance Oblig
BR14 -Data Records
BR15 -Data Security -
BR15 -Data Security -Malware protection
BR15 -Data Security -Out-of-band confirmation
BR16 -Audit Requirements
BR17 -Liability & Indemnification
BR18 -Privacy & Confidentiality
BRA -Algorithm & Key Sizes
BRB -Certificate Extensions
BRC-User Agent Verification
BR-New-________ (for areas of discussion that you do not believe have been
adequately accommodated in the existing outline)
I disagree with Stephen's assessment of the CAB Forum's "initial posture"
and the assertion that "they" are not open to "public examination" and
change or that "they" are only willing to make "small adjustments" as the
antithesis of "public participation." This isn't directed at Stephen, but
at everyone who finds it easier to sit in front of a monitor and criticize
without having to structure language and comments in ways that reasonably
and unambiguously express a solution to their concern. The reason for the
CAB Forum's initial posture is to set expectations about how much can be
done. Just like the software development process, sometimes it is better to
get version 1.0 out and postpone an improvement for a future release. One
thing you may not have caught in the announcement is that members of the CAB
Forum are continuing to work in parallel on improving future versions of the
Baseline Requirements (e.g., to address RA issues), even while we are
receiving public comment on this draft version.
So, after first reading the draft, if anyone would like to fully address an
area of concern and feels that it has not been covered in the outline above,
he or she may comment using the BR-New-________ subject line (in which case,
also please recommend the two sections between which the new section heading
would appear). Finally, you'll notice that the lines and pages are
numbered--so if you have a single word or punctuation change and you don't
want to bother the rest of the list with it, please send an email to
"ques...@cabforum.org" and the correction will be made in the working
draft.
Ben Wilson, DigiCert
(Unofficial Co-Rapporteur, with Tim Moses, Entrust)
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digie...@lists.mozilla.org] On
Behalf Of Stephen Schultzec
Sent: Tuesday, April 12, 2011 8:48 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: CABForum Baseline Requirements: Public Comment period
On 4/12/11 7:32 AM, Gervase Markham wrote:
I'm going to respond directly to this post because it pertains to the
process.
Although I think that it is commendable that the CAB Forum is seeking
public input, I think that the initial posture of the CAB Forum is
significantly less helpful than it could be. They are either open to
public examination and change or not. The notion that they are willing
to make only small adjustments works against true public participation.
The notion that "we'll fix it further down the line" is what led to
the PKIX mess we're in today.
Take, for instance, the existing WebTrust guidelines. The version that
everyone uses today is still the first version ever created more than 10
years ago, which was envisioned as an initial document to be updated but
never was. This is the same document that has a gaping hole in RA
authority... because they preferred a "bird in the hand."
"Fn. 5: As indicated herein, during development of this document, the
AICPA/CICA Electronic Commerce Assurance Task Force considered the
situations in which subscriber registration is performed by the
certification authority (CA) itself or by external registration
authorities (RAs). This document has been written such that the RA
function may be "carved out" or considered outside the scope of the
WebTrust for certification authorities examination when registration
activities are performed by parties external to the CA. For the purpose
of some end users, this approach may not address all requirements for
the independent verification of such end users. The Task Force was aware
of this situation and concluded that the issuance and use of this
document was desirable and that the impact of a third-party registration
function was beyond the scope of this document."
http://www.webtrust.org/homepage-documents/item27839.aspx
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Steve Schultze
> I disagree with Stephen's assessment of the CAB Forum's "initial posture"
> and the assertion that "they" are not open to "public examination" and
> change or that "they" are only willing to make "small adjustments" as the
> antithesis of "public participation." This isn't directed at Stephen, but
> at everyone who finds it easier to sit in front of a monitor and criticize
> without having to structure language and comments in ways that reasonably
> and unambiguously express a solution to their concern. The reason for the
> CAB Forum's initial posture is to set expectations about how much can be
> done. Just like the software development process, sometimes it is better to
> get version 1.0 out and postpone an improvement for a future release.
If this is the actual outcome of the process, I applaud it. You can
understand my skepticism given the failure of WebTrust to update *their*
baseline requirements at all after version 1.0. I recognize that CAB
Forum has done considerably better in their EV process.
I most certainly agree that constructive suggestions are more productive
than mere criticism (and they are forthcoming). I want to emphasize
that such suggestions should be heard and acted on in a reasonable
fashion. The initial posture of limiting the public's changes to the
initial draft, and soliciting input for less than two months when the
rest of the conversation on the draft has been going on for two years,
was troubling.
Go ahead and prove my concerns unwarranted. :)