[T2TRG] Laws of Identity and idevid-considerations

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> wrote:
    > I have sent a zillion editorial comments (yes, starting from
    > “toxonomy”) to the authors; I really recommend reading the document as
    > soon as they are addressed.

Now addresses:

Title:		A Taxonomy of operational security of manufacturer installed keys and anchors
Document date:	2020-08-27
Group:		Individual Submission
Pages:		25
URL:            https://www.ietf.org/internet-drafts/draft-richardson-t2trg-idevid-considerations-01.txt
Status:         https://datatracker.ietf.org/doc/draft-richardson-t2trg-idevid-considerations/
Htmlized:       https://tools.ietf.org/html/draft-richardson-t2trg-idevid-considerations-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richardson-t2trg-idevid-considerations
Diff:           https://www.ietf.org/rfcdiff?url2=draft-richardson-t2trg-idevid-considerations-01

    > It is amazing that even this document occasionally falls into the trap
    > of using the same term for a public key/certificate and a key pair (or
    > even the attribute that is proven by demonstrating the possession of
    > that key pair).  That is easy to do because they work in step/in
    > harmony, but we do need to fix our language here.

Yes, I agree.
I like the symmetry that the things in the device are either roots of trust
(a term from remote attestion), or trust anchors.

Roots of Trust imply a keypair in the device.
Trust Anchors are just the public part, embued with some authorization.
Whether the Trust Anchor anchors an entire hierachy of PKI or not is one of
the questions that needs to be evaluated.

Meanwhile, on the factory/facility side, there are also keypairs that are
part of the PKI, or not.  I would love to give each some distinct term, even
though mathematically, they are exactly identical.

    > I think that the questions in Section 6 are good ones, but sometimes I
    > feel that more fundamental questions are struggling to come to the
    > light here.  Can we find them?

I agree, there may be more fundamental things to ask, but they might also be
too specific, and the general question can elicit a variety of different
kinds of answers.

    > The document discusses the issue of “justified parties” for the
    > manufacturing process, but not for the PKI side.  Maybe we can expand
    > on that, too.

Carsten Bormann <[e-mail]> wrote:
    > On 2020-08-25, at 02:27, Carsten Bormann <[e-mail]> wrote:
    >>
    >> “justified parties”

    > … and I meant Kim Cameron’s “justifiable parties” [1], but not just in
    > Cameron’s sense (avoiding disclosure), but more importantly in the
    > sense of avoiding the need for trusting yet another party:

    > Trust is a liability for the entity being trusted, and that liability
    > will cost you dearly in one or another way (or in both).

    > Grüße, Carsten

    > [1]: https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf
    > [is there really no better reference out there?]

I had not read this before, and I read through it, and like it.
How did I miss this before?  Cameron started blogging again this year, btw.
To think that it is 15 years old, and we have so little progress here.

Cameron gives the example that while people were happy to use Passport to
interact with MSN site, they found they didn't want to use Passport to
interact with non-MSN sites.  We see today this in some people's justified
reluctance to Login-With Google/Facebook/Github/etc.  vs having yet another
poorly chosen password to remember and recover.

I'm not entirely certain I understand your comments above.
I think that I should link to some of the Laws in the document, but I'm not
sure how yet.

Tell me how do I discuss the issue of justified parties?
Is it in section 4.1.2 (how keys are generated)?  Or am I misunderstanding?

I can see that end users may wish to not involve the manufacturer when
authenticating the device via it's IDevID.

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