Re: [lamps] IDevID considerations document to secdispatch

[Tomas Gustavsson <[e-mail]>]

Hi Michael,

It's a good read. One thing confuses me a bit.
Please allow for ignorance on my part as my knowledge about
manufacturing processes is limited

The notion of serialNumber in the document, for me, reads as it's not
clear what is the certificate serial number (9-19 bytes in your
document) and the device serial number. There don't have to be the
same. What I have seen commonly used is that the subjectDN field is
used to carry the device serial number, while the certificate serial
number is random, and only used to uniquely identify the certificate
in the PKI (issuer/serial).
In such a case I would assume that the manufacturing execution system
(MES) and it's database controls the device serial number, while the
PKI controls the certificate serial number, and there does not have to
be any synchronization between these two.

Regards,
Tomas


On 2020-06-10 17:51, Michael Richardson wrote:
> 
> 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 =-
> 
> 
> 
> 
> _______________________________________________ Spasm mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/spasm
>