[cabfpub] Require commonName in Root and Intermediate Certificates ballot draft (2)
jeremy.rowley at digicert.com
Mon Apr 17 10:17:27 MST 2017
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.
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?
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4964 bytes
Desc: not available
More information about the Public