Skip to content
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.

Sign up for GitHub

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

Encoding equality to equivalence, and key equivalence #393

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Encoding equality to equivalence, and key equivalence #393

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 17 additions & 9 deletions cddl/crypto-key-type-choice.cddl
View file
Open in desktop
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how the expanded typing makes a difference wrt lossy/non-lossy properties of each type. We could have just documented them as one or the other.

Original file line number Diff line number Diff line change
@@ -1,12 +1,20 @@
$crypto-key-type-choice /= tagged-pkix-base64-key-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-path-type
$crypto-key-type-choice /= tagged-cose-key-type
$crypto-key-type-choice /= tagged-thumbprint-type
$crypto-key-type-choice /= tagged-cert-thumbprint-type
$crypto-key-type-choice /= tagged-cert-path-thumbprint-type
$crypto-key-type-choice /= tagged-pkix-asn1der-cert-type
$crypto-key-type-choice /= tagged-bytes
$crypto-key-type-choice /= lossless-crypto-key-type-choice
$crypto-key-type-choice /= lossless-crypto-key-cert-type-choice
$crypto-key-type-choice /= lossless-crypto-key-cert-path-type-choice
$crypto-key-type-choice /= lossy-crypto-key-type-choice

lossless-crypto-key-cert-path-type-choice /= tagged-pkix-base64-cert-path-type

lossless-crypto-key-cert-type-choice /= tagged-pkix-base64-cert-type
loslesss-crypto-key-cert-type-choice /= tagged-pkix-asn1der-cert-type

lossless-crypto-key-type-choice /= tagged-pkix-base64-key-type
lossless-crypto-key-type-choice /= tagged-cose-key-type

lossy-crypto-key-type-choice /= tagged-thumbprint-type
lossy-crypto-key-type-choice /= tagged-cert-thumbprint-type
lossy-crypto-key-type-choice /= tagged-cert-path-thumbprint-type
lossy-crypto-key-type-choice /= tagged-bytes

tagged-pkix-base64-key-type = #6.554(tstr)
tagged-pkix-base64-cert-type = #6.555(tstr)
Expand Down
26 changes: 18 additions & 8 deletions draft-ietf-rats-corim.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2206,9 +2206,7 @@ state of the Claim.
This specification does not assign special meanings to any Claim name,
it only specifies rules for determining when two Claim names are the same.

If two Claims have the same `environment-map` encoding then this does not
trigger special encoding in the Verifier. The Verifier follows instructions
in the CoRIM file which tell it how claims are related.
The Verifier follows instructions in the CoRIM file which tell it how claims are related.

If Evidence or Endorsements from different sources has the same `environment-map`
and `authorized-by` then the `measurement-values-map`s are merged.
Expand Down Expand Up @@ -2408,11 +2406,11 @@ If any of the fields does not match, then the condition ECT does not match the A
A Verifier SHALL compare each field which is present in the condition ECT `environment-map` against the corresponding field in the ACS entry `environment-map` using binary comparison.
Before performing the binary comparison, a Verifier SHOULD convert both `environment-map` fields into a form which meets CBOR Core Deterministic Encoding Requirements {{-cbor}}.

If all fields which are present in the condition ECT `environment-map` are present in the ACS entry and are binary identical, then the environments match.
If all fields which are present in the condition ECT `environment-map` are present in the ACS entry and are equivalent, then the environments match.

If any field which is present in the condition ECT `environment-map` is not present in the ACS entry, then the environments do not match.

If any field which is present in the condition ECT `environment-map` is not binary identical to the corresponding ACS entry field, then the environments do not match.
If any field which is present in the condition ECT `environment-map` is not equivalent to the corresponding ACS entry field, then the environments do not match.

If a field is not present in the condition ECT `environment-map` then the presence of, and value of, the corresponding ACS entry field SHALL NOT affect whether the environments match.

Expand All @@ -2427,6 +2425,18 @@ If any entry in the condition ECT `authority` does not have a matching entry in

When comparing two `$crypto-key-type-choice` fields for equality, a Verifier SHALL treat them as equal if their deterministic CBOR encoding is binary equal.

A Verifier MAY compare keys in different lossless formats `lossless-crypto-key-type-choice`, `lossless-crypto-key-cert-type-choice`, `lossless-crypto-key-cert-path-type-choice` is the following ways:

* A Verifier MAY compare a certificate to a key by means of the certificate's subject public key.
* A Verifier MAY compare a key across formats by their denoted algorithms and parameters.
* A Verifier MAY compare a key in the condition ECT to a candidate authority certificate path by finding a matching key in the path.

A Verifier MAY compare keys in lossy formats across representations provided they have a means to look up a corresponding lossless representation it can use for comparison, and the correspondence is documented.
A Verifier MAY compare a key in lossless format to lossy format if the lossy format correspondence to convert lossless to lossy is well-documented.
A `tagged-bytes` MUST only be compared with binary equality.

These comparison rules are specific to authorities and not `cryptokeys` measurements.

### Element list comparison {#sec-compare-element-list}

A Verifier SHALL iterate over all the entries in the condition ECT `element-list` and compare each one against the corresponding entry in the ACS entry `element-list`.
Expand All @@ -2442,7 +2452,7 @@ If any entry in the condition ECT `element-list` does not have a matching entry
A Verifier shall compare each `element-map` within the condition ECT `element-list` against the ACS entry `element-list`.

First, a Verifier SHALL locate the entries in the ACS entry `element-list` which have a matching `element-id` as the condition ECT `element-map`.
Two `element-id` fields are the same if they are either both omitted, or both present with binary identical deterministic encodings.
In the absence of equivalence rules, two `element-id` fields are the same if they are either both omitted, or both present with binary identical deterministic encodings.

Before performing the binary comparison, a Verifier SHOULD convert both fields into a form which meets CBOR Core Deterministic Encoding Requirements {{-cbor}}.

Expand All @@ -2453,7 +2463,7 @@ If any condition ECT entry has multiple corresponding `element-id`s then the ele
Second, a Verifier SHALL compare the `element-claims` field within the condition ECT `element-list` and the corresponding field from the ACS entry.
See {{sec-compare-mvm}}.

### Measurement values map map Comparison {#sec-compare-mvm}
### Measurement values map Comparison {#sec-compare-mvm}

A Verifier SHALL iterate over the codepoints which are present in the condition ECT element's `measurement-values-map`.
Each of the codepoints present in the condition ECT `measurement-values-map` is compared against the same codepoint in the candidate entry `measurement-values-map`.
Expand Down Expand Up @@ -2518,7 +2528,7 @@ A Verifier SHALL treat two algorithm identifiers as equal if they have the same
If both an integer and a string representation are defined for an algorithm then entities creating ECTs SHOULD use the integer representation.
If condition ECT and ACS entry use different names for the same algorithm, and the Verifier does not recognize that they are the same, then a downgrade attack is possible.

The comparison MUST return false if the CBOR encoding of the `digests` entry in the condition ECT or the ACS value with the same codepoint is incorrect (for example if fields are missing or the wrong type).
The comparison MUST return false if the determisitic encoding of the `digests` entry in the condition ECT or the ACS value with the same codepoint is incorrect (for example if fields are missing or the wrong type).

The comparison MUST return false if the condition ECT digests entry does not contain any digests.

Expand Down