[cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

[Ben Wilson]

Just a thought, for what it's worth.  I'd rather keep audit compliance and ballot drafting simple and only state, "the CA shall maintain a record of which domain validation method they used to validate every domain."  Doesn't that implicitly encompass tracking the BR version number?  Can't we leave it up to CAs to choose a tracking method without over-proscribing?  Otherwise I anticipate an auditor coming in and asking to look at my database to confirm that I've listed every BR version number with which the validation performed complied.

Ben


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Monday, August 14, 2017 8:54 AM
To: Wayne Thayer <wthayer at godaddy.com>; Ben Wilson <ben.wilson at digicert.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>; Kirk Hall <Kirk.Hall at entrustdatacard.com>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

On 01/08/17 22:58, Wayne Thayer wrote:
> This led me to propose a version number embedded in section 3.2.2.4 of 
> the BRs that covers either all validation methods or one for each 
> method – it doesn’t matter to me.

I can see the value and clarity of this approach. I would prefer that there be one version number per method. (Just as individual ACME methods are versioned; same idea.)

I agree that semantically one can achieve the same result by recording the BR version number one is following, although one then needs to do some textual comparisons to see whether CA Foo using method 3.2.2.4.6 as of BRs 1.7.8 is actually using the same method as CA Bar using method
3.2.2.4.6 from BRs 1.8.3, or not.

The question is whether there is a sufficient additional clarity advantage in this system to make it worth implementing.

Gerv
-------------- 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/20170814/fbfcab4e/attachment-0003.p7s>