Subject: [T2TRG] idevid-considerations at -- SecDispatch/IETF108

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2020 23:34:58 -0400

Francesca Palombini <francesca.palombini=[email-masked]> wrote:
    > The SECDISPATCH WG met on Thursday July 30.  The agenda items were dispatched as follows:

    > (1) IDevID considerations (Michael Richardson)
    > * specification: https://tools.ietf.org/html/draft-richardson-secdispatch-idevid-considerations-00
    --> Needs vendor involvement - get more people from the industry and then
    > possibly bring it back.

Hi, so I heard the feedback strongly to go talk to more
industrial/manufacturing types.

It was also suggested that T2TRG would welcome it.
  https://mailarchive.ietf.org/arch/msg/t2trg/E05g95AX3DUlS0_mBQH4DwcfLBc/

with a possible title of:
  A Toxonomy of Operational Security of manufacturer installed keys and anchors

A pointer was sent me about RFC6711:
   An IANA Registry for Level of Assurance (LoA) Profiles

This might be fine as a place to store/reference the palette of mechanisms,
but it does not, I think, help in creating the content of each palette.

It references: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html
But, I didn't quite understand it.  I think that it's about communicating between
verifiers and relying parties, the degree to which the verifier has validated
the identity of a SAML Identity.

Kantara Initiative Identity Assurange Framework (KIIAF) was referenced, and
Kantara Initiative was also mentioned by private message during secdispatch.
Kantara is, as far as I can understand, a conformity assessment and assurance
entity, which works against NIST 800-63-3.
I hope to have further conversations with them.

So, going to that NIST document, which was also mentioned:
   https://pages.nist.gov/800-63-3/

This document has a lot of commonalities, but yet it is not about how keys
are protected.  It is about how to communicate about the confidence an entity
has about the identities it is asserting.  It is "Identity Proofing" for humans.

Now, NIST SP 800-63B _Authentication and Lifecycle Management_, has lots and
lots of good stuff.  Nothing that says how to evaluate how many intermediate
CAs are appropriate when issuing certificates to put into the hardware authenticators.

It's clear that this document is relevant to a manufacturer who might need to
consider how to authenticate and authorize access to private keys.  For
instance, AAL2 (maybe even AAL3) is probably appropriate for access to the
signing key for a software update.  (There is an interesting recursive
element here where where cryptographic authenticators are used...)

NIST Special Publication 800-63C: _Digital Identity Guidelines: Federation and Assertions_
deals in SAML, OpenID Connect, and Kerberos, at the level of assertions, not
keys.  Really nice diagrams.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Aug 2020 18:46:21 -0400

>    A Toxonomy of Operational Security of manufacturer installed keys and anchors

I have re-posted with a new name, and title:

https://datatracker.ietf.org/doc/draft-richardson-t2trg-idevid-considerations/

  A Toxonomy of operational security of manufacturer installed keys and
                                 anchors
             draft-richardson-t2trg-idevid-considerations-00

Abstract

    This document provides a toxonomy of methods by manufacturers of
    silicon and devices secure private keys and public trust anchors.
    This deals with two related activities: how trust anchors and private
    keys are installed into devices during manufacturer, and how the
    related manufacturer held private keys are secured against
    disclosure.

    This document does not evaluate the different mechanisms, but rather
    just serves to name them in a consistent manner in order to aid in
    communication.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Aug 2020 02:27:31 +0200

Good start, Michael.

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.

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.

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?

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.

Grüße, Carsten

> On 2020-08-19, at 00:46, Michael Richardson <[email-masked]> wrote:
> 
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Aug 2020 02:54:33 +0200

On 2020-08-25, at 02:27, Carsten Bormann <[email-masked]> 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?]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Aug 2020 16:38:50 -0400

Carsten Bormann <[email-masked]> 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.

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

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