[cabfpub] Baseline Requirements "Certificate Policy" for the Issuance and Management of Publicly-Trusted Certificates

[Ben Wilson]

I’d support removing the words “Certificate Policy” from the document title, if that is the request,  but I am fine with whatever the group decides.

 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith via Public
Sent: Wednesday, June 21, 2017 5:51 PM
To: 'Ryan Sleevi' <sleevi at google.com>; 'Gervase Markham' <gerv at mozilla.org>
Cc: Rich Smith <richard.smith at comodo.com>; 'CA/Browser Forum Public Discussion List' <public at cabforum.org>
Subject: Re: [cabfpub] Baseline Requirements "Certificate Policy" for the Issuance and Management of Publicly-Trusted Certificates

 

Should we put this forth as a ballot?  Anyone who might have reason that we should go the other way can bring it up in the discussion period.

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, June 21, 2017 9:30 AM
To: Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org> >
Cc: Rich Smith <richard.smith at comodo.com <mailto:richard.smith at comodo.com> >; CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
Subject: Re: [cabfpub] Baseline Requirements "Certificate Policy" for the Issuance and Management of Publicly-Trusted Certificates

 

As it stands, http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf and http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.01.01_60/en_31941102v020101p.pdf both note

 

"Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates"

 

That is, the pre-1.3.0 language, even though they're based on and incorporate post-1.3.0 versions.

 

https://cabforum.org/2015/04/16/ballot-146-convert-baseline-requirements-to-rfc-3647-framework/ as text notes "Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.3.0, effective upon adoption."

 

On the basis of this data, and in the lack of evidence to the contrary, it certainly would appear that changing the title of the document to reflect its historic, pre-1.3.0 naming, has _less_ impact both to the BRs and consumers than it does to suggest changing Section 2.2.

 

Of course, if others are aware of evidence to the contrary, this would be useful to provide. But this is why I was highlighting that whether or not external documents were updated to refer to the 'new' language (in which case, changing 2.2 is the path of least resistance) or 'old' language (as, it turns out, they are), can affect the cost evaluation of the different proposals.

 

Hopefully that's at least an objective reason to "change the title back to what it was" :)

 

 

On Wed, Jun 21, 2017 at 9:39 AM, Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org> > wrote:

On 21/06/17 15:36, Rich Smith wrote:
> If I’m not mistaken, Gerv is saying, rather than update a bunch of text
> in other places, how about changing the name back to /Baseline
> Requirements for the Issuance and Management of Publicly-Trusted
> Certificates/.
>
> Gerv, if that is correct, I second the motion.

That was my suggestion. 2 caveats, though: Ryan pointed out offlist that
the name may be referenced elsewhere, and so it might be more work to
change to something new than to standardize on what the cover page
currently says. And also, presumably we added the words "Certificate
Policy" to the name for a reason; we shouldn't remove them without
knowing what that reason was.

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Gerv

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170622/74a9fd64/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170622/74a9fd64/attachment-0003.p7s>