Add simple guidance on repo mapping metadata #111
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tkfu
changed the title
trishankatdatadog
requested changes
Jun 3, 2019
There was a problem hiding this comment.
LGTM @tkfu thanks!
I've got a couple of additional minor edits I want to make, should I just add commits here?
| 1. Load and verify the current time, or the most recent securely attested time. | ||
| 1. Download and check the Root metadata file from the Director repository, following the procedure in {{check_root}}. | ||
| 1. Download and check the Timestamp metadata file from the Director repository, following the procedure in {{check_timestamp}}. | ||
| 1. Download and check the Snapshot metadata file from the Director repository, following the procedure in {{check_snapshot}}. |
There was a problem hiding this comment.
Suggested change
| 1. Download and check the Snapshot metadata file from the Director repository, following the procedure in {{check_snapshot}}. | |
| 4. Download and check the Snapshot metadata file from the Director repository, following the procedure in {{check_snapshot}}. |
mnm678
reviewed
Jun 3, 2019
uptane-standard.md
Outdated
| @@ -634,6 +633,8 @@ Each ECU in a vehicle receiving over-the-air updates is either a primary or a se | |||
|
|
|||
| All ECUs MUST verify image metadata as specified in {{metadata_verification}} before installing an image or making it available to other ECUs. A primary ECU MUST perform full verification ({{full_verification}}). A secondary ECU SHOULD perform full verification if possible. See [Uptane Deployment Considerations](#DEPLOY) for a discussion of how to choose between partial and full verification. | |||
|
|
|||
| ECUs MUST have a secure source of time. The Uptane deployment considerations ({{DEPLOY}}) describe one way to implement an external time server to cryptographically attest time, but any other source of time that the OEM or Uptane implementor considers to be secure MAY be used. When "loading time" is referenced in procedures in this standard, it should be understood to mean loading into memory the current time (if the ECU has its own secure clock), or the most recent attested time. | |||
There was a problem hiding this comment.
I don't like the phrase "considers to be secure", is there anything more specific we can cite?
There was a problem hiding this comment.
Maybe RFC 7384? I don't want to do that normatively, though. I think that when it comes down to it, OEMs are going to make choices about time that are not perfectly secure, but are "good enough" by their own internal valuation of the risk. So the best realistic thing we can do here is give some best practices in the deployment considerations.
uptane-standard.md
Outdated
| Repository mapping metadata informs a primary ECU about which repositories to trust for images or image paths. Repository mapping metadata MUST be present on all primary ECUs, and MUST contain the following information: | ||
| As described in the introduction to {{design}}, Uptane requires a Director repository and an Image repository. However, it is possible to have an Uptane-compliant implementation that has more than two repositories. | ||
|
|
||
| Repository mapping metadata informs a primary ECU about which repositories to trust for images or image paths. {{TAP-4}} describes how to make use of more complex repository mapping metadata have more than the two required repositories. |
There was a problem hiding this comment.
I think the second sentence is missing a word.
|
Hi,
I agree that Uptane implementors *and* OEMs will make their
own decisions about secure time sources. So in the Uptane
standard, I don't think we want to add normative choices.
BUT - In the Deployment Considerations, I think we want
to strongly state that NO implementation should ever use
GPS-based time. It's inherently insecure and easily hacked.
For checking signatures and certificate revocations, for
example, Google Roughtime is more than sufficient (and
is now widely deployed in Internet servers):
https://roughtime.googlesource.com/roughtime
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: blueroofmusic@gmail.com
PO Box 221 Grand Marais, MI 49839 906-494-2434
…On Tue, Jun 4, 2019 at 5:00 AM Jon Oster ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In uptane-standard.md
<#111 (comment)>
:
> @@ -634,6 +633,8 @@ Each ECU in a vehicle receiving over-the-air updates is either a primary or a se
All ECUs MUST verify image metadata as specified in {{metadata_verification}} before installing an image or making it available to other ECUs. A primary ECU MUST perform full verification ({{full_verification}}). A secondary ECU SHOULD perform full verification if possible. See [Uptane Deployment Considerations](#DEPLOY) for a discussion of how to choose between partial and full verification.
+ECUs MUST have a secure source of time. The Uptane deployment considerations ({{DEPLOY}}) describe one way to implement an external time server to cryptographically attest time, but any other source of time that the OEM or Uptane implementor considers to be secure MAY be used. When "loading time" is referenced in procedures in this standard, it should be understood to mean loading into memory the current time (if the ECU has its own secure clock), or the most recent attested time.
Maybe RFC 7384 <https://tools.ietf.org/html/rfc7384>? I don't want to do
that normatively, though. I think that when it comes down to it, OEMs are
going to make choices about time that are not perfectly secure, but are
"good enough" by their own internal valuation of the risk. So the best
realistic thing we can do here is give some best practices in the
deployment considerations.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#111?email_source=notifications&email_token=AE33UOZOJUBWNGOSLWML4PLPYYVLPA5CNFSM4HR4CIJ2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB2PTTOI#discussion_r290195143>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE33UOZEM2MXE6GUECLZPBTPYYVLPANCNFSM4HR4CIJQ>
.
|
|
Merged before I could review again, but I think we should be good |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #53.
I also added a short paragraph on time, because many procedures still reference loading secure attestations of time, and the full time server procedure was removed in #104.