[cabfpub] [Ext] Fixup ballot for CAA

[Phillip]

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:public-bounces at cabforum.org] On Behalf Of Paul Hoffman
via Public
Sent: Friday, June 9, 2017 1:29 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Paul Hoffman <paul.hoffman at icann.org>
Subject: Re: [cabfpub] [Ext] Fixup ballot for CAA

On Jun 9, 2017, at 9:38 AM, Gervase Markham via Public <public at cabforum.org>
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
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public