How should we handle updates that are location-focused?

[tkfu]

There are certain types of updates, like maps, rules-of-the-road, or emergency traffic notifications, that are relevant to vehicles based on their specific location. How can Uptane be extended to help secure these use cases?

Note: this issue is split off from #120 to consider the location-specific use case. Discussion of the factory flashing/updating use case for non-ECU-targeted updates continues on that issue.

[kyusuk]

Interesting topic. By the way, maps and rules are static, while emergency traffic notification is dynamic and needs real-time communication. We may need to consider Uptane principle for data stream for later case.

[pattivacek]

maps and rules are static

I don't agree. They might be static, and it's true that emergency notifications are likely to change more quickly and perhaps demand a higher level of dynamic control, but maps and rules can absolutely change over time.

[pattivacek]

To summarize some of our discussion on the call and my understanding:

• There might again actually be two issues issues here:

1. Emergency government override, which should have a higher authority than the OEM. This may require two Directors (one from the government and one from the OEM) or this may be outside of Uptane as we know it.
2. Maps, rules-of-the-road, or other non-emergency information that can still use the OEM's Director for distribution, but are non-unique to a vehicle and instead are tied to a location or something else.

• The first case I don't have a good handle on, but the second I might. Here are my thoughts:
  • Image repo would have to indicate the target applies only to a specific region (instead of a hardware identifier?).
  • There is a URL type for describing location that we could use. It includes a way to specify a radius. (See Ira's comment in #120.)
  • The device would report its location in the manifest and Director would respond (presumably automatically) to the device using that location and the device identifier.

[JustinCappos]

The emergency government override isn't in scope here. It would be a separate issue (multi-director / image repo) as you correctly pointed out.

…

On Tue, Mar 31, 2020 at 10:59 AM Patrick Vacek ***@***.***> wrote: To summarize some of our discussion on the call and my understanding: - There might again actually be two issues issues here: 1. Emergency government override, which should have a higher authority than the OEM. This may require two Directors (one from the government and one from the OEM) or this may be outside of Uptane as we know it. 2. Maps, rules-of-the-road, or other non-emergency information that can still use the OEM's Director for distribution, but are non-unique to a vehicle and instead are tied to a location or something else. - The first case I don't have a good handle on, but the second I might. Here are my thoughts: - Image repo would have to indicate the target applies only to a specific region instead of an ECU identifer, and Director would have to approve as well. - There is a URL type for describing location that we could use. It includes a way to specify a radius. - The device would report its location in the manifest and Director would respond (presumably automatically) to the device using that location and the device identifier. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD53SLYP746YMOPCIKDRKIAO5ANCNFSM4LNPR3UA> .

[pattivacek]

The emergency government override isn't in scope here. It would be a separate issue (multi-director / image repo) as you correctly pointed out.

That makes sense to me. I've created #162 to cover the government emergency use case (item 1 in my previous comment) while we can continue discussing non-emergency location-based updates (item 2 in my previous comment) here.

[jhdalek55]

Could we get some additional feedback and/or maybe a draft PR here before our next meeting?

[pattivacek]

Should we approach this by changing the Standard to explicitly allow it, or should we add a chapter to the Deployment Considerations that lays out how to do it? I'm leaning towards the latter with the aim of keeping the "default" or "normal" use case as simple as we can.

[iramcdonald]

Hi, I agree with Patrick that discussing this in the Deployment Considerations for now makes the most sense. Perhaps after some deployment experience and reviews, we might want to eventually say something minimal in the Standard (while still keeping the main stuff in the Standard simple). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: [email protected] (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434

…

On Tue, Apr 14, 2020 at 3:17 AM Patrick Vacek ***@***.***> wrote: Should we approach this by changing the Standard to explicitly allow it, or should we add a chapter to the Deployment Considerations that lays out how to do it? I'm leaning towards the latter with the aim of keeping the "default" or "normal" use case as simple as we can. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO56Q2DJWCIOFUOIXHTRMQEYTANCNFSM4LNPR3UA> .

[jhdalek55]

PR#44 has been merged on the Deployment pages. Have we sufficiently addressed this issue, or should we continue to leave it open?

[pattivacek]

PR#44 has been merged on the Deployment pages. Have we sufficiently addressed this issue, or should we continue to leave it open?

In my opinion, this has been addressed and we should focus on the other open issues.