-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How do we handle government updates? #162
Comments
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. |
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
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 Wed, Apr 1, 2020 at 8:43 AM Justin Cappos ***@***.***> 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
<#162 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE33UO3ALGCKPQXKXTQYUDLRKMZIDANCNFSM4LYPWRIQ>
.
|
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:
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. |
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. |
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. |
@patrickvacek or @tkfu ---can we get this issue flagged as a milestone for V.2.0.0? |
Done. |
That was quick. Thanks.
Lois
…On Mon, Aug 17, 2020 at 10:29 AM Patrick Vacek ***@***.***> 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=>
.
|
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. |
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. |
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. |
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. |
We need a volunteer to ad some text to the Deployment pages on this topic. |
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. |
@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, |
Done. |
Thanks, Patti. |
PR #118, recently merged in Deployment Best Practices, provides a partial answer to this issue. It does not close out the issue. |
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? |
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. |
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. |
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? |
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
*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/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: ***@***.***
***@***.***>(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
<#162 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE33UOYKDUWPCG6NFOPRASLW5TZ2BANCNFSM4LYPWRIQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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 uptane/deployment-considerations#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.
The text was updated successfully, but these errors were encountered: