I do not see a good argument for including the text in the BR and a good reason not to.
One of the things that we have attempted to maintain is a separation of concerns between CABForum and IETF so that CABForum does not do protocol and IETF does not do policy. That does not mean that CABVForum never does protocol. In fact we did just that when we ignored the lunatic requirement to require name constraints to be marked as requiring a breaking chain (i.e. use the critical flag). I want to keep that practice the rare exception rather than the norm and reserve it for cases where the IETF group has made a real error and refuses to fix it. I don't see the problem with the errata series. We are not proposing this as a long term fix. We expect a new RFC will address this one way or the other. If things change on the IETF end, we can address them on the CABForum end. Now I was going to sarcastically point out that the only way that we could be absolutely certain of anything would be to reference the documents by SHA-2 digests enrolled in a blockchain. And then I realized that this was not only true it is probably a pretty good idea. I did some work with a scheme of this sort with Stephen Farrell and some others. -----Original Message----- From: Public [mailto:[email protected]] On Behalf Of Paul Hoffman via Public Sent: Friday, June 9, 2017 1:29 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Paul Hoffman <[email protected]> Subject: Re: [cabfpub] [Ext] Fixup ballot for CAA On Jun 9, 2017, at 9:38 AM, Gervase Markham via Public <[email protected]> wrote: > > On 06/06/17 09:42, Gervase Markham via Public wrote: >> So if and when we do think PHB's algorithm tweak is both stably >> defined and an improvement, then amending the BRs to specifically >> incorporate the erratum seems like the right fix, because that >> erratum can not be Verified (which would mean it was automatically incorporated). > > Further to this, I am advised that although errata numbers are > supposed to be stable for a given version of the text, this is not to > be relied upon. I therefore suggest that, once the errata text is > stable and agreed to be correct, we incorporate the text directly into the BRs. This seems sensible. Although the RFC Editor's errata system is supposed to be stable and have long-lived tracking, no one has really tested it, and it seems like the CAA requirement might be long-lived. It is thus better to put the diff from the RFC directly into the base requirements. --Paul Hoffman _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
