Toerless Eckert <[email protected]> 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
