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.
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.
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 I really think that a serialNumber DN attribute
(as opposed to the serialNumber certificate attribute) is needed for BRSKI
to interoperate well.
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.
--
] 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 [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
