Re: [Rats] CoTS and CoRIM

[Carl Wallace <[e-mail]>]

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