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

From: Toerless Eckert <[email-masked]>
Date: Tue, 1 Sep 2020 13:21:12 +0200

This came up trying to respond to Ben Kaduks ACP review
i am just working through and me stumbling across the BRSKI reference:

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].

[rant]
Instead of the real serialNumber, [RFC5280] has "explicitly tagged" attributes
called X520<name> in A.1, including X520SerialNumber. But without explanation.
So i am not sure what those are and if in the IETF certificate language one
would need to refer to any such attributes as X520<name>. I have certainly
never seen any router CLI using any such X520<name>...

Grep'ing through all RFCs i could not find any mentioning of X520<name>
other than in the few RFC that define their ASN.1, such as [RFC5280].
So i wouldn't dare to mention any such name before finding an explanation
for them. 
[/rant]

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"

i have no idea if this would be right given that A.1 only has X520SerialNumber.

Cheers
    Toerless

In-Reply-To: <[email-masked]>

On Tue, Sep 01, 2020 at 07:58:52AM +0000, Werner, Thomas wrote:
> Thanks, just one small change, the refinement of "voucher/pinned-domain-cert" should read: 
> 
>       refine "voucher/pinned-domain-cert" {
>         mandatory false;
>         description "A pinned-domain-cert field
>                      is not valid in a voucher request, and
>                      any occurrence MUST be ignored";
>       }
> 
> Best regards
> Thomas
> 
> -----Ursprüngliche Nachricht-----
> Von: Michael Richardson <[email-masked]> 
> Gesendet: Montag, 31. August 2020 22:01
> An: [email-masked]
> Cc: Werner, Thomas (CT RDA CST SEA-DE) <[email-masked]>
> Betreff: Re: BRSKI#43, Figure 5 YANG Tree diagram for Voucher-Request
> 
> 
> Thomas has pointed out that the "pinned-domain-cert" and "last-renewal-date"
> fields which are defined in RFC8366 are not clearly specified for the voucher-request.
> 
> Neither are needed or appropriate in a voucher-request.
> I have edited the YANG to include:
> 
>       refine "voucher/pinned-domain-cert" {
>         mandatory false;
>         description "A voucher-request field
>                      is not valid in a voucher request, and
>                      any occurrence MUST be ignored";
>       }
> 
>       refine "voucher/last-renewal-date" {
>         description "A last-renewal-date field
>                      is not valid in a voucher request, and
>                      any occurrence MUST be ignored";
>       }
> 
> This is, I think, an editorial change.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Sep 2020 21:43:49 -0400

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

    > [RFC4519] used in BRSKI as an example for a serialNumber, it point correctly

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.

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

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

commit c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99
Author: Michael Richardson <[email-masked]>
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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Sep 2020 19:00:59 +0200

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

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Sep 2020 15:34:34 -0400

> a) Wrt. X.520: From ITU's page:

distraction deleted.

    > summary how this relates to the issue i brought up ?

The serial number originally came from a variety of places, but at:
   https://mailarchive.ietf.org/arch/msg/anima/vpItLADnu-2Ea-uB0A9fHjia4hw/

We agreed to remove that and just go for the X520SerialNumber DN.
But, I goofed and cited the wrong section.

    > (except for the ASN.1 rfcs about them].

Yup.  Because it's the DN "serialNumber", not the X520SerialNumber.
RFC5280 is no so clear about that.  Maybe X520 has more detail, I don't know.
But, the OID has been around for a long time:

%cat reach/spec/files/product/00-D0-E5-F2-00-02/device.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 226876461 (0xd85dc2d)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA
        Validity
            Not Before: Feb  3 06:47:20 2020 GMT
            Not After : Dec 31 00:00:00 2999 GMT
        Subject: serialNumber = 00-D0-E5-F2-00-02
        ...

Yes, my testing serialNumber is a mac address based upon a dead company's OUI allocaiton)
My *Certificate Serial Number* is: 226876461 which is a PRNG result.

    > IETF process steps we're just doing for the other BRSKI fix....

This probably a reasonable AUTH48 fix that would require AD approval.
The AD could approve it beforehand.
As a process, once the rename occurs (or does not), I will post a document
with the changes, and ask the AD to approve those changes.
Whether we have to "physically" slip them in at AUTH48, or can give them to
the RFC-editor beforehand, is probably unimportant.

If this WG are okay with my proposed text, I'll ask Sean Turner+LAMPS to review
it, and tell me what was imprecise.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Sep 2020 08:40:29 +1200

> 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.

> 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