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

["Smith, Ned" <[e-mail]>]

To sumarize, a mfg'r issued DeviceID certificate is an Endorsement. Additional claims included in the certificate would be considered Endorsements. 

A DeviceID certificate endorses the Attester's key which may be used to assert claims. In theory, the Attester could assert the same claims that the mfg'r asserts. 

If the Endorser gives carte blanche authority to the Attester key to assert claims on behalf of the Endorser, is that desirable? The answer is it depends on the Relying Party and Verifier who decide which entity (Endorser or Attester) is best able to assert the claims. Determining this may require looking at each claim individually to see what makes the most sense.
-Ned

On 6/9/22, 6:31 AM, "RATS on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

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