Verifier processing of authorized-by

[nedmsmith]

PR #107 line 1528, presumes there is no authority context without use of authorized-by statements. However, given all RVs are signed / authenticated, all RVs have an authorized-by context. The same is true for Evidence / ACS. All Evidence is signed / authenticated, hence has an authorized-by context. I don't think the conditional wording is needed, but rather to explain better the authorized-by context.

Namely, that all claims are entered into the ACS with authority context (either by assigning the corim signer corim-signer-map, or by authorized-by in measurement-map.

Note: coswid-triples, identity-triples and attest-key-triples need to be updated to include authorized-by since they don't use measurement-map.

[andrew-draper]

I agree this should be done, and we need to define authorized by better.
One thing to note is that we need description of use cases for this header, and to describe how authorized by is filled in when evidence/endorsements are added to the ACS

[nedmsmith]

A partial solution to this issue involves augmenting identity-triples and attest-key-triples with authorized-by. The solution proposed here builds on PR #127 which adds ? &(cryptokeys: 12) => [ + $crypto-key-type-choice ] measurement to measurement-values-map.
The current identity-triples uses:

identity-triple-record = [ 
     environment-map, 
     [ + $crypto-key-type-choice ] 
]

which doesn't include authorized-by.

triples-map = {
...
  ? &(identity-triples: 2) =>
    [ + identity-triple-record ]
  ? &(attest-key-triples: 3) =>
    [ + attest-key-triple-record ]
...
}

Instead, identity-triple-record is expanded:

identity-triple-record = [ 
     environment-map, 
     [ + $crypto-key-type-choice ] / measurement-map
]

and

attest-key-triple-record = [ 
     environment-map, 
     [ + $crypto-key-type-choice ] / measurement-map
]

Since, measurement-values-map contains [ + $crypto-key-type-choice ] the same key information can be described in the measurement value, but since measurement-map is included, the authorized-by context can be supplied.

Retaining the current definition prevent breaking backward compatibility.

[nedmsmith]

The coswid triple could be instrumented with authroized-by similarly:

coswid-triple-record = [
  environment-map
  [ + concise-swid-tag-id ]
]

concise-swid-tag-id = text / bstr .size 16

becomes:

coswid-triple-record = [
  environment-map
  [ + concise-swid-tag-id ] / measurement-map
]

measurement-values-map = {
...
? &(coswids: 13) =>  [ + concise-swid-tag-id ]
...
}

Alternatively, the coswid-triples triple could be deprecated (assuming no backward compatibility implications exist) and only define:

measurement-values-map = {
...
? &(coswids: 13) =>  [ + concise-swid-tag-id ]
...
}

[andrew-draper]

As I understand it, the processing rules for attest-key-triple-record are that one of the keys listed in the triple must be used to authenticate part of the evidence. If I'm correct there then this triple is really an expansion of authorized-by, but perhaps it can be replaced by an authorized-by on the reference-value being matched (doesn't work for conditional series triple etc).

If I understand identity-triple-record correctly then it could be deprecated and replaced by a $crypto-key-type-choice as discussed in issue #126

[nedmsmith]

As I understand it, the processing rules for attest-key-triple-record are that one of the keys listed in the triple must be used to authenticate part of the evidence. If I'm correct there then this triple is really an expansion of authorized-by, but perhaps it can be replaced by an authorized-by on the reference-value being matched (doesn't work for conditional series triple etc).

If I understand identity-triple-record correctly then it could be deprecated and replaced by a $crypto-key-type-choice as discussed in issue #126

Authorized-by is an alternative way of declaring authority (of a claim). Use of a key (to sign the claim) is the other (normal?) way to do it.

A measurement asserted via [ref | end | evidence]-triples implies appraisal through byte-wise comparison.

A measurement asserted via [identity | attest-key]-triples implies appraisal through some sort of key verification operation. PR #135 and issue #126 are addressing exact semantics.

I don't think there is agreement that authority for a claim is the same as a claim that is a key.

It may be that both require key verification of some kind, but that doesn't mean they are equivalent.

[andrew-draper]

PR #148 submitted which fixes this issue.

[andrew-draper]

I'm going to close this issue and continue discussing the key triples in #135 and #126