[cabfpub] Require commonName in Root and Intermediate Certificates ballot draft (2)

[Jeremy Rowley]

Why the sigh? I think we should have a bright-line rule about when the 
scope/date should be in the proposed ballot vs. when the scope/date must be in 
the document itself.  Otherwise, the objection to including a date in the 
ballot v. BR text seems arbitrary.  If I understand correctly, the accepted 
rule proposed is:

1) The only point in time action that matters is certificate issuance;
2) If BR change exempts future certificate issuance from a requirement, the 
requirement date must be specified in the BR language; and
3) If the BR change only exempts previously issued certificates, no exception 
or requirement date should be included in the ballot or BR language.

A lot of the confusion/conflict originates on a perceived shift in the point 
of action. Previously, I've generally thought of the point of action of the 
BRs as the validation of the certificate data. Over the past year, we've 
clearly moved to certificate issuance being the point of action. This shift is 
fine, but I think it's worth explicitly stating.


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Monday, April 17, 2017 8:40 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Public 
Discussion List <public at cabforum.org>; Patrick Tronnier 
<Patrick.Tronnier at oati.net>
Subject: Re: [cabfpub] Require commonName in Root and Intermediate 
Certificates ballot draft (2)

On 17/04/17 15:28, Jeremy Rowley wrote:
> Doesn't this ballot suffer from the same limitation that Ryan raised
> in connection with the domain validation ballot? Namely, that this
> language "For the avoidance of doubt, these updated requirements apply
> only to root and intermediate certificates issued after the Effective
> Date of this ballot, which is upon approval (i.e. at the end of the
> IPR Review Period if no Exclusion Notices are filed)" needs to be part of 
> the document text?

<sigh>

I think that the plain and only sensible way to understand the BRs is that 
particular rules apply only to actions taken when those rules are in force. So 
if a motion e.g. alters the rules surrounding the issuance of intermediate 
certificates, by default the new rules apply only to issuances of intermediate 
certificates that happen after the motion fully passes (i.e. after IPR review 
is complete). Such a motion does not by default require the revocation and 
replacement of all previous intermediate certificates which do not now meet 
the updated rules.

This default can, of course, be changed by explicit wording in the motion 
which adds an instruction to the BRs to e.g. revoke all previous certs or make 
any other provision retroactive, but that's not the default.

[How does this apply to the current debate about information reuse?
Information reuse is an action. So BR rules about information reuse apply when 
you reuse information. BR rules about gathering information apply when you 
gather information. But let's not get sidetracked by that in this thread.]

Kirk was keen that the motion state this explicitly, so I added something to 
the motion to state this explicitly, "for the avoidance of doubt". However, I 
personally don't believe that there's any doubt. And I don't think we want to 
clutter up the BRs with things which basically say "this rule applies only to 
things which happen under the auspices of this document." I think that's 
obvious.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170417/5f7bdded/attachment-0001.p7s>