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

[Henk Birkholz <[e-mail]>]

Hi Laurence,

okay just fore representative purposes, I am doing this once now. Please 
don't be mad with me :-)

What are attestations?

Viele Grüße,

Henk

On 06.06.22 21:44, Laurence Lundblade wrote:
> 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] 
>> <mailto:evoit=[e-mail]>>
>> *Subject: **Re: [Rats] security-level claim (was Re: WGLC for 
>> https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat 
>> <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] 
>> <mailto:[e-mail]>>, "[e-mail] 
>> <mailto:[e-mail]>" <[e-mail] <mailto:[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] 
>> <mailto:[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] 
>> <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
>