[OPSAWG] changes to draft-ietf-opsawg-mud-acceptable-urls-02.txt

[Michael Richardson <[e-mail]>]

>        Title           : Authorized update to MUD URLs
>        Authors         : Michael Richardson
>                          Wei Pan
>                          Eliot Lear

>A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-acceptable-urls-02

The text of the document has been revised for better flow.
Some content in the introduction has moved to section 3.

Section 4, which is the core of the proposal has been slightly tweaked, but
essentially remains the same: when signaling a changae to the MUD URL via
insecure mechanisms that malware may control (DHCP, LLDP), only changes to
the last component of the MUD URL are permitted.

The new mud file may contain a new MUD-URL, which is substantially different
from the original one, and this allows the manufacturer to re-organize their
site (or even change sites entirely).  But this is controlled because the new
file must be signed by the same signer as the original file.

This document makes some statements in section 3.3 about pinning of the
signing entity.  This language is not at this point normative.

This document has marked itself as a BCP in the header, although it has grown
some BCP14 language.  It seems that it an error, that it should be standards
in order track to Update RFC8520, and should include BCP14 language.
How does the WG feel about that?  The adoption call did not say anything
about intended status.

There is an option issue at the end of section 4:
      XXX: how should the trust anchor for the signature be updated when
      there is Merger&Acquisition)

There are a number of different ways in which this could be handled.
Getting it right, and making it interoperable would require that we make some
more substantive normative statements about how the MUD controller pins the
signing entity from the Manufacturer.

While this seems slightly esoteric to worry about M&A actitivy, establishing
the long-term identity of the manufacturer seems pretty important.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide