[lamps] Re: I-D Action: draft-ietf-lamps-macaddress-on-05.txt

[Michael StJohns <[e-mail]>]

Hi Hendrik -

Probably not.  It's a language standard and we already refer to the 
ASN.1 documents.  The fact that I didn't identify that to you for your 
earlier comment was due to me having a cold and lack of sleep.

Mike


On 2/23/2026 02:21, Brockhaus, Hendrik wrote:
>
> Mike
>
> Thank you for the clarification.
>
> Would that be worth a Note that expresses that in the document?
>
> Hendrik
>
> *Von:*StJohns, Michael <[e-mail]>
> *Gesendet:* Freitag, 20. Februar 2026 18:49
> *An:* [e-mail]
> *Betreff:* [lamps] Re: I-D Action: draft-ietf-lamps-macaddress-on-05.txt
>
> Actually - as I thought when I wrote it (and have now confirmed) a 
> hexadecimal literal may contain any amount of white space between the 
> two apostrophes.  So this ended up being a NO CHANGE MEEDED.
>
> Mike
>
> Ps x.680 12.12.2
>
> On Thu, Feb 5, 2026 at 10:42 Michael StJohns <[e-mail]> 
> wrote:
>
>     Hi Russ/Hendrik -
>
>     I blame this on me.  I had the spaces in there when I was writing
>     this
>     section so I wouldn't keep screwing up my count ;of the "00"
>     octets and
>     always meant to remove them, but got distracted.
>
>
>     That said, it does make it easier for a reader to follow the
>     examples,
>     even it its invalid coding so Russ' suggestion of a note is probably
>     useful.  Perhaps?:
>
>     "Note: While an ASN.1 OCTET STRING literal can't contain any
>     spaces and
>     must contain an even number of hexadecimal digits some OCTET STRING
>     literals in the examples below may contain a space between the
>     value and
>     mask octets.  This was done to make the examples more readable.  The
>     spaces should be removed if you wish to use any of the examples in
>     compilable ASN.1."
>
>     In you comments, note that the first one is describing the
>     encoding and
>     omits the space, while the second isn't talking about the
>     encoding, but
>     the math.
>
>     Later, Mike
>
>
>     On 2/5/2026 10:29, Russ Housley wrote:
>     > Hendrik:
>     >
>     > There is not space in the value carried in the OCTET STRING.  I
>     find the space easier for the human to see the two parts.  Do you
>     think a note is needed to make this clear?
>     >
>     > Russ
>     >
>     >
>     >> On Feb 5, 2026, at 4:17 AM, Brockhaus, Hendrik
>     <hendrik.brockhaus=[e-mail]> wrote:
>     >>
>     >> I have read the draft. Thank you very much for defining a
>     standardized way to encode MAC addresses as part of the name in
>     certificates.
>     >>
>     >> I have one question about encoding name constraints.
>     >> In Section 3.2, value and mask bit patterns are encoded
>     directly after each other.
>     >> "a mask part of 'FFFFFFFF000000'H and would be
>     >> encoded as OCTET STRING '00005E000000FFFFFF000000'H."
>     >>
>     >> In other places, value and mask bit patterns are separated by a
>     space.
>     >> See, for example, Section 3.4.10
>     >> "For example, a constraint of '000000000000 030000000000'H will be
>     >> matched by any universal/unicast EUI-48 address such as
>     00-00-5e-00-
>     >> 50-34. A constraint of '00005E000000 FFFFFF000000'H will be matched
>     >> by any universal/unicast address with a OUI of 00-00-5E - i.e., it
>     >> will also match 00-00-5e-00-50-34. Note that '00-00-5E' is an OUI
>     >> controlled by IANA."
>     >>
>     >> What is the correct encoding?
>     >>
>     >> Hendrik
>     >>
>     >>> -----Ursprüngliche Nachricht-----
>     >>> Von: [e-mail] <[e-mail]>
>     >>> Gesendet: Mittwoch, 4. Februar 2026 22:40
>     >>> An: [e-mail]
>     >>> Cc: [e-mail]
>     >>> Betreff: [lamps] I-D Action: draft-ietf-lamps-macaddress-on-05.txt
>     >>>
>     >>> Internet-Draft draft-ietf-lamps-macaddress-on-05.txt is now
>     available. It is a work
>     >>> item of the Limited Additional Mechanisms for PKIX and SMIME
>     (LAMPS) WG of the
>     >>> IETF.
>     >>>
>     >>>   Title:   Media Access Control (MAC) Addresses in X.509
>     Certificates
>     >>>   Authors: Russ Housley
>     >>>            Corey Bonnell
>     >>>            Joe Mandel
>     >>>            Tomofumi Okubo
>     >>>            Michael StJohns
>     >>>   Name: draft-ietf-lamps-macaddress-on-05.txt
>     >>>   Pages:   15
>     >>>   Dates:   2026-02-04
>     >>>
>     >>> Abstract:
>     >>>
>     >>>   This document defines a new GeneralName.otherName for
>     inclusion in
>     >>>   the X.509 Subject Alternative Name (SAN) and Issuer
>     Alternative Name
>     >>>   (IAN) extensions to carry an IEEE Media Access Control (MAC)
>     address.
>     >>>   The new name form makes it possible to bind a layer-2 interface
>     >>>   identifier to a public key certificate.  Additionally, this
>     document
>     >>>   defines how constraints on this name form can be encoded and
>     >>>   processed in the X.509 Name Constraints extension (NCE).
>     >>>
>     >>> The IETF datatracker status page for this Internet-Draft is:
>     >>> https://datatracker.iet/
>     >>> f.org <http://f.org/>%2Fdoc%2Fdraft-ietf-lamps-macaddress-
>     >>> on%2F&data=05%7C02%7Chendrik.brockhaus%40siemens.com
>     <http://40siemens.com/>%7C246ee67e8b1
>     >>> 34707b57b08de64360606%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
>     >>> 7C639058380367010418%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>     >>>
>     RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
>     >>> %3D%7C0%7C%7C%7C&sdata=crM3Vx4kY3JHgqXWDiE12dcIkTlQEF33WLYHmb
>     >>> 0s43k%3D&reserved=0
>     >>>
>     >>> There is also an HTML version available at:
>     >>>
>     https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%25
>     >>> 2Farchive%2Fid%2Fdraft-ietf-lamps-macaddress-on-
>     >>> 05.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com
>     <http://40siemens.com/>%7C246ee67e8b1
>     >>> 34707b57b08de64360606%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
>     >>> 7C639058380367034484%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>     >>>
>     RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
>     >>> %3D%7C0%7C%7C%7C&sdata=Xpad99tStO6DbLN54d2aWRy0G3ur9W6xBjc1U1T
>     >>> 6DxY%3D&reserved=0
>     >>>
>     >>> A diff from the previous version is available at:
>     >>> https://author-/
>     >>> tools.ietf.org
>     <http://tools.ietf.org/>%2Fiddiff%3Furl2%3Ddraft-ietf-lamps-macaddress-on-
>     >>> 05&data=05%7C02%7Chendrik.brockhaus%40siemens.com
>     <http://40siemens.com/>%7C246ee67e8b13470
>     >>> 7b57b08de64360606%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63
>     >>> 9058380367051470%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
>     >>>
>     UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
>     >>> 7C0%7C%7C%7C&sdata=pOBAy6SDg6Tjbyt8q7Vk2atNuucHvb87pCv5YXQVf7c%3
>     >>> D&reserved=0
>     >>>
>     >>> Internet-Drafts are also available by rsync at:
>     >>> rsync.ietf.org::internet-drafts
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Spasm mailing list -- [e-mail]
>     >>> To unsubscribe send an email to [e-mail]
>     >> _______________________________________________
>     >> Spasm mailing list -- [e-mail]
>     >> To unsubscribe send an email to [e-mail]
>     > _______________________________________________
>     > Spasm mailing list -- [e-mail]
>     > To unsubscribe send an email to [e-mail]
>