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

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > a) Wrt. X.520: From ITU's page:

distraction deleted.

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

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.

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

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.

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

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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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