search

ietf-rats / ietf-corim-cddl

This repository is abandoned. The adopted I-D can be found at:
https://github.com/ietf-rats-wg/draft-ietf-rats-corim/
2 stars 0 forks source link

relative mkey #155

Open nedmsmith opened 3 years ago

nedmsmith commented 3 years ago

One of the challenges in matching environments to measurements is ensuring that Evidence is encoded with the right key. Currently, the environment-map and optional 'mkey' uniquely disambiguates the measurement value. Use of mkey in ref values can affect how evidence is encoded. If an evidence measurement is identified by an OID there is ambiguity if the RIM encoding uses mkey (or not). The way we have defined environment-map the evidence must exactly match the environment-map in ref values. If mkey is used it isn't included in environment matching. This implies an environment match could match multiple measurements. This implies there is a second tier matching operation applied to mkey. But the matching algorithm doesn't contemplate a 2nd-tier matching step.

If we consider OID as class-id, the OID tree already has tiering as each arc can represent a lower tier of objects. Applied to corim, mkey is a lower tier in the OID arc that identifies the environment-map. Matching algorithm issues aside, mkey as OID should be a relative OID (#6.110) as most of the differences between class-id OID and mkey OID are identical. e.g.: class-id = 1.2.3.4 mkey_1 = 1.2.3.4.1 mkey_2 = 1.2.3.4.2 etc...

relative OID means we only need to add the part of the OID that is the RHS to class-id OID. (e.g.: 1, 2, 3...)

nedmsmith commented 3 years ago

Endorsed-triple-records are another possible use case where \kval. Endorsed values are measurements that qualify reference values (essentially). The endorsed value measurement needs to be bound to a measurement or environment in a reference-triple-record.

That creates a three tuple that relates the ref-triple environment with the endorsed value e.g.: ( etr.environment-map.class-map.class-id , rtr.environment-map.class-map.class-id, etr.measurement-map.mval.<measurement>)

If we assert that the env maps for both etr and rtr must be the same then there is the problem that there needs to be a name given to the measurement value in etr. Otherwise, the logic would identify the etr measurements as duplicates / updates to what is in the rtr. That is wrong semantics because they are different types of measurements.

We could solve this ambiguity by using kval in etr to name the endorsed measurement. The 3-tuple becomes:

( etr.environment-map.class-map.class-id = <rtr.environment-map.class-map.class-id>, 
   etr.measurement-map.kval.<etr.environment-map.class-map.class-id<measurement>>, 
   etr.measurement-map.mval.<measurement>
)
nedmsmith commented 3 years ago

A question to consider is whether these two interpretations of how kval is used are compatible.

nedmsmith commented 3 years ago

Assuming kval should primarily be used for series measurements (change in trust state of the target environment over time).