Adds extension point to validity-map #164
Conversation
Fixes #147 Signed-off-by: Yogesh Deshpande <[email protected]>
Signed-off-by: Yogesh Deshpande <[email protected]>
Signed-off-by: Yogesh Deshpande <[email protected]>
Signed-off-by: Yogesh Deshpande <[email protected]>
Co-authored-by: Henk Birkholz <[email protected]>
Incorporate some comments Co-authored-by: Thomas Fossati <[email protected]>
Add explaination for 0-N CoBOM requirement
Signed-off-by: Yogesh Deshpande <[email protected]>
Minor correction on Extensions
There was a problem hiding this comment.
The semantics of this must be documented in §1.3.3 -- and possibly in all the places it is validity-map is reused.
Besides, since this introduces an extension point, we need a new IANA sub-registry.
But more generally, I don't think this is the right design. (See #161 (comment) for the rationale.)
|
I am a bit confused by this PR (next to style & syntax). This seems to break the straight forward semantics of current validity map. But more importantly, I cannot see how Epoch Markers (that were the example in #161 would solve a problem here. Do they really? |
The validity period assumes verifier has trusted time. I'm looking for a solution that doesn't require trusted time. Epoch markers could be used in this sort of environment. |
Co-authored-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]> Co-authored-by: Thomas Fossati <[email protected]> Co-authored-by: Henk Birkholz <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]> Co-authored-by: Thomas Fossati <[email protected]> Co-authored-by: Henk Birkholz <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
code point 12 is already used by concise-evidence spec for spdm indirect.
changed cryptokeys code point to 13
Fix #184 Signed-off-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
Co-authored-by: Andrew Draper <[email protected]>
Co-authored-by: Ned Smith <[email protected]>
Co-authored-by: Ned Smith <[email protected]>
Signed-off-by: Thomas Fossati <[email protected]>
extend the use of tagged-bytes to identifiers
Improved prose and added lines describing verifier behavior
Improved prose and added lines describing verifier behavior
…aft-ietf-rats-corim into 161-validity-map
|
This branch was rebased to pick up changes in main that fixes ghpages build errors. |
We can tolerate not having an IANA sub-registry until there is interest in standardizing extensions. In the meantime, a vendor may leverage a profile context to define a vendor-specific approach using negative code points. The lack of a defined registry creates a friction point that limits use of the extention point for standard use, thereby limiting possible backwards compatibility issues should another approach become preferred. |
|
Move to "won't fix" based on the justification that an alternative form of validity can be added by extending at the corim-map and opting not to use validity? |
|
Sgrm |
|
Awaiting some actions in EPOCH markers draft to introduce an Extensibility points. @henk to follow up on this and then only close this Pull Request! |
Adds extension point to validity-map