Rework ECT comparison section to match new internal representation #289
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
andrew-draper
requested review from
henkbirkholz,
thomas-fossati,
yogeshbdeshpande and
nedmsmith
as code owners
deeglaze
requested changes
Sep 23, 2024
Co-authored-by: Dionna Amalie Glaze <dionnaglaze@google.com>
nedmsmith
reviewed
Sep 26, 2024
draft-ietf-rats-corim.md
Outdated
|
|
||
| Note: CBOR tags are useful for discriminating values amongst alternates, but the comparison of tagged values is still determined by the codepoint they appear under. It is recommended but not required to compare values with a specific CBOR tag the same way across codepoints. For this reason, it is recommended to specify a default comparison algorithm with the CBOR tag's registration. | ||
| If the codepoint key is negative then the Verifier MAY use a comparison algorithm defined by the appropriate CoRIM profile to compare the claims. | ||
| The codepoint number, the profile associated with the condition ECT, and the tag value (if present) shall be used to select the algorithm. |
There was a problem hiding this comment.
The "select" wording does not resonate with me. We are documenting the algorithms here. Can't we just write a section for each code point and describe the comparison algorithm?
Co-authored-by: Ned Smith <ned.smith@intel.com>
nedmsmith
reviewed
Sep 26, 2024
Comment on lines
+2091
to
+2092
| A Verifier MAY treat two keys as equal if they have different formats but represent the same key. | ||
| For example, a Verifier may contain code to compare a key fingerprint against the key which, when hashed, creates that fingerprint. |
There was a problem hiding this comment.
Suggested change
| A Verifier MAY treat two keys as equal if they have different formats but represent the same key. | |
| For example, a Verifier may contain code to compare a key fingerprint against the key which, when hashed, creates that fingerprint. |
This kind of optional behavior could result in different verifiers arriving at a different result given the same inputs.
It is safer if the Verifier simply compared the "keys" (aka authority values) as opaque values rather than try to do format translation to a universal form.
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.
This is the first edit to section 8.9 - it aligns the terminology with the change to ECT internal representation
It also defines the comparison rules for raw-value (codepoint 4 and 5).