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

[Michael Richardson <[e-mail]>]

>>>>> Laurence  <Lundblade, June 6, 2022 3:45 PM> writes:
    > 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.

They can even go into an IDevID certificate.
Then it's the manufacturer making a claim (an Endorsement) about the holder
of the private key.

In my world, the IDevID gets replaced by an LDevID for many things, so the
contents are no longer quite as trustworthy, depending upon the relationship
of the Verifier and the (Enterprise) owner.
The SUEID could go into the LDevID though, with the Enterprise Registrar
acting as RP for the initial onboarding.

    > 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.

One reason why one might want these as Evidence is if the Verifier wants
proof of possession of private key.  If a TLS connection with a client
authentication is used to convey Evidence, then that might already be
accomplished.  If the the conveyance is something else, then there might be
value.  Of course, in that situation, a freshness nonce might also be
included, so problem solved.

    > 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.

I agree.

    > <eric> The three claims listed above are focused on establishing
    > instance identity. A policy of the Relying Party needs to establish an
    > instance identity to understand the context of other claims.  An
    > endorsed security level should be a known function of the instance
    > identity once that identity has been established.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide