Hi, My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE 802.1AR recommends this but BRSKI enforces this - makes this a MUST.
But behind the scenes this question was coming from considerations related to complexity that this adds to the manufacturing flow when required to provision every device with a certificate that includes its Serial Number :-). This creates usability and security issues on the manufacturing line. We are devising a solution for this manufacturing problem by using an embedded CA in a RoT / Hardware TEE in the platform for this purpose - but there are concerns with this implementation as well. Therefore I wanted to clarify this requirement. (Although I agree that it makes perfect sense). Regarding: " If you just let the device generate a public key pair and you simply capture the public key during manufacturing, maybe that is a significant simplification when you talk 10 million devices" This is a very interesting remark as we are actually thinking of a solution where the Platform Identifier in the Ownership Voucher (that the OEM uploads to their inventory from the manufacturing line) would include 2 components: 1. The Serial Number assigned by the OEM to the platform - this could be a Service Tag or perhaps a hash of all serial numbers of devices included in the platform - or something else the OEM chooses - but as it can be a hash we allocate 32 bytes for it. 2. A hash of the Public Key of a key pair that is generated by the Platform RoT for identity / TEE - this would be the public key in the IDevID certificate. When using an embedded CA (in the RoT hardware) to issue IDevID certificates, this would be the Public Key in the certificate of the embedded CA that the IDevID Certificate is rooted to. Altogether 64 bytes. Using an embedded CA enables revoking and replacing the key and certificate used for identity attestation easily, after a FW update that increases the security version number. Regards, Tsippy -----Original Message----- From: Brian E Carpenter [mailto:[email protected]] Sent: Wednesday, July 31, 2019 05:18 To: Toerless Eckert <[email protected]>; Michael Richardson <[email protected]> Cc: Jayanna, Prabhu <[email protected]>; Mendelson, Tsippy <[email protected]>; [email protected]; Ruan, Xiaoyu <[email protected]> Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 Let's be clear in the BRSKI text that our standard makes this a MUST *even if* it is not mandatory in the IEEE standard. Of course we can do that (and not including the serial number seems very sloppy), but we should be explicit that our requirement is stronger than the IEEE. Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think we care, because our model is that nodes containing management smarts such as an ASA need to join the ACP, but managed nodes themselves do not. Regards Brian On 31-Jul-19 11:11, Toerless Eckert wrote: > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote: >> >> Toerless Eckert <[email protected]> wrote: >> > From what i understand (and please correct me if you are coming from a >> > different angle), you may be able to reduce cost in manufacturing of >> > low-cost and/or constrained device by not having to have IDevID >> >> I didn't get that all from the original poster. >> I think you are jumping to a conclusion that is not supported by text here. > > Yes, i was elaborating about why one would want an IDevID without the > serialNumber and what would need to happen to support that. But i also > said this should be out of scope for the current BRSKI document. > >> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather >> a SHOULD. >> And, that's not the point at all, really. >> IF you want to do BRSKI, then you MUST include a serialNumber in the DN. > > Agreed. > >> 802.1AR-2009, has section 7.2.8: >> >> 7.2.8 subject >> The DevID subject field shall uniquely identify the device associated >> with the particular DevID credential within the issuer???s domain of >> significance. The formatting of this field shall contain a unique X.500 >> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer or any other suitable unique DN >> value that the issuer prefers. In the case of a third-party CA or a >> standards certification agency, this can contain the manufacturer???s >> identity information. >> >> The subject field???s DN encoding should include >> the ???serialNumber??? attribute with the device???s unique serial >> number. >> >> Note lack of RFC2119 language (or a reference to it). >> >> So if the 2018 has "SHOULD" here, then that's a strengthing of the >> language, not a weaking. >> The first paragraph does have weasel words "any other suitable unique >> DN", but > > Ok, i currently can't access the IEEE standards, so i can not compare > myself. My reading of the OP was that it was a weakening. > > >> I really think that a serialNumber DN attribute (as opposed to the >> serialNumber certificate attribute) is needed for BRSKI to >> interoperate well. > > Agreed. > >> If someone has a 10 million devices in the field which can be field >> upgraded to run BRSKI (while still in a not-yet enrolled state in a >> box), then let's talk about this. Maybe it's actually 10,000,000 TPM >> devices with IDevIDs already generated, but no serialNumber in it. >> Getting the JRC code right to do other things can be a pain, but it can be >> done. > > Right, this was my question to the OP as well. I was guessing its more > about minimizing cost for future built 10 million devices. Today you > would need to burn-in during manufacturing identity elements such as > specifically the serialNumber, so you need to devise a protected > burn-in process. If you just et the device generate a public key pair > and you simply capture the public key during manufacturing, maybe that > is a significant simplification when you talk 10 million devices. Just > guessing. In any case, serialNumber is a lot more useful when humans > are involved, but they may become less relevant when everything is > automated. > > Cheers > Toerless > >> -- >> ] Never tell me the odds! | ipv6 mesh networks >> [ >> ] Michael Richardson, Sandelman Software Works | IoT architect >> [ >> ] [email protected] http://www.sandelman.ca/ | ruby on rails >> [ >> > > > >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > > --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
