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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 30 July 2019 22:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6E1201C9 for <anima@ietfa.amsl.com>; Tue, 30 Jul 2019 15:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmtHjk-pX9jO for <anima@ietfa.amsl.com>; Tue, 30 Jul 2019 15:23:39 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614A81201CB for <anima@ietf.org>; Tue, 30 Jul 2019 15:23:39 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 906DF3808A; Tue, 30 Jul 2019 18:23:12 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5042914; Tue, 30 Jul 2019 18:23:37 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>, "Mendelson, Tsippy" <tsippy.mendelson@intel.com>, "anima@ietf.org" <anima@ietf.org>, "Ruan, Xiaoyu" <xiaoyu.ruan@intel.com>, "Jayanna, Prabhu" <prabhu.jayanna@intel.com>
In-Reply-To: <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de>
References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 30 Jul 2019 18:23:37 -0400
Message-ID: <31027.1564525417@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/gb6NXuMT0ezUrVsWVXUlkNd5i8w>
Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 22:23:41 -0000

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.

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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [