[lamps] Re: draft-housley-lamps-macaddress-on-01.txt

[Michael StJohns <[e-mail]>]

On 10/7/2025 11:54, Russ Housley wrote:
> Mike:
>>>
>>> Section 3:
>>>
>>> Encoding not only the 6-octet and 8-octet variants of MAC addresses,
>>> but also the respective address constraints as octet strings,
>>> where the encoding of constraints effectively carries two different 
>>> kinds of data in double-length strings,
>>> smells a bit like a hack making their use a little cumbersome, but 
>>> keeps the syntax lean.
>>>
>> This is exactly how we do it for IPV4 and IPV6 addresses.  See 
>> Section 4.2.1.10 of RFC5280.   (But wait - Russ - why is the mask 
>> first in the encoding here - that's different than we use for the IP 
>> address - 12th para in this section of 5280?)
>>
> I think you are saying that the NameConstraints certificate extension 
> could carry just the mask.  I think that is a better approach, but the 
> current text capture the discussion from the mail list.
>
> Russ
>
Not quite - I'm saying that the first part should be the value part and 
the second the mask.  You've currently defined this as the first 6 or 8 
bytes have the mask, and the second 6 or 8 bytes the value.  That 
matches up with how the ipAddress  carrying a value and mask is encoded 
from 5280.

This is a style comment rather than a technical comment, but it just 
seems a weird ordering given history.

E.g. let's say you want to encode a "Non-multicast universal" as a name 
constraint.  That would be

[02 00 00 00 00 00 03 00 00 00 00 00] for an EUI48.