Re: [Rats] 802.1AR device identity

Laurence Lundblade <> Fri, 23 April 2021 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B7B83A1918 for <>; Fri, 23 Apr 2021 11:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qXUdSyB8uxpZ for <>; Fri, 23 Apr 2021 11:16:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 449683A1917 for <>; Fri, 23 Apr 2021 11:16:18 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id a0Lfl0P0yrPTra0LglpyVh; Fri, 23 Apr 2021 11:16:16 -0700
X-CMAE-Analysis: v=2.4 cv=T89J89GQ c=1 sm=1 tr=0 ts=60830ef1 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=QyXUC8HyAAAA:8 a=tGX7uwomAAAA:8 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=K6EGIJCdAAAA:8 a=pGLkceISAAAA:8 a=Jg6--adYSNYXEHCzORYA:9 a=QEXdDO2ut3YA:10 a=OXrohY9_HIevfIkeyaAA:9 a=hy_OLbzDc93LghcN:21 a=_W_S_7VecoQA:10 a=ZFOOzkjxzLGrPE5HuMia:22 a=w1C3t2QeGrPiZgrLijVG:22 a=cAcMbU7R10T-QSRYIcO_:22 a=L6pVIi0Kn1GYQfi8-iRI:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A1677D2-FA49-4D03-8ADF-A796DAB91517"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Fri, 23 Apr 2021 11:16:14 -0700
In-Reply-To: <>
Cc: Russ Housley <>, Eliot Lear <>, Henk Birkholz <>, "" <>, "" <>, Ira McDonald <>, Guy Fedorkow <>
To: "Smith, Ned" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfJLKzwb4JRs6MaFT7oXIdZnI1uMabD1GHm8dU32bQaqwdej3OUvlVrgxL1AWXvdFkQs4Q3rih1ApNIV/VFuYl490GxU7HMMMyr3ptpqy9JEeULTeWFMF 0ZjWQoFAEN33Ox33+MqreKK58lRDNHhkb6f070/8kxJ4WpzgJoeNTkMmK9JQI6c2ehl1YVh5BNJN0CJbigx2rqAfNKh1T+cm3miOd+Bp+yjknwH0ilv56GNY /i98b9MzogiZvoL1NeAKpUuESLY0g05/8rXDqY6j+7okpENm8LSxZCd0/L2WlnLE27xM/9OngPXWTZmHNAJIZs5mgWgdDJf9W14IE/83FRPPWeW8WUS5Riie CVsTt22rmj3e7CxTwYgjYiD75Jn1YPMOjV8+eE3aG3PnUkHx7+y/wN6oGbeNF3OPpu1nelflvrYnjQ5CgQ/vifUYL7H26w==
Archived-At: <>
Subject: Re: [Rats] 802.1AR device identity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Apr 2021 18:16:24 -0000

Thanks for all the helpful responses and info here. 

I believe the discussion and comments received validate the EAT design of a UEID and an SUEID.

- Permanent. Set by device or chip manufacturer.
- Can’t be changed by subsequent owners or any in down-stream supply chain
- Akin to IDevID

- Semi-permanent. Can be set by new owners of the device, down stream entities in the supply chain and so on
- Changed on major device lifecycle events
- Akin to LDevID

The current SUIED PR doesn’t allow multiple SUIED’s the way you can have multiple LDevIDs. I think EAT needs to allow multiple SUIEDs.

Option 1 — A simple array of SUEIDs. You can’t really tell one from another or who assigned them.

Option 2 — Each SUEID is a pair of the SUEID plus a string naming the entity that created it or naming a type of SEUID.

Option 3 ?

My understanding is that one LDevID is distinguished from another by the issuer in the LDevID certificate. EAT doesn’t have these separate certificates.

EAT can use the same attestation key to sign one UEID and many SUEIDs. EAT can also have separate attestation keys for each SUEID. It can be used to implement the IDevID/LDevID model and/or other models.


> On Apr 21, 2021, at 4:19 PM, Smith, Ned <> wrote:
> It is reasonable, in the context of onboarding, where the owner isn’t a supply chain entity, but the network owner who is going to deploy / manage the device. Onboarding might involve separately evaluating the supply chain risk and any ‘owner’ that might be a supplier from onboarding processes that take a clean room approach that wipe clean / reset to mfg defaults.
> An mfg IDevID design might be such that tampering by supply chain ‘owners’ would be detected and hence trusting them isn’t really necessary. The end user / customer as ‘owner’ might only care about trusting the IDevID mfg or only trusting him/her self. 
> From: Russ Housley <>
> Date: Sunday, April 18, 2021 at 10:31 AM
> To: Eliot Lear <>
> Cc: Guy Fedorkow <>et>, "Smith, Ned" <>om>, Henk Berkholz <>de>, "" <>rg>, "" <>rg>, Laurence Lundblade <>om>, Ira McDonald <>
> Subject: Re: [Rats] 802.1AR device identity
>> On Apr 18, 2021, at 9:51 AM, Eliot Lear < <>> wrote:
>> Signed PGP part
>> Sorry for the delayed response:
>>> On 2 Apr 2021, at 19:05, Guy Fedorkow < <>> wrote:
>>> Hi Laurence,
>>>   I agree that IDevID is intended to persist through the device’s lifetime, while LDevID is meant to represent the current owner.
>> Yes, that was the original intent, and even the current intent.  And while that is necessary, it may not be sufficient for long supply chains where ownership passes from one to another.  The LDevID is an owner-assigned name, and so the question is this: when an owner goes to transfer, does it need to use the IDevID again or should it use the LDevID?  There are benefits and drawbacks to both, but if the LDevID is used, then it is used as the IDevID would have been as part of that transfer.  The nice thing about FDO is that it keeps an entire record of these sorts of transfers.
> I think it depends on whether the new owner trusts the issuer of the LDevID.  If so, then leveraging the existing LDevID may be straightforward.  If the new owner does not trust the issuer of the LDevID, then resetting the device to the factory default settings, which would include the IDevID, makes a lot of sense.
> Russ
> _______________________________________________
> RATS mailing list