> 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 <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
