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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
