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
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
