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 <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
> 
> 