[Secdispatch] idevid-considerations at -- SecDispatch/IETF108

[Michael Richardson <[e-mail]>]

Francesca Palombini <francesca.palombini=[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-