On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote: > > Toerless Eckert <t...@cs.fau.de> 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 [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima