Removing the term ECU Key #148
Conversation
|
@plapczyn Can you give a look and let me know if this is OK? Merging it puts us one step closer to closing out this issue. |
|
@plapczyn 2nd call. Does this properly address your suggestions? |
|
@jhdalek55 - This change will need to coincide with a change to the standard itself. We refer to an "ECU key" multiple times in the standard, however this is very confusing and we should try to clarify a better term. In the standard, there are some inconsistencies in the way we use the term. We say that the key can be symmetric, then talk about signatures. Honestly, I think we need to refactor the key usage and clearly describe the properties we are assuming for the keys. For instance, if we rely on a non-repudiation, we should not allow symmetric keys (or at least clarify that additional protections are needed when using these types of keys). It may be possible to configure the system with certain key flags to allow this property. |
|
Ok. I did make a change in the Standard as well as what appears here. It was PR #250, which was merged, though in following up it looks like a check failed in the commit. However, it appears to be within the text. Your write-up though implies that maybe this isn't enough? Is so, should be push this issue top V.2.2.0? Since we are supposed to be publishing 2.1.0 in less than two weeks, I don't think we have a lot of time to dither with this. Let me know what we should do. |
|
More changes may be needed based on our discussion from the 4/25 Uptane meeting, so let's leave this open for the time being. |
Per @plapczyn suggestion, I've re-written the text under the "ECU Keys" header using the term "ECU Identity key." This matches the re-naming suggested in PR #250 on the Standards Repo. When both of these PRs are approved, we can close Deployment Issue #139 .