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

[Dimitris Zacharopoulos]

On 17/4/2017 6:02 μμ, Ryan Sleevi via Public wrote:
>
>
> On Mon, Apr 17, 2017 at 10:40 AM, Gervase Markham via Public 
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
>     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.
>
>
> I agree with both your summary and your conclusion.
>
> The BRs represent a state of the CA's compliance at a point in time 
> with respect to what they issue. It does not govern past actions, nor 
> can it indemnify them. It can, however, require that on a particular 
> date, some action is taken - such as revoking past certificates.

When a CA is being audited for a period-in-time (say June 2016 - June 
2017), they are usually audited against an audit criteria (Webtrust or 
ETSI) that incorporate a certain version of the BRs, usually not the 
latest. If they are audited with the latest version of the BRs that 
don't take into consideration a transition phase for some cases like the 
timestamping issuance or the Intermediate CA Certificate without a CN, 
it might lead to problems.

For example, if a CA issued an Intermediate CA Certificate in August 
2016 without a CN, and the BRs were updated in May 2017, when the 
auditor comes in at the end of the audit period in June 2017 and checks 
everything against the latest BRs, they will consider the Intermediate 
CA issued in August 2016 as being mis-issued. Of course the CA can 
explain to the auditors that the BRs changed in May 2017 and enter a 
discussion with them but why shouldn't we try to avoid this?

I would also encourage adding an effective date for this ballot just as 
we did for ballot 189.


Dimitris.


>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170417/c5f7ed20/attachment-0003.html>