Re: [Anima] BRSKI#43, serial-number

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 September 2020 01:43 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 A70BF3A09BB for <anima@ietfa.amsl.com>; Tue, 1 Sep 2020 18:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J9SzseCyDkOR for <anima@ietfa.amsl.com>; Tue, 1 Sep 2020 18:43:52 -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 4FACF3A09BD for <anima@ietf.org>; Tue, 1 Sep 2020 18:43:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 75F5A389D0; Tue, 1 Sep 2020 21:22:47 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I_yuJe7GCxB9; Tue, 1 Sep 2020 21:22:45 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A690C389CF; Tue, 1 Sep 2020 21:22:45 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 763E9516; Tue, 1 Sep 2020 21:43:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>, "anima\@ietf.org" <anima@ietf.org>
In-Reply-To: <20200901112112.GA15609@faui48f.informatik.uni-erlangen.de>
References: <20200901112112.GA15609@faui48f.informatik.uni-erlangen.de>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512; protocol="application/pgp-signature"
Date: Tue, 01 Sep 2020 21:43:49 -0400
Message-ID: <21905.1599011029@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/lqaaqxPkyOfjiG2eYjhN8MmMf4I>
Subject: Re: [Anima] BRSKI#43, serial-number
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: Wed, 02 Sep 2020 01:43:55 -0000

I seem to remember requests for clarification many months, and I wonder if it
was part of a different piece.
    https://mailarchive.ietf.org/arch/msg/anima/mBNQoRCTECyQ0G-D9AnEWgLaHUc/
    https://mailarchive.ietf.org/arch/msg/anima/vpItLADnu-2Ea-uB0A9fHjia4hw

confusingly, we discussed rfc5280 4.2.1.2 a bunch, but not 4.1.2.2.
It looks like as a result of the thread starting at:
** https://mailarchive.ietf.org/arch/msg/anima/oR0POVwZ24EZEVD3S4XCXdNmtSE/
and specifically https://mailarchive.ietf.org/arch/msg/anima/8Ys6ctjFeyINat_BGg860b04I3E/
That made me rewrite that section, and it appears that I did too quick a
search of RFC5280.

It's a tribute to this Internet thing we built that the tinyurl.com in the **
noted email leads to:
  https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-24&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/master/dtbootstrap-anima-keyinfra.txt

Which works great, and show you the text that got replaced.
However, the above link will likely give you a different result as I'm about
to push the fix to the fix.

Try, instead:
  https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-24&url2=draft-ietf-anima-bootstrapping-keyinfra-43

Toerless Eckert <tte@cs.fau.de> wrote:
    > BRSKI section 2.3.1:

    > | The serialNumber field is defined in [RFC5280].  That specification
    > | allows for the field to be omitted if there is a good technical
    > | reason.  IDevID certificates for use with this protocol are REQUIRED
    > | to include the "serialNumber" attribute with the device's unique
    > | serial number (from [IDevID] section 7.2.8, and [RFC5280] section
    > | 4.1.2.2's list of standard attributes).

    > The serialNumber field defined in [RFC5280] 4.1.2.2 is not the subject
    > DN serialNumber (a string) that we want to talk about, but the certificate serial
    > number (a number). That serialNumber string is actually defined in [X.520],
    > for which BRSKI does unfortunately not have a reference. See for example
    > [RFC4519] used in BRSKI as an example for a serialNumber, it point correctly
    > to [X.520].

X.520 is behind an impossible to use paywall. From what I can tell, it's
actually run on a for-profit basis within each national boundary, and the one
within my national boundary is incompetent.
I am of the opinion that the ITU is violating the UN convention on human
rights when they do this.
So, to me, any X520 reference will result in less understanding rather than more.

I find the text in 2.3.1 paragraph two of BRSKI, which you quote to be startlingly wrong.
As you say, that's not the id-at-serialNumber we were looking for, and the
one we want is defined in RFC5280 as X520SerialNumber.

The example of RFC4519, section 2.31 is a correct reference.

    > Aka: I am not sure exactly what the minimum editorial fix is:

    > "The serialNumber field is defined in [RFC5280]"

    > This is AFAIK not correct unless A.1 definition of X520SerialNumber can
    > be represented as definition of serialNumber. More easily, serialNumber is
    > defined in [X.520]

    > "and [RFC5280] section 4.1.2.2's list of standard attributes"

    > this is wrong.

    > "and [RFC5280] section A.1's list of standard attributes"

https://github.com/anima-wg/anima-bootstrap/commit/c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99

commit c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99
Author: Michael Richardson <mcr@sandelman.ca>
Date:   Tue Sep 1 21:25:05 2020 -0400

    fix section 2.3.1 to point at X520SerialNumber

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index d655d69..9739945 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -799,18 +799,24 @@ INSERT_TEXT_FROM_FILE component-diagram.txt END
           </t>

           <t>
-            The serialNumber field is defined in <xref target="RFC5280" />.
-            That specification allows for the field to be omitted if there is
-            a good technical reason. IDevID certificates for use
-            with this protocol are REQUIRED to include the "serialNumber" attribute with the device's
-            unique serial number
-            (from <xref target="IDevID" /> section 7.2.8, and
-            <xref target="RFC5280" /> section 4.1.2.2's list of standard
-            attributes).
-          </t>
-          <t>
-            The serialNumber field is used as follows by the pledge to build the
-            "serial-number" that is placed in the voucher-request.
+            There is a (certificate) serialNumber field is defined in <xref
+            target="RFC5280" /> section 4.1.2.2.  In the ASN.1, this is
+            referred to as the CertificateSerialNumber.  This field is NOT
+            relevant to this specification.  Do not confuse this field with
+            the "serial-number" defined by this document, or by
+            <xref target="IDevID" /> and <xref target="RFC4519" /> section
+            2.31.
+          </t>
+
+          <t>
+            The device serial number is defined in <xref target="RFC5280" />
+            section A.1 and A.2 as the X520SerialNumber, with the OID tag
+            id-at-serialNumber.
+          </t>
+          <t>
+            The device serial number field (X520SerialNumber) is used as
+            follows by the pledge to build the "serial-number" that is placed
+            in the voucher-request.
             In order to build it, the fields need to be converted into a
             serial-number of "type string".
           </t>
@@ -821,8 +827,7 @@ INSERT_TEXT_FROM_FILE component-diagram.txt END
           </t>
           <t>
             Due to the reality of existing device identity provisioning
-            processes, some
-            manufacturers have stored serial-numbers in other
+            processes, some manufacturers have stored serial-numbers in other
             fields. Registrar's SHOULD be configurable, on a per-manufacturer
             basis, to look for serial-number equivalents in other fields.
           </t>

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-