Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009

On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert <tte@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   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 

> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de