I’ll probably do both. That way if things do collide, I can discard the commit(s) that gets collided with, and regenerate it/them from the bulleted list. It saves me work on the most likely path (no collisions).
-Tim From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, May 4, 2018 1:06 PM To: Tim Hollebeek <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] Spring Cleanup Ballot 2019 Then I think it would be good to simply keep a bulleted list of ideas (of which every bit I just gave applies), but worry about the specific language and wording changes closer to an actual ballot, to avoid the unfortunately not-uncommon situation of a 'fix' overwriting other corrections in that area. In short, anything that says "Replace all of" or "Delete all of" more than a few weeks of being a ballot makes me rather nervous :) On Fri, May 4, 2018 at 11:45 AM, Tim Hollebeek <[email protected] <mailto:[email protected]> > wrote: Yes, I’m really planning a year out. From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ] Sent: Friday, May 4, 2018 11:06 AM To: Tim Hollebeek <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] Spring Cleanup Ballot 2019 On Fri, May 4, 2018 at 10:52 AM, Tim Hollebeek via Public <[email protected] <mailto:[email protected]> > wrote: Any objections if the Spring Cleanup branch includes cleanup changes involving dates that will be true in Spring of 2019? I'm not sure what you're proposing here - was that a typo from 2018 to 2019? Or are you really planning a year out? :) If you really meant 2019, then I think it's unwise to start planning those sorts of changes so far ahead, given the unfortunate tendency to forget to continually update and ensure semantic consistency with any other changes the Forum may have made in the interim. For example, removing the definition of Domain Authorization Document, and changing 3.2.2.4.5 to read: “3.2.2.4.5 Domain Authorization Document This method has been retired and MUST NOT be used. Completed validations using this method SHALL NOT be used for the issuance of certificates.” Did you mean to include 3.2.2.4.1 if including 3.2.2.4.5? Otherwise, these are both August 2018 - not Spring 2018 (which supports the Spring 2019 theory). If you're going 2019, then you'd also need to be touching 4.2.1 - for consistency. There are similar changes that could be made in 2.2: “The Certificate Policy and/or Certification Practice Statement MUST: 1. be structured in accordance with RFC 3647, 2. include all material required by RFC 3647, 3. state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA’s CAA policy or practice MUST: 1. be consistent with these Requirements, 2. clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue The CA SHALL log all actions taken, if any, consistent with its processing practice.” Where we don’t have to worry about RFC 2527 any longer. So, that's a Spring 2018 thing (specifically, May 2018). And if you're cleaning up for 2018, it's not clear if you were intending to touch the following paragraph (regarding September 2017) or not. If you're going a Spring 2018 route, then you'd want to be touching 6.3.2, 3.2.2.8, 7.1.3, 7.1, 7.1.4.2.1, 3.2.2.6, 4.9.10, 6.1.5, 8 (the implementors note), and the definition of "Effective Date"
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
