Media Access Control (MAC) Addresses in X.509 Certificates
draft-ietf-lamps-macaddress-on-07

Thanks to Murray Kucherawy for the ARTART review.

Thanks for the work done in this document, and knowing the authors, no wonder that both 48-bit and 64-bit MAC addresses are supported.

Thanks also to Jacqueline McCall for the IoT-directorate review and the follow-up by the authors.

Final thanks to David Lou for the INT-directorate review.

Thanks to the authors and the WG for their work on this document.

I have a couple of comments about the IANA considerations:

1) Please identify the registry group under which those registries are located. In this case, I believe it is "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" ?

2) id-mod-mac-address-other-name-2025 should be id-mod-mac-address-other-name-2026 ... based on the pattern that I observe in that registry?

Section 4, paragraph 0
>    The binding of a MAC address to a certificate is only as strong as
>    the CA's validation process.  CAs MUST verify that the subscriber
>    legitimately controls or owns the asserted MAC address.

Since you mention the binding of the MAC address to a certificate, this
section should include a note on MAC spoofing, e.g., that the trust
model depends on the CA and the deployment controls, and that MAC
addresses can be spoofed at L2. Having that here makes the threat
model clearer in my mind.

Section 5, paragraph 1
>        +=========+====================================+===============+
>        | Decimal | Description                        | References    |
>        +=========+====================================+===============+
>        | TBD0    | id-mod-mac-address-other-name-2025 | This document |
>        +---------+------------------------------------+---------------+

Not sure of the significance of the number 2025, but if this has anything
to do with the year 2025, maybe it can be updated to 2026.

No reference entries found for these items, which were mentioned in the text:
[draft-housley-lamps-macaddress-on].

Possible DOWNREF from this Standards Track doc to [X680]. If so, the IESG needs
to approve it.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "natively"; alternatives might be "built-in", "fundamental",
   "ingrained", "intrinsic", "original"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 0
>    In this document "otherName", "OtherName" and "GeneralName.otherName"
>    all refer to a GeneraName.otherName field included in a SAN or IAN.
>    The new name form is identified by the object identifier (OID)
>    id-on-MACAddress (TBD1) and declared below using the OTHER-NAME class
>    declaration syntax.  The name form has variants to convey an EUI-48
>    as an OCTET STRING comprising of 6 octets, or an EUI-64 as an OCTET
>    STRING comprising of 8 octets.  Constraints on EUI-48 and EUI-64
>    values are conveyed as OCTET STRINGs whose lengths are twice the
>    octet length of the identifiers.  The first set of N octets (where N
>    is the length of the address octets) define the bit pattern of the
>    constraint that the address must match, and the second set of N
>    octets defines the bit mask that defines the set of significant bits
>    in the bit pattern.

s/GeneraName/GeneralName/

Section 3.2, paragraph 4
>    For example, a constraint that specifies that the the acceptable
>    names must all be within an Organizationally Unique Identifier (OUI)
>    of '00-00-5e' for an EUI-48 address, would have a value part of
>    '00005E000000'H, a mask part of 'FFFFFFFF000000'H and would be
>    encoded as OCTET STRING '00005E000000FFFFFF000000'H.

s/the the/the/

Section 3.4.2, paragraph 0
>    This section describes the Path Validation Processing specific to
>    OtherName.MACAddress constraints.  N.B., It is possible to build
>    hierarchies of NCEs for OtherName.MACAddress's that prohibit all
>    names, even if that was not intended.  For example, say that the
>    level 1 NCE contained only a "permitted_subtrees" of only
>    (OtherName.MACAddress) global/unicast EUI-48, and the level 2 NCE
>    contained only a "permitted_subtress" of "any address" (i.e. the
>    initial constraint set).  This would result in an empty
>    permitted_subtrees set as an "any address" constraint is not
>    contained within a "global/unicast" constraint.  The worked example
>    is left to the reader.

s/permitted_subtress/permitted_subtrees/

Section 3.4.2.2, paragraph 5
> // rst => one of the requested subtrees (from the cert)
> // pst -> one of the current permitted subtrees
> foreach ( constraint rst in tempRequestedSubtrees) {
>     foreach ( constraint pst in prevSubtrees) {
>           if (childIsSubsetofParent (rst,
>                                    pst) {
>                 tempPermittedSubtrees += requestedSubtree;
>                 break;
>           }
>      }
>  }

s/childIsSubsetofParent/childIsSubsetOfParent/

Section 3.4.2.3, paragraph 4
>    // note that the ordering of the loop here differs
>    // from the 'intersection' operation.
>    foreach (constraint rExcl in tempRequestedSubtrees) {
>      boolean matches = false;
>      foreach (constraint est in tempExcludedSubtrees) {
>          // If I find a constraint in the current excluded
>          // constraints that 'covers' the requested subtree,
>          // I do not need to add the requested subtree
>          // to the set of excluded subtrees.
>          if (childIsSubsetParent (rExcl, est)) {
>            matches = true;
>            break;
>          }
>       }
   
s/childIsSubsetParent/childIsSubsetOfParent/

Section 6, paragraph 0
>    This Appendix contains the ASN.1 Module for the MAC Address; it
>    follows the conventions established by [RFC5912].

s/This Appendix/This Section/

These URLs in the document did not return content:

 * https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf

Section 1, paragraph 3
> ey an EUI-48 as an OCTET STRING comprising of 6 octets, or an EUI-64 as an OC
>                                 ^^^^^^^^^^^^^
Did you mean "comprising" or "consisting of"?

Section 2, paragraph 1
> or an EUI-64 as an OCTET STRING comprising of 8 octets. Constraints on EUI-4
>                                 ^^^^^^^^^^^^^
Did you mean "comprising" or "consisting of"?

Section 2, paragraph 2
> Name/GeneralName/ The following sub-sections describe how to encode EUI-48 an
>                                 ^^^^^^^^^^^^
This word is normally spelled as one.

Section 3.1, paragraph 2
> , a constraint that specifies that the the acceptable names must all be withi
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 3.2, paragraph 1
> ING '00005E000000FFFFFF000000'H. s/the the/the/ The bit patterns encoded in 
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 3.2, paragraph 4
> are the same layer-2 interface. A relying party that matches a presented MAC
>                                   ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 3.2, paragraph 8
> f type id-on-MACAddress. In the pseudo-code below, 'mask' is shorthand for t
>                                 ^^^^^^^^^^^
This word is normally spelled as one.

Section 3.4.1, paragraph 5
> by any universal/unicast address with a OUI of 00-00-5E -i.e., it will also m
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

# IESG review of draft-ietf-lamps-macaddress-on-06

CC @MikeBishop

## Comments

### Section 3.3, paragraph 4

Would this be a case warranting IAN usage?

### Section 3.4.1, paragraph 10

Being somewhat pedantic, various invalid lengths of n and c could pass
the algorithm in the text and fail the code or vice versa. You probably want to
add either an assumption that the inputs are valid or explicit checks that the
inputs are one of the two valid lengths.

### Section 4, paragraph 2

The mechanics of this make me nervous. It seems like it would be very
easy to claim control of a MAC that is actually on the router between the CA and
an attacker.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `natively`; alternatives might be `built-in`, `fundamental`,
   `ingrained`, `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3, paragraph 1
```
-    all refer to a GeneraName.otherName field included in a SAN or IAN.
+    all refer to a GeneralName.otherName field included in a SAN or IAN.
+                         +
```

### Section 3, paragraph 1

You're inconsistent in the document whether the separator here is '-'
(U+002D, "hyphen-minus") or '‑' (U+2011, "non-breaking hyphen"). I'd assume
U+002D was the intent and this is just copy-paste or text editor vagaries.

(There are many other instances of U+2011 throughout the document, but the
identifier is the one with actual interop implications.)

### Grammar/style

#### Section 2, paragraph 1
```
ey an EUI-48 as an OCTET STRING comprising of 6 octets, or an EUI-64 as an OC
                                ^^^^^^^^^^^^^
```
Did you mean "comprising" or "comprised of"?

#### Section 2, paragraph 1
```
or an EUI-64 as an OCTET STRING comprising of 8 octets. Constraints on EUI-4
                                ^^^^^^^^^^^^^
```
Did you mean "comprising" or "comprised of"?

#### Section 3, paragraph 1
```
 the bit pattern. The following sub-sections describe how to encode EUI-48 an
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.1, paragraph 2
```
, a constraint that specifies that the the acceptable names must all be withi
                                   ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 3.3, paragraph 1
```
f type id-on-MACAddress. In the pseudo-code below, 'mask' is shorthand for t
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 3.4.1, paragraph 7
```
by any universal/unicast address with a OUI of 00-00-5E -i.e., it will also m
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 3.4.2, paragraph 1
```
 bits within the OUI of 00-00-0e. If 'constraint child2 = '00005E005000 FFFF
                                     ^
```
Unpaired symbol: "'" seems to be missing.

Hi Russ, Corey, Joe, Tomofumi, and Mike, 

Thank you for the effort put into this specification. 

Please find below some few comments:

# I was wondering whether there is any operational impact that need to be highligted for devices that agressively rotate their MAC addresses (e.g., guards to issue too short-lived certificates)?

# For this one:  

CURRENT:
   The same MAC
   address MUST NOT be included in certificates issued to different
   devices, unless different devices share the same layer-2 interface.

## I guess this is reasoning for active certificates?

## How the issuer knows that these devices share the same L2 interface? What does that mean actually?

I flagged some few nits that I will send in a seprate PR to the authors.

Cheers,
Med

Thank you to Vijay Gurbani for the GENART review.

** Section 4
   CAs MUST verify that the subscriber
   legitimately controls or owns the asserted MAC address.

Consider if this is the appropriate framing – can you “own” a MAC address?  Why “subscriber” -- is the assignment of OUI a subscription service (don’t think so)?  Is subscriber here assuming a particular deployment model?  Section 7.3 uses similar language.

# Internet AD comments for draft-ietf-lamps-macaddress-on-06
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.4.1

* I saw there's an earlier requirement on CAs not to sign malformed
  NCE instances (S3.2) but might there be an addition check here, perhaps:

  "4.1 Perform a bitwise AND operation with the value bit pattern from
   Step 3 and mask bit pattern from Step 4. If the resulting value does
   not equal the value bit pattern the NCE is invalid."

  or something? (or perhaps I've misunderstood)

## Nits

### S3

* "GeneraName.otherName" ->
  "GeneralName.otherName" I expect

* "comprising of" -> "comprising", I believe

Thanks to MSK for the ARTART Review.