Re: [Rats] name of identity key

[Michael Richardson <[e-mail]>]

In some private thread, Guy said:

    > Smith, Ned <[e-mail]> wrote:
    >> Actually, it is expected that there will be many keys in a platform
    >> that could be used to obtain an IDevID credential. As discrete
    >> components (vendors of) are increasingly embedding root-of-trust / key
    >> gen capabilities. The challenge is more likely one of deciding *which*
    >> key should be regarded as the 'platform' key/identity used for
    >> onboarding.

    >> I agree that having multiple IDevID credentials could be confusing to
    >> "platform" owners but that should not imply that a platform can only
    >> have one key / credential. It is possible for a platform to have a
    >> delegate device that represents the platform remotely while other
    >> *devices* recognize the delegate as a platform local 'verifier'. This
    >> is the Open Compute Project's Cerberus architecture / use case. The EAT
    >> sub_mods claim and TEEP architecture seems to support this convention
    >> as well.

I said:
    mcr> I don't want to prevent multiple IDevID credentials, I want to name them
    mcr> consistently :-)

Ned Smith then said:
    nms> Good question. Part of the motivation to use "IDevID" terminology in
    nms> TCG is to agree on some industry standard naming. The
    nms> Cerberus/RIoT/DICE work introduced other terms "AliasID" and

Do you mean Kerberos, or are you referring to something else?
(There have been multiple crypto protocols with that name, alas)

    nms> "DeviceID" which are more confusing than helpful. DICE layering also
    nms> uses subscript notation to disambiguate which component/layer a key
    nms> belongs to, since it doesn't make sense to name things like naming
    nms> your kids given a layered architecture. Even so, TPM and DICE still
    nms> distinguish between key / credential types based on expected usage
    nms> (identity, attestation) and DICE also support embedded CA use cases
    nms> therefore acknowledges a third type (ECA). ECA keys can attest, but
    nms> do so by including Evidence in the certificate it
    nms> issues. Attestation keys can sign evidence (e.g. sign an EAT) while
    nms> identity keys sign an auth challenge. Auth challenges can support
    nms> implicit attestation - meaning claims ascribed to the Attester
    nms> arrive at the Verifier through an out-of-band channel and can
    nms> include claims signed by Endorsers. The identity (aka SubjectName /
    nms> SubjectAltName etc...) is used to link the identity to Tokens or
    nms> Endorsements containing Claims.

    nms> Maybe it makes sense to talk about how the keys are used rather than trying to name them?

Well, I think that having it named "the key we use for Onboarding" is the
same as saying, "Onboarding Key", right?

I don't know how the manufacturing process that involves a TPM with a TPM
attestation key works.  I just know that when doing BRSKI, that there were
issues with being confused between various TPM keys, and we originally wrote
text saying that the device Serial Number might be in weird places.  We later
ripped that text out, as time had changed things, and I'm worried that this
issue is not really dead.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [




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