Re: [Rats] About (E)UID's

[Simon Frost <[e-mail]>]

I wasn't suggesting that the UEID claim be structured, rather that the description be changed to describe a value unique within the target context. This makes the standard claim more useful for any implementation that doesn't fit a global viewpoint, rather than that automatically needing a custom claim.

The assumption here is that a given implementation of Remote Attestation based on the standard will be prepared such that the policies applied by the verifier and the relying party take into account the locus to which that implementation is targeted. Within that, they can follow a standard definition for an (opaque) UEID claim as identifying a unique instance. However, it can be specific to that implementation context whether other claims, standard or custom, may be required to apply the policy. For example: if an implementation is built for a closed ecosystem with a dedicated single supplier then evidence appraisal may need only consider the UEID claim. Alternatively, if it is known there may be multiple suppliers then evidence appraisal could also consider, say, OEMID or Origination claims along with the UEID claim.

Going back to PSA Security Model, the InstanceID uniquely identifies the Attestation Key and which in turn must be unique to an Implementation of the PSA RoT, hence to establish locus the (custom) ImplementationID claim is also required.

On a related note, the PSA token proposes a 'Profile' claim to be included in the token, being a reference to a document that defines the set of claims used and any semantic details.  This wouldn't be required to satisfy the above but could be used to remove any ambiguity for the verifier implementer / policy writer. This proposed claim is captured as part of the EAT issues: https://github.com/ietf-rats-wg/eat/issues/32

HTH
Simon


-----Original Message-----
From: Michael Richardson <[e-mail]>
Sent: 11 February 2020 21:23
To: [e-mail]
Subject: Re: [Rats] About (E)UID's


Simon Frost <[e-mail]> wrote:
    > I agree that there should have a UEID claim within the standard and
    > also with the proposed bitlength representations.

    > I suggest we should change the description of the UEID claim to allow
    > the standard to support more interpretations of what the locus of
    > uniqueness might be to an implementation.

What are the implications to the Verifier and Relying Party of these differences?

If you intend there to be code path differences based upon the locus of uniqueness, then I would prefer that value of the UEID claim be opaque, and if we need to have semantic differences, that we register multiple UEID key values.


--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.