search

uptane / uptane-standard

standard for Uptane
https://uptane.github.io
Other
36 stars 30 forks source link

How do we handle government updates? #162

Open pattivacek opened 4 years ago

pattivacek commented 4 years ago

Governments and regulatory bodies may require automakers to grant them full control over a vehicle in emergency situations. How can Uptane be extended to allow secure access for such a situation?

This may require two Directors and Image Repositories (one each from the government and the OEM). Delegations are not good enough to solve this, as the government will have a higher authority than the OEM, but the government probably won't want to micromanage OEM's non-emergency updates.

This may be better covered in the Deployment Considerations, and this may build upon https://github.com/uptane/deployment-considerations/issues/4.

Note: this issue is split off from #161 to consider the government emergency use case. Discussion of the non-emergency location-based updates continues on that issue.

JustinCappos commented 4 years ago

Delegations are not good enough to solve this,

I just want to make a minor comment. It is possible to do this with delegations on the same repository, but either the government or OEM will have to control the repository, which may not be desirable / permitted.

iramcdonald commented 4 years ago

Hi Justin,

It may be technical possible to do with delegations. But not legally possible. The Registration Authorities and Certificate Authorities in ITS safety must be owned/managed by government authorities. They cannot be delegated from OEMs. And vice-versa.

Cheers,

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: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434

On Wed, Apr 1, 2020 at 8:43 AM Justin Cappos notifications@github.com wrote:

Delegations are not good enough to solve this,

I just want to make a minor comment. It is possible to do this with delegations on the same repository, but either the government or OEM will have to control the repository, which may not be desirable / permitted.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/162#issuecomment-607226634, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO3ALGCKPQXKXTQYUDLRKMZIDANCNFSM4LYPWRIQ .

cameronmott commented 4 years ago

This is an interesting issue, indeed. We will need clarity on whether this is a design requirement or is handled outside of Uptane. My current expectation is that this is outside of Uptane but I'd like to explore the possibilities.

Some complications that I would anticipate that need to be addressed:

  1. Interoperability between OEMs If a government agency is to have the ability to override functionality of a vehicle remotely in an emergency situation, it would need to be implemented for multiple OEMs. Are there separate systems for each of the different OEMs? One system that incorporates all of the POUFs and also stores all of the updates for each ECU per OEM?
  2. Extent of "full control" Is this a case of fail-operational control where the vehicle's functionality can be adjusted (pull to the side of the road, reduce speed to below 25 MPH at a safe deceleration rate) or fail-safe control where the vehicle comes to a stop. Another option may be triggering a mode that is built-in by the OEM such as a limp-mode or location tether where the vehicle's functionality is restricted by simple rules.

I believe that there are parallels here with fleet vehicle updates (updates that are not necessarily OEM controlled) as well as after-market vehicle updates. It will be important to understand how these may (or may not) play a part in these scenarios.

jhdalek55 commented 4 years ago

On the 4/28 Uptane Standards call, it was decided we would put this issue on hold for the time being, pending the deliberations of other standards teams. A discussion of this use case might be appropriate on the Deployment pages if a volunteer wanted to frame such a discussion.

jhdalek55 commented 4 years ago

On the 6/9 Uptane Standards call it was decided that though this issue remains on hold in terms of the Standard, we may want to issue a white paper that summarizes the status quo for this issue and current efforts to resolve it.

jhdalek55 commented 4 years ago

@patrickvacek or @tkfu ---can we get this issue flagged as a milestone for V.2.0.0?

pattivacek commented 4 years ago

Done.

jhdalek55 commented 4 years ago

That was quick. Thanks.

Lois

On Mon, Aug 17, 2020 at 10:29 AM Patrick Vacek notifications@github.com wrote:

Done.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uptane_uptane-2Dstandard_issues_162-23issuecomment-2D674915761&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=hgBKIqNYIOwzXeBjPUaKRw&m=d9zx1X_2EyXS5cvB3K_c8GhB_A4hOni-Fq4xk2LADlc&s=3Ne64JqESZ7bTIDdzTVqWMnhU4oWLTbKwLOgZUAIhKg&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADPGUX4IWEE4GT3ZEEISPPTSBE5GBANCNFSM4LYPWRIQ&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=hgBKIqNYIOwzXeBjPUaKRw&m=d9zx1X_2EyXS5cvB3K_c8GhB_A4hOni-Fq4xk2LADlc&s=pGFUPUDN8Rm2w7vxZH3T8MGTY4O9eTLCkxSgUhSi8Ac&e= .

jhdalek55 commented 3 years ago

We can leave this flagged for 2.0.0 for now, but based on discussions at our 12/8 meeting, it is most likely something that may need to wait for an even later version.

jhdalek55 commented 3 years ago

Per our 3/16 meeting, it was recommended by @iramcdonald that we add a mention of this issue to the Deployment pages as a way of letting the community know we are aware of this issue. Draft text could be added to "Exceptional Operations" page.

jhdalek55 commented 3 years ago

At our 4/13 meeting, it was agreed we should add an "Emerging Issues" page to Deployment Best Practices that would address topics like this one where no definitive solution is on the horizon. PR # 104 opened a file for this page and @jhdalek55 will draft some initial text. In addition to this issue, the text will address Issues #200, #201 and Issue #86 on the Deployment pages.

jhdalek55 commented 3 years ago

At the Uptane Standard meeting on 8/3, it was suggested we may add some text about this issue may be added to the Deployment pages. This will focus only on the problems and will not put forward any solutions.

jhdalek55 commented 3 years ago

We need a volunteer to ad some text to the Deployment pages on this topic.

jhdalek55 commented 2 years ago

Though we have mentioned the issue on the "Emerging Issues" page, it probably should have some text directly addressing it. While I would much prefer this be addressed by someone with more knowledge than I on the subject, I will put together some rough text if several of the group members will give it a careful reading.

jhdalek55 commented 2 years ago

@pattivacek ...when you get a chance, can you change the title of this issue to "How do we handle government updates?"

This is per @iramcdonald's comments in the 9/28 Uptane Standard meeting that these updates may not always involve an emergency. Thanks,

pattivacek commented 2 years ago

can you change the title of this issue to "How do we handle government updates?"

Done.

jhdalek55 commented 2 years ago

Thanks, Patti.

jhdalek55 commented 2 years ago

PR #118, recently merged in Deployment Best Practices, provides a partial answer to this issue. It does not close out the issue.

jhdalek55 commented 2 years ago

Since this issue cannot be resolved at this time, can we make a new label, perhaps PENDING, for issues like this for which cannot say when they answered? I would prefer we did not leave issues like this (#162 #198) labeled "2.0.0" on the repo as it gives the appearance that we did not completed these on-time. Failing that can we leave it posted without a version label at all?

jhdalek55 commented 2 years ago

On 1-4-22, we reviewed all the open issues to see if any required reframing. After some discussion, we felt that this is clearly stated, and so we will leave it as is.

jhdalek55 commented 1 year ago

After discussing this at the 1/31/23 Uptane Standard meeting, the group felt there is nothing we can specifically address with this issue as it stands. However, this may actually be part of a much larger issue, how to address the needs of fleet operators. Government updates could be one use case, but there are probably more common and addressable ones than this under this umbrella.

jhdalek55 commented 1 year ago

Given the discussion we had earlier in the year (see comment above) do we want to close this issue and re-open a new one that embraces this issue as the needs of fleet operators?

iramcdonald commented 1 year ago

Hi,

IMO, fleet management updates and government updates are disjoint and not closely related. I believe that, until government regulations address government updates, we should abandon that topic for the indefinite future.

I think it's fine to have a separate issue on fleet management updates (whether they are coming from the OEM, the "body builder" (correct term from ISO 24089) who actually built the fleet vehicles on raw frames from the OEM, or the independent fleet owner. A primary aspect is the obvious need for multiple Image Repositories and multiple Directors, which is our major future general topic for Uptane (along with the related topic of multiple in-vehicle Primary ECUs with separate domains of Secondary ECUs to manage).

Cheers,

Ira McDonald (Musician / Software Architect)

Chair - SAE Trust Anchors and Authentication TF Co-Chair - TCG Trusted Mobility Solutions WG

Co-Chair - TCG Metadata Access Protocol SG

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: @. @.>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

On Thu, Mar 23, 2023 at 9:25 PM Lois Anne DeLong @.***> wrote:

Given the discussion we had earlier in the year (see comment above) do we want to close this issue and re-open a new one that embraces this issue as the needs of fleet operators?

— Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/162#issuecomment-1482125750, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UOYKDUWPCG6NFOPRASLW5TZ2BANCNFSM4LYPWRIQ . You are receiving this because you were mentioned.Message ID: @.***>