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

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
> 
> 
> 
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
> 
>