[Lwip] IDevID considerations document to secdispatch

[Michael Richardson <[e-mail]>]

Dear Secdispatch chairs and WG, (and various people in the BCC who are
encouraged to forward)

EXEC SUM:  https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

While working on ANIMA's BRSKI enrollment system, and the associated
mechanisms that create the ACP, it became clear that there was possibly a
wealth of useful advice on operating the Manufacturer and Owner components
(the MASA and Registrar).  As these thoughts grew, it became clear that there
were many non-normative, non-wire-protocol level design considerations.
Two documents were originally created:
    a) draft-richardson-anima-masa-considerations
    b) draft-richardson-anima-registrar-considerations

Both situations involve operation of a certificate authority.
On the manufacturer side, this involves the Manufacturer Installed
Certificate, the IDevID.  There are multiple users of the IDevID and there
are many entities building a variety of trust models based upon having
that trust model.  For instance, the Kumari/Doyle Secure Device
Install/draft-ietf-opsawg-sdi-12 leverages built-in certificates as much as
BRSKI does.

Much of the RATS work requires some kind of known signing key to
be built-in, secured deep into a hardware or firmware TPM/enclave.
If you want to (asymmetrically) encrypt firmware for SUIT, you may need
keys built in too.  Many other protocols also depend upon keys to be deployed,
but can deal with having them deployed as part of configuration, but as we
all experienced, actually getting them deployed can be difficult.

As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few WGs, there
seems to be three ways to deploy matching private-key/certificates. a)
generate key onboard, sign with EST/SCEP/CMP/magic<%>, b) generate keypair in
CA, deploy with EST/SCEP/JTAG/magic, c) simultaneously/deterministically
generate keypair from shared secret, deploy certificate via magic.
I don't have good names for these three methods, nor sufficient proof that
there isn't a reasonable fourth method.    One reason (among many) to have
names for these three methods is so that it is possible in Supply Chain
Security discussions to be able to easily state the inherent security vested
in the device, and to thus #include the risk/threat landscape of devices
(particularly MCUs) that are included in designs.

I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some lightweight
profile of CMP (such as is in LAMPS) are reasonable protocols for factory
time onboarding, but require very strict profiling to get right.  This makes
it IETF business.
I would want to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally
said champion would be describing active experience from a real factory.

As publically anchored enterprise (intermediate) CAs seem to be a thing of
the past, many have discussed how appropriate it might be for manufacturers
to use ACME to provision IDevIDs directly. {In fact, I have running code}

There are however many aspects of this effort which might reasonably be
considered outside of the IETF perview.  Fundamentally, these are PKIX
objects that are being provisioned, and it is at the IETF that potential
successors to PKIX (CoID, JWTs, etc.) are being developed.

One of the major difficulties I have experienced in trying to assemble this
document is that current methods are often buried in a Silicon
vendor/OEM-board vendor interaction fearing many NDAs. This is particularly
acute for method (c).  This makes it difficult to ascertain what level of
care has been taken with the sensitive symmetric keys, which results in a
difficulty to compare audit results across the industry.

In order to get better and wider review, as well as detailing the required
magic, I've split the MASA considerations document into two pieces.
One is BRSKI MASA RFC8366 voucher generation specific, which I intend to
leave in the ANIMA WG (should the chairs agree), and the other part which is
IDevID generation specific, which I am looking for advice from secdispatch to
determine what to do with it.

The second document is:
  https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

and it is still rather drafty.

I will note that draft-richardson-anima-registrar-considerations also
discusses an Operator/Enterprise/Home-router having/operating a CA,
(among many other things), and I am undecided whether or not to extract
that advice and merge it into idevid-considerations.  At this point, I think
that it is not of general interest and it is better kept isolated.



<%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well.

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