Re: [Rats] Function of an endorsement relative to evidence

[Laurence Lundblade <[e-mail]>]

I’m using this thread to comment on the general issue of claims in endorsements vs attestations even though some of that discussion is in the other thread.

It’s right that attestations should not be signed by the same key as endorsements:
- The type of exposure to attack of the two signing keys are very different
- They have very different deployment, operational and life-cycle characteristics

I don’t know what the Endorsement standard will look like, but agree that going for a unified Endorsment/Attesation design now is a leap we’re not ready for. But, I don’t think we need that to progress the issue at hand.


That said, I stand by my comment (quoted far below) that data items can get from the Endorser/AttesterManufacturer to the Verifier either through 1) an Endorsement protocol/token or 2) by being embedded in the Attester at time of manufacture as a static claim.

Restating as three paths:
1a) Signed Endorsement transmitted B2B perhaps secured by TLS
1b) Independently signed Endorsement embedded in the Attester that the Attester conveys to the Verifier along with the Evidence
2) A static claim in Evidence

I don’t think we’re ready to design an Endorsement token/protocol here and now so no further discussion on 1a) or 1b).

Think about these static Attestation claims set by the Attester Manufacturer:
OEMID: Set once at manufacturer time and never changes; it is the same for large numbers of devices
UEID: Set once at manufacturing and never changes; it is different for each device
HW Version and Mode: Set once at manufacturing time and never changes; large groups have the same ID

We’re fine with these being set and sent as claims. They don’t have to be in an Endorsement, right? Some of them could be in an Endorsement, but there is nothing wrong with them in Evidence.

Of course if they are sent in Evidence, then there has to be an Endorsement that tells the Verifier they can believe these claims in Evidence and the signature on Evidence has to be verified.

To me security-level (the static statement of designed security level; see here <https://mailarchive.ietf.org/arch/browse/rats/?qdr=d>) is pretty much the same as the above claims in the way it is conveyed securely.

What ever the outcome for security-level is, I think getting to common understanding of how claims are secured relative to Endorsements is critical to Rats.

LL



> Begin forwarded message:
> 
> From: "Eric Voit \(evoit\)" <evoit=[e-mail]>
> Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
> Date: June 6, 2022 at 11:05:43 AM PDT
> To: Giridhar Mandyam <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> I am not suggesting any changes to the charter.   I am trying to help
> articulate an Endorsed security-level claim capable of transiting an
> Attester.  And that it is possible to verify this transit has happened
> without modification.   To me this falls under the RATS charter item [6]
> which says: "Standardize interoperable data formats to securely declare and
> convey endorsements and reference values."
> 
> I believe endorsements need to signed with a private key not found in the
> Attester.  And I believe any endorsements transiting the Attester need to be
> passed through to the Verifier and/or Relying Party with this signature
> intact.  
> 
> This is why I proposed requirements (1) & (2) below.  These requirements can
> be met using a single properly constructed x5chain or an x5bag.
> 
> Eric



> On Jun 6, 2022, at 9:44 AM, Henk Birkholz <[e-mail]> wrote:
> 
> Hi Laurence,
> 
> On 04.06.22 23:16, Laurence Lundblade wrote:
>> The fundamental purpose of an Endorsement is to tell the Verifier that they can believe what they get in Evidence. There may be some varying degree here from claim to claim and device to device, but the basic  principle always holds.
> 
> Well, actually I'd say that is a subset of what Endorsements are about. The few components in a Attester that you cannot produce Evidence about need Endorsements instead.
> 
> If an Attester does not know that is painted green, then that is a Claim about the Attester that has to come from the outside, has to be endorsed trusted third party (and here we go traditional... manufacturer, owner, etc.), because the Attester would never know that (only in weird cases, that is not the point) on its own devices.
> 
> On 05.06.22 21:34, Michael Richardson wrote:
>> So, it is*NEVER*  useful as Evidence.  EVER.
> 
> As the Attester can at the very best "cache" or "carry" an Endorsement put there during manufacturing, I think I have to agree with Michael here. Please note, in order to be useful and believable, the Endorsement is not signed by the Attester, but the Endorser! With key material not available to the Attester.
> 
> Viele Grüße,
> 
> Henk



> On Jun 4, 2022, at 2:16 PM, Laurence Lundblade <[e-mail]> wrote:
> 
> This is a step back for framing for the security-level discussion.
> 
> The fundamental purpose of an Endorsement is to tell the Verifier that they can believe what they get in Evidence. There may be some varying degree here from claim to claim and device to device, but the basic  principle always holds.
> 
> Assuming for the sake or argument here that the Attester Manufacturer and Endorser are the same, it goes like this. The Endorser/AttesterManufacturer only puts private keys into devices that it knows are built correctly. They won’t lie. They’ll protect their keys. They produce correct claims. This really is the fundamental work of the Endorser/AttesterManufacturer above all else.
> 
> For example, maker of a device with a TPM selects a good TPM and also carefully writes the boot code that does the measurement. They make sure that the devices that the TPM is soldered into always has the good boot code. Then they publish the public keys supplied with the TPM to the Verifier so it knows it can trust the measurements.
> 
> In the TPM world, you can’t really have the Attester send much more than PCRs in Evidence, but in the non-TPM world, lots of stuff can go into Evidence.
> 
> Tell me if you disagree with this!
> 
> 
> By all that, Evidence can be a parallel channel for the Endorser/AttesterManufacturer to convey claims to the Verifier.
> 
> The Endorsement can mean “believe all the Evidence from this Attester”. (It might always not be all the Evidence, but it will always be some of the Evidence).
> 
> By this it is entirely reasonable for security-level to be transmitted either as an Endorsement or in Evidence.
> 
> 
> I think there is also room for security-level in Evidence in composite device attestation. One Attester may have a good way to evaluate the security-level of a subsystem, perhaps a subsystem that varies from device to device.
> 
> LL
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats