Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-acceptable-urls-04.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-04

I started with a review of text, and proceeded with a few edits.

I then got to

  (XXX: how should the trust anchor for the signature be updated when
   there is Merger&Acquisition)

and I decided to add a new section 4.1 on mergers/acquisitions and changes to
file structure:

https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-04.html#name-merger-acquisitions-and-key

Section 4.1.3 suggests that we can change the signing CA if we get the old CA
to sign the new CA.  That won't let us change the Subject Name of the EE.

I did add in section 4.0:
   When pinning the signature, the MUD controller SHOULD pin the lowest
   Certification Authority (CA) that was used in the validation of the CMS
   structure, along with the chain of Subject Names leading to the
   signature. The MUD controller may need additional trust anchors (including
   previously pinned ones) in order to verify that CA certificate.

and perhaps this belongs in an entirely new section, with more details.
The section 4.1.3 exploits this part to change signing authorities.
I'd really like some careful review of this.

I also added a section 5,
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-04.html#name-polling-for-changes-in-mud-

on how the MUD controller really has to poll, and therefore ETag and Max-Age
headers are probably required.   I welcome feedback as to whether or not I've
strayed too far from the original document goals.


====


4.1. Merger, Acquisitions and Key Changes
The above process allows for a manufacturer to rework its file
structure. They can change web server host names, so long as they retain the
old structure long enough for all devices to upgrade at least once.

The process also allows a manufacturer to change the EE certificate and
Certification Authority used for signing.

4.1.1. Changing file structure
A manufacturer has been hosting a MUD file at
https://example.com/household/products/mudfiles/toaster.json and wishes to
move it to https://example.com/mudfiles/toasters/model1945/mud.json

The manufacturer simply changes the MUD-URL contained with the files at the
old location to have a value of
https://example.com/mudfiles/toasters/model1945/mud.json. The manufacturer
must continue to serve the files from the old location for some time, or to
return an HTTP 301 (Moved Permanently) redirecting to the new location.

4.1.2. Changing hosting URLs
A manufacturer has been hosting a MUD file at
https://example.com/household/products/mudfiles/toaster.json and wishes to
move it to https://mud.example/example.com/toasters/model1945/mud.json

The manufacturer simply changes the MUD-URL contained with the files at the
old location to have a value of
https://example.com/mudfiles/toasters/model1945/mud.json. The manufacturer
has to continue to host at the old location until such time as it is sure
that all MUD controllers have loaded the new data, and that all devices in
the field have upgraded their URL. A 301 Redirect that changed the hostname
SHOULD NOT be accepted by MUD controllers.

4.1.3. Changing Signing Authority
A manufacturer has been signing MUD files using an EE Certificate with
subjectAltName foo.example, issued by an internal Certification Authority
BAZ.

The manufacturer wishes to begin signing with an EE Certificate with
subjectAltname foo.example, but now signed by a public CA (call it: Fluffy).

The manufacturer first creates a new MUD file with a new detached signature
file. Within this signature file, the manufacturer places a certificate
chain: Internal-CA BAZ->Fluffy, and then the Fluffy Certificate, and then the
foo.example certificate issued from Fluffy.

This supports changing certification authorities, but it does not support
changing the Subject Name of the signing entity.


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