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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 03 September 2020 20:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 DC4253A0DCB for <anima@ietfa.amsl.com>; Thu, 3 Sep 2020 13:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level:
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 eLRgd87YGN0J for <anima@ietfa.amsl.com>; Thu, 3 Sep 2020 13:40:34 -0700 (PDT)
Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D756F3A0DCA for <anima@ietf.org>; Thu, 3 Sep 2020 13:40:34 -0700 (PDT)
Received: by mail-pj1-x1044.google.com with SMTP id gf14so2022865pjb.5 for <anima@ietf.org>; Thu, 03 Sep 2020 13:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UzwASl5PK2gfBIDr14v9izFhfLT9hK1GnAx5P7QrGvM=; b=c1ZyOBerPtuJ66L+IIgxGZABFaJ8Lxv3N2SJKZKBOY3onlDyZH3cGldiNkhCpvzeB/ 4n2/I6ZGcpoRaAcXWUz/4LV4rf3hza0820eDAbI8N6liRcUC5vQV76qjqWb3IgjwaXf4 shbMyjdpvPwH3chEunCrYTNxN2iYfkKItbEehrnmO/QvIo/WbUVsJUCSO58yg0YuPBW9 lhy8I1fQw9Xd+978vSyNwky9A9pHS31dpqepn/WDLZ4NtLNlyU1D0mPd1oMGSTmJx55n WV+XsfuuCSwym4JGPDe+Szm6u5zsf+3Bw4vbrd6iAHwVxiZ+Y2P37yvgtu32s0/DNbV9 PBDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UzwASl5PK2gfBIDr14v9izFhfLT9hK1GnAx5P7QrGvM=; b=k/n9XnYRRkH0agS2qr3An1PaY9iColcYmLWkmpOgU2EroX3ibOoRcQLh0MUCndPW7A wkQcTjvajPzGHPqMeYEbPfFd8wLwvdxPzg4Yd40Wuq64MlSeF28+OuxlURIu86uaPxm/ r/lAVOpkIgS9r8WyMpdowl8FflW6i/u5U6VWLZAYdylhcGj+3tonu3+IgSrHTMDAl6rj LaQyNs5flzCcR2+ii4bj3u3y4YEUK2FAlMRjvPlZYV45NSMwzDOVkDRvMCW2JHpCwyxL LJQPRtpDU0wSTon1DOo+8Q8UFIpIyurfDkcsdFOjMIke0kcUBq//6EDhXrgwqi0E4hwb vF3w==
X-Gm-Message-State: AOAM531ZPCrxMg3SiuHNQJsYZLrVd/H88uM1CIeZR0tUCblussObRsHq 0Hx6BujJgnhAlz3LRCORVdwnPseqxc+MPg==
X-Google-Smtp-Source: ABdhPJxnGJkCY8QWNT3Usri4vdzOXrBiB8DFq0q4VXju3nJAd/qKgoCkOVC2uWAM5Wj3Nxv6tR/TMw==
X-Received: by 2002:a17:90a:bd02:: with SMTP id y2mr4977242pjr.66.1599165633865; Thu, 03 Sep 2020 13:40:33 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id lh6sm3147669pjb.15.2020.09.03.13.40.32 for <anima@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Sep 2020 13:40:33 -0700 (PDT)
To: anima@ietf.org
References: <20200901112112.GA15609@faui48f.informatik.uni-erlangen.de> <21905.1599011029@localhost> <20200903170059.GA21861@faui48f.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <d8c9db3a-e11b-381a-3b97-94d5e9e0030b@gmail.com>
Date: Fri, 4 Sep 2020 08:40:29 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200903170059.GA21861@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/8LdnFt-CxNgrJ5_q1jp0jKSuX4w>
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: Thu, 03 Sep 2020 20:40:37 -0000

On 04-Sep-20 05:00, Toerless Eckert wrote:
> inline..
> 
> a) Wrt. X.520: From ITU's page:
> 
> | This text was produced through a joint activity with ISO and IEC. 
> | According to the agreement with our partners, this document is only available through payment.
> 
> Of course, ITU shouldn't enter into such partnership, but given how common
> public-private partnerships are in western governments, its hardly unusual.

The IETF has many, many normative references to ITU recommendations despite their
paywall, and has done for 30 years or so.

> Given how all certificate work in IETF is based off X.500 certificates, it would be
> a great job for the IETF/ITU-T liaison to see how IETF work could get free access
> to the according ITU-T documents.

I don't think we should worry about it at WG level. There's no standards process
problem in citing ITU-T documents.

    Brian

> 
> b) I am confused about your text up to the diff -24 to -43. Is there an executive
>    summary how this relates to the issue i brought up ?
> 
> c) Of course, you are welcome trying to avoid X.520 and instead step into X520SerialNumber,
>    so your diff is fine to me.
> 
>    [ The fixes i am proposing to Ben re serialNumber in ACP
>      will attempt to avoid X520SerialNumber because i don't even understand how this
>      explicit tagging works and no CLI/document has ever used these terms
>      (except for the ASN.1 rfcs about them].
> 
> d) I am mostly wondering if/how changes like this would go into the final BRSKI RFC
>    given its state in RFC editor queue. I don't understand what type of text
>    fixes will be accepted as just editorial, not requiring the whole shebang of
>    IETF process steps we're just doing for the other BRSKI fix....
> 
> Cheers
>     Toerless
> 
>> 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.
> 
> On Tue, Sep 01, 2020 at 09:43:49PM -0400, Michael Richardson wrote:
>>
>> 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 =-
>>
>>
>>
> 
> 
> 
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
>