Re: [Rats] CoTS and CoRIM

["Smith, Ned" <[e-mail]>]

>[CW] “My answer to this question is essentially no TAs are Endorsements. I’ve given references to sections in the architecture draft to explain why previously but will put the contents here in full and provide a few fictional examples. RFC 9334 defines an Endorsement … [snip]”

While 9334 provides a conceptual definition of endorsements, it should not be interpreted with any sort of mathematical precision. For example, it is not saying that an “endorser” can’t make assertions about things that fall outside of this definition and place them in “endorsements”.


The best advice I can give is that a key (aka principal – see [1] A Calculus for Access Control in Distributed MARTIN ABADI, MICHAEL BURROWS, and BUTLER LAMPSON) can say (assert) any claim it wishes. Assertions are limited only by the expressiveness of the claims schemas. The Verifier’s primary function is to keep track of which principal asserted which claims. The claims that are relevant to a RP are asserted by RP Owner (via the RP over an exchange between the RP and the Verifier) or via Verifier Owner in the form of appraisal policy for Evidence. But clearly, Verifier Owner will specify policy for how to trust Endorsers and RVPs as well as Attesters. Normally, this is accomplished using TA policies that direct which TAs to place in the Verifiers TA store.



RPs can either filter the verifier results (i.e., a statement tree of who said what), or the Verifier can filter results based on inputs from the RP. Either way, the RP processes only the claims that are most relevant to the RP use case.



Note, the Verifier is also a principal who can assert claims. This doesn’t mean the Verifier is/isn’t an endorser as a Verifier is also likely to be yet another entity in a broader supply chain context. 9334 simply provides a set of descriptions for roles and messages that facilitate information flows and processes that relate to attestation. It isn’t intended to be a formal model the way [1] is intended.



My personal view is RVPs are a special case of “Endorsers” where the RV claims are intended to match Attester asserted claims. In the simple case where an exact match is presumed, the only difference between the claims sets is who asserted them. The Verifier simply keeps track of both.



If there are claims that are not expected to “match” Evidence, then these are endorsements (even if they have nothing to do with trustworthiness attributes). It is assumed, these claims are asserted with some context about the Attester such that a Verifier can reason whether they apply to a known Attester. Hence, all endorsements are conditional upon some form of attester context (for example, the key the attester used to authenticate to a Verifier).



Attesters can assert any claims they wish. If none of the claims are a subset of RVs, then the claims are still relevant in that Verifiers primarily just keep track of who said what. An RP policy (aka claims that an RP asserts about what is relevant for a use case) could identify Attester asserted claims that were not part of the RVP claims. If so, these claims would not be filtered by the RP policy and would show up in Attestation Results. It would be the same as if an RP policy said to trust anything asserted by an Attester (based on Attester identity / credentials).



However, a normal use case anticipates RPs that have policies that identify RVPs and Endorsers that are trusted to make authoritative assertions about an Attester device.



According to [1] a principal “speaks” using cryptographic keys. Anything that can be digitally signed could be regarded as a claimset. Hence, it isn’t wrong to read 9334 and interpret it to be inclusive of X.509 certificates, XML-DSIG, COSE, JOSE, CWT, JWT, …. Or any other format of signed data. A TA isn’t a TA until it is written into the principal’s secure storage that is used to terminate path validation. Otherwise, keys can be asserted as endorsements, evidence, reference values, and attestation results freely. It is a reasonable use case if vendor A asserts that vendor B is authorized to assert a claim set X. A RP policy that accepts this statement might process it by writing vendor B’s public key into a TA store. It becomes a TA policy at that point.



Cheers,

Ned



[1] https://homepages.inf.ed.ac.uk/gdp/publications/Calculus_for_Access_Control.pdf

From: RATS <[e-mail]> on behalf of Carl Wallace <[e-mail]>
Date: Monday, December 18, 2023 at 3:36 AM
To: Muhammad Usama Sardar <[e-mail]>, Thomas Fossati <[e-mail]>, Henk Berkholz <[e-mail]>
Cc: "hannes.tschofenig=[e-mail]" <hannes.tschofenig=[e-mail]>, Yogesh Deshpande <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Rats] CoTS and CoRIM

Aside from editorial comments about use of the word “data” where “value” would have been better, most of this thread relates to differences of opinion regarding whether a TA is an endorsement, as in this comment plucked from below).

[MUS] Is there any TA/CA public key in the context of this draft which should not be considered Endorsement? If yes, which one and why?

[CW] My answer to this question is essentially no TAs are Endorsements. I’ve given references to sections in the architecture draft to explain why previously but will put the contents here in full and provide a few fictional examples. RFC 9334 defines an Endorsement as follows:


“A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities, such as Claims collection and Evidence signing.
Consumed By:
Verifier
Produced By:
Endorser”

The attester role is defined as:


“A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation.
Produces:
Evidence”

RFC9334 addresses trust anchors in the Trust Model section. I don’t see why it is desirable to transitively extend the endorsement definition up through the trust model.

A typical certification path may look like this: TA -> CA1 (off device) -> CA2 (on device) -> End Entity. In my mind, the terms in the architecture draft apply like this: TA (trust model) -> CA1 (trust model) -> CA2 (endorsement from CA1 for attester CA2) -> End Entity (evidence). The indirection and the fact that the Verifier chooses its own TA store contents do not fit with labeling a TA as an Endorsement.

For sake of argument, suppose a group of manufacturers have defined a trust model like the bridge CAs uses in pharma and aerospace industries. Each vendor has their own root, with a bridge CA used to establish trust between vendors. In this example, let’s say there are two devices from two different vendors:

Vendor A Root -> CA A1 -> CA A2 -> End Entity A
Vendor B Root -> CA B1 -> CA B2 -> End Entity B

When these are verified via the notional consortium’s trust model you could end up with the following in a Verifier from Vendor C:

Vendor C TA -> Bridge CA -> Vendor A Root -> CA A1 -> CA A2 -> End Entity A.

If we say *all* trust anchors and CA certs are endorsements, Vendor C TA and Bridge CA would be an Endorsement for End Entity A.

Let’s consider another case, where there is a long-lived device.

Vendor L TA -> CA L1 -> CA L2 -> End Entity L

Maybe in this case, the Verifier is provisioned with CA L1 (or even CA L2) as a trust anchor for sake of efficiency. In this case, I could see a trust anchor being an endorsement.

In my opinion, it is better to leave Trust Anchors as part of the Trust Model, which is really part of Appraisal Policy, instead of trying to label TAs as endorsements. CA certificates are blurrier in terms of the definitions, and I don’t think it’s necessary to try to say all CA certificates are endorsements either.

From: Muhammad Usama Sardar <[e-mail]>
Date: Saturday, December 16, 2023 at 10:57 AM
To: Carl Wallace <[e-mail]>, Thomas Fossati <[e-mail]>, Henk Birkholz <[e-mail]>
Cc: <hannes.tschofenig=[e-mail]>, Yogesh Deshpande <[e-mail]>, <[e-mail]>
Subject: Re: [Rats] CoTS and CoRIM


Hi Carl,
On 16.12.23 16:17, Carl Wallace wrote:
<snip>
[CW] This is because the first sentence is setting up the next sentence which gives an example of a typically short-lived reference value type and contrasts this with typically long-lived TAs and CAs. Why is it necessary to mention endorsements in the sentence you reference?
[MUS] because public keys are Endorsements and a direct comparison with Reference Values alone does not sound very logical to me.

[CW] It is not a direct comparison with reference values.
[MUS] At least to me, it clearly is: "Trust anchor (TA) and certification authority (CA) public keys may be less dynamic than the reference values"
The sentence is part of rationale for conveying trust anchors independent of CoRIMs. CoRIMs convey reference data, which are often shorter lived.
[MUS] Please avoid non-standard terms such as "reference data" which are neither defined in draft nor in RFC9334. That only adds confusion. CoRIMs convey not only Reference Values but also Endorsements.
While I don’t agree that all public keys are endorsements (or even that all private key holders are endorsers),
[MUS] Is there any TA/CA public key in the context of this draft which should not be considered Endorsement? If yes, which one and why?
if that is how the group wants to view them that’s fine. Labeling them in this way does not alter their function.
and seems to create exactly the same misunderstanding that Hannes pointed.
<snip>
The point here isn’t that all reference values or endorsements are short-lived but that often they are shorter lived than trust anchors.

[MUS] I assume "they" in your statement includes Endorsements (and not only Reference Values)?

[CW] In this statement, yes, “they” included “reference values or endorsements.”

If yes, there is a very simple fix, something likes this:

"Trust anchor (TA) and certification authority (CA) public keys may be less dynamic than other types of endorsements and the reference values"


[CW] OK. I don’t see where that changes much but if others find that this adds clarity it seems fine to me despite the intimation that all public keys are endorsements. I’d really rather we not backdoor the “all public keys are endorsements” notion in this way, though. If that is generally held, it should be written more clearly. Something like: “All trust anchors and certificate authority certificates are endorsements.”


[MUS] I think this is exactly what the issue #3 requested. "Please clarify that trust anchors are Endorsements and not Reference Values." If this is clearly specified before third paragraph, then the above suggested change in third paragraph is not required.
Given trust anchor lifespans are often measured in decades I really don’t see this as a controversial notion. This is not to say that there may not be some reference values or endorsements that are similarly long-lived.

Cheers,

Usama
On 15.12.23 09:45, Thomas Fossati wrote:

Usama, Hannes, could you have a look at the clarifying edits in

[1] and tell us if it's OK to merge them?



Thanks for raising this.



cheers, t



[1] https://ietf-rats-wg.github.io/draft-wallace-rats-concise-ta-stores/tas-are-not-refvals/draft-ietf-rats-concise-ta-stores.html#section-1