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

["Brockhaus, Hendrik" <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
>>> Gesendet: Mittwoch, 4. Februar 2026 22:40
>>> An: [e-mail]<mailto:[e-mail]>
>>> Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>> _______________________________________________
>> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
> _______________________________________________
> Spasm mailing list -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>