Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt

[Eric Rescorla <[e-mail]>]

On Fri, Sep 29, 2023 at 6:22 AM Eliot Lear <[e-mail]> wrote:

> Hi Eric,
> On 29.09.2023 15:11, Eric Rescorla wrote:
>
> Well, I'm no longer at Mozilla, but seeing as you mention Firefox, I can
> tell you that when I was this scenario wasn't anywhere near the top of my
> concerns around European regulation. Rather, it was ill-advised
> requirements in the name of security (e.g. QWACs). In fact, while I had
> concerns about CRA, it was not about standards forking but rather about the
> security disclosure and process requirements (
> https://blog.mozilla.org/netpolicy/2023/07/13/european-parliaments-version-of-the-cra-threatens-cybersecurity-and-open-source-development/
> ).
>
> And it *shouldn't* be a concern, so long as we maintain control of our
> works.  You are proposing to release control of our works.
>
I'm proposing to release control of the words they are written in. I don't
think that's the main content of our works. Rather, that's the PDUs and the
protocol semantics (which, as an aside, is why it's possible to write
compatible implementations of specifications largely without reference to
the RFCs but rather by looking at protocol traces and other
implementations).


>
>
> If another jurisdiction replicates Europe's model and then diverges,  we
>> have can end up in one of two scenarios- one bad and the other worse:
>>
>>    - Bad: different code points, but a local requirement to use a
>>    particular standard; meaning no common algorithm selection.
>>    - Worse: same code point but different meaning.
>>
>> We can and have seriously limited both of these threats through our
>> copyrights.  If we give up on that we are asking for chaos.
>>
> I don't find this at all persuasive. ETSI is perfectly capable of writing
> their own versions of specifications when they choose to, or, alternately
> providing diffs against ours (again, see QWACs), and with any code points
> they choose. If the only thing preventing this is copyright, then that's
> not going to do much
>
> Ok, let's agree to disagree.
>
Well, we can do that, but I wish you would engage with the specific example
I provided above, which I think is directly on point and (again, when I was
at Mozilla) was by far the biggest concern I had about local variants of
specifications (see https://educatedguesswork.org/posts/eidas-article45/
for more details).

Here, we have a set of specifications which everyone agrees are managed by
the IETF, namely PKIX, TLS, and HTTP(S). The EU wishes to levy a new set of
requirements that browsers accept a variant type of certificate that
attests not to (or not only to, depending on the variant) the domain name
of the endpoint but rather to their legal identity (a "Qualified Website
Authentication Certificate"). When ETSI was called upon to provide the
supporting specifications for QWACs, they didn't write their own copies of
RFC 5280, etc. but just published their own documents that extend the IETF
RFCs. As noted, this is *also* what ETSI did for eTS.

I suppose you could argue that they did it this way because they weren't
allowed to just copy RFC 5280 and make their own changes, but that would be
an incredibly inefficient approach.The goal here is to leverage the
existing ecosystem with some tweaks not to create a parallel ecosystem,
because once you've done the latter, you actually own it and have to
maintain it. The effort of doing that would far outweigh the one time cost
of producing a compatible specification with different words.

-Ekr

> Eliot
>