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

[Toerless Eckert <[e-mail]>]

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.

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.

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


-- 
---
[e-mail]