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

Toerless Eckert <> Tue, 30 July 2019 23:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ACDF12010E for <>; Tue, 30 Jul 2019 16:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p4o3K5NAj2fu for <>; Tue, 30 Jul 2019 16:11:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DCED12007C for <>; Tue, 30 Jul 2019 16:11:41 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 7711B548342; Wed, 31 Jul 2019 01:11:36 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 5F144440041; Wed, 31 Jul 2019 01:11:36 +0200 (CEST)
Date: Wed, 31 Jul 2019 01:11:36 +0200
From: Toerless Eckert <>
To: Michael Richardson <>
Cc: "Mendelson, Tsippy" <>, "" <>, "Ruan, Xiaoyu" <>, "Jayanna, Prabhu" <>
Message-ID: <>
References: <> <> <> <31027.1564525417@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <31027.1564525417@localhost>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jul 2019 23:11:43 -0000

On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
> Toerless Eckert <> 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.


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


> 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


> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]        |   ruby on rails    [

> _______________________________________________
> Anima mailing list