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:g...@mozilla.org] Sent: Monday, April 17, 2017 8:40 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public Discussion List <public@cabforum.org>; Patrick Tronnier <patrick.tronn...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public