diff --git a/cddl/crypto-key-type-choice.cddl b/cddl/crypto-key-type-choice.cddl index e8caf813..febcc0bf 100644 --- a/cddl/crypto-key-type-choice.cddl +++ b/cddl/crypto-key-type-choice.cddl @@ -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) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 32b1e2ce..a2a453c8 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -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. @@ -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. @@ -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`. @@ -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}}. @@ -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`. @@ -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.