Re: [Rats] [Iotops] 802.1AR device identity

[Eliot Lear <[e-mail]>]

[moving rats to bcc… continuing discussion on iotops]

Hi Michael,

> 
> 
> (It could be that there are modes where another IDevID can be installed, but
> the original would not be removed.  Whether this is an LDevID or IDevID is
> open to intepretation)

Yes.

> 
>> I’ve had this thought in two
>> different contexts: What if the signature algorithm, CA, or private key
>> used to protect the iDevID has been compromised?
> 
> Then, the device is broken.
> I think you would certainly agree that this can be the only answer if the
> software signing key is compromised, right?

The device is vulnerable.  The question is whether a repair can be effected.

> 
>> Can one recover with an update?
>> What if there are attributes in the cert that I want to
>> dink and share with the deployment?
> 
> Please define "dink" for me.  I know of only one definition from the school yard.
> Does this mean remove? replace?

Yes.

> 
>> I’d like to take that latter case off the table, but then we need to
>> seriously think about RATS or SUIT providing a standard protected TLV
>> list that deployments could receive through a standard interface.
>> These are attestations of a form, but they’re not really measurements,
>> as has been previously discussed here.
> 
> Can you give me an example of one of these attributes?

Soooo…. Here’s an example:

Suppose I am a system integrator who needs to assemble a device out of constituent components that includes a particular software load.  I wish to claim to be the manufacturer of the device, as I am the one producing the final product.  I want to therefore provide the onboarding service.  That requires a change of URL for the MASA in BRSKI terms.  I may also wish to change the MUD-URL based on the software load.

The core question I am asking is this: we have attributes about the device I these certificates that really could be elsewhere.  But where?

Eliot