Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 10031 Vigil Security
Category: Standards Track C. Bonnell
ISSN: 2070-1721 TurboLight Solutions
J. Mandel
AKAYLA
T. Okubo
Penguin Securities
M. StJohns
NthPermutation Security LLC
August 2026
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).
このドキュメントでは、IEEE メディア アクセス コントロール (MAC) アドレスを伝送するために、X.509 サブジェクト代替名 (SAN) および発行者代替名 (IAN) 拡張に含める新しい GeneralName.otherName を定義します。新しい名前形式により、レイヤー 2 インターフェイス識別子を公開キー証明書にバインドできるようになります。さらに、この文書は、この名前形式の制約を X.509 名前制約拡張機能 (NCE) でエンコードおよび処理する方法を定義します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10031.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10031 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions and Definitions
3. MACAddress otherName
3.1. Encoding a MACAddress as an Alternative Name
3.2. Encoding a MACAddress Constraint
3.3. Generation and Validation Rules
3.4. Path Processing for the Name Constraints Extension
3.4.1. Matching Rules
3.4.2. OtherName.MACAddress Path Validation Processing
4. Security Considerations
4.1. Privacy Considerations
5. IANA Considerations
6. ASN.1 Module
7. MAC Address otherName Examples
7.1. EUI-48 Identifier
7.2. EUI-64 Identifier
7.3. EUI-48 Constraint for Universal, Unicast Addresses
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
Deployments that use X.509 certificates to identify a device by a Media Access Control (MAC) address need a standard way to encode it in the Subject Alternative Name (SAN) extension defined in [RFC5280]. This document defines a new otherName form "MACAddress". The name form carries either a 48-bit IEEE 802 MAC address (EUI-48) or a 64-bit extended identifier (EUI-64) in an OCTET STRING [X680]. Additionally, the name form also can convey constraints on EUI-48 or EUI-64 values when included in the Name Constraints extension (NCE) defined in Section 4.2.1.10 of [RFC5280]. The new name form enables certificate-based authentication at Layer 2 and facilitates secure provisioning in Internet of Things (IoT) and automotive networks, in particular.
X.509 証明書を使用してメディア アクセス コントロール (MAC) アドレスによってデバイスを識別する展開には、[RFC5280] で定義されているサブジェクト代替名 (SAN) 拡張でデバイスをエンコードする標準的な方法が必要です。この文書では、新しい otherName 形式「MACAddress」を定義します。名前形式は、48 ビットの IEEE 802 MAC アドレス (EUI-48) または 64 ビットの拡張識別子 (EUI-64) を OCTET STRING [X680] で保持します。さらに、名前形式は、[RFC5280] のセクション 4.2.1.10 で定義されている名前制約拡張 (NCE) に含まれる場合、EUI-48 または EUI-64 の値に対する制約を伝えることもできます。新しい名前形式により、レイヤー 2 での証明書ベースの認証が可能になり、特にモノのインターネット (IoT) や自動車ネットワークでの安全なプロビジョニングが容易になります。
Note that while this construct may be used to carry EUI-48 or EUI-64 addresses in an Issuer Alternative Name (IAN) extension, there are probably few, if any, reasons to do so.
この構造は、発行者代替名 (IAN) 拡張で EUI-48 または EUI-64 アドレスを運ぶために使用される可能性がありますが、そうする理由はおそらくほとんどないことに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
In this document, "otherName", "OtherName", and "GeneralName.otherName" all refer to a GeneralName.otherName field included in a SAN or IAN. The new name form is identified by the OBJECT IDENTIFIER (OID) id-on-MACAddress (1.3.6.1.5.5.7.8.12) and declared below using the OTHER-NAME class declaration syntax. The name form has variants to convey an EUI-48 as an OCTET STRING consisting of 6 octets, or an EUI-64 as an OCTET STRING consisting 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.
このドキュメントでは、「otherName」、「OtherName」、および「GeneralName.otherName」はすべて、SAN または IAN に含まれる GeneralName.otherName フィールドを指します。新しい名前形式は、OBJECT IDENTIFIER (OID) id-on-MACAddress (1.3.6.1.5.5.7.8.12) によって識別され、OTHER-NAME クラス宣言構文を使用して以下で宣言されます。名前形式には、EUI-48 を 6 オクテットからなる OCTET STRING として伝える、または EUI-64 を 8 オクテットからなる OCTET STRING として伝えるためのバリエーションがあります。EUI-48 および EUI-64 値の制約は、識別子のオクテット長の 2 倍の長さのオクテット文字列として伝達されます。N オクテットの最初のセット (N はアドレス オクテットの長さ) は、アドレスが一致する必要がある制約のビット パターンを定義し、N オクテットの 2 番目のセットは、ビット パターン内の有効ビットのセットを定義するビット マスクを定義します。
The following subsections describe how to encode EUI-48 and EUI-64 values and their corresponding constraints.
次のサブセクションでは、EUI-48 値と EUI-64 値、およびそれらに対応する制約をエンコードする方法について説明します。
When the name form is included in a SAN or IAN extension as an OtherName, the syntax consists of exactly six or eight octets. Values are encoded with the most significant octet encoded first ("big-endian" or "left-to-right" encoding). No text representation is permitted in the certificate, as human-readable forms such as "00-24-98-7B-19-02" or "0024.987B.1902" are used only in management interfaces. When a device possesses a 48-bit MAC identifier, the Certification Authority (CA) MUST encode it using a 6-octet OCTET STRING as the MACAddress value. When the device's factory identifier is a 64-bit EUI-64 or when no canonical 48-bit form exists, the CA MUST encode it using an 8-octet OCTET STRING as the MACAddress value.
名前形式が SAN または IAN 拡張に OtherName として含まれる場合、構文は正確に 6 または 8 オクテットで構成されます。値は、最上位オクテットが最初にエンコードされてエンコードされます (「ビッグ エンディアン」または「左から右」エンコード)。「00-24-98-7B-19-02」や「0024.987B.1902」などの人が読める形式は管理インターフェイスでのみ使用されるため、証明書ではテキスト表現は許可されません。デバイスが 48 ビットの MAC 識別子を所有する場合、認証局 (CA) は MACAddress 値として 6 オクテットの OCTET STRING を使用してそれをエンコードしなければなりません (MUST)。デバイスの工場出荷時の識別子が 64 ビット EUI-64 である場合、または正規の 48 ビット形式が存在しない場合、CA は MACAddress 値として 8 オクテットの OCTET STRING を使用してそれをエンコードしなければなりません (MUST)。
Example: 00-24-98-7B-19-02 encodes as OCTET STRING '0024987B1902'H.
例: 00-24-98-7B-19-02 は、オクテット文字列 '0024987B1902'H としてエンコードされます。
When the name form is included in the NCE, the syntax consists of an OCTET STRING that is twice as long as the OCTET STRING representation of the address type being constrained. Within the OCTET STRING, two elements are encoded:
名前形式が NCE に含まれる場合、構文は、制約されるアドレス タイプの OCTET STRING 表現の 2 倍の長さの OCTET STRING で構成されます。オクテット文字列内では、2 つの要素がエンコードされます。
1. The first set of N octets (where N is 6 for an EUI-48 constraint or 8 for an EUI-64 constraint) contains the "value bit pattern". This bit pattern encodes the bits that the masked address must contain to be considered a match.
1. N オクテットの最初のセット (N は EUI-48 制約の場合は 6、EUI-64 制約の場合は 8) には、「値ビット パターン」が含まれます。このビット パターンは、一致とみなされるためにマスクされたアドレスに含まれている必要があるビットをエンコードします。
2. The second set of N octets encodes the "mask bit pattern" of the constraint. Each bit that is asserted in the mask bit pattern indicates that the bit in the same position in the address is constrained by the first set of N octets.
2. N オクテットの 2 番目のセットは、制約の「マスク ビット パターン」をエンコードします。マスク ビット パターンでアサートされる各ビットは、アドレス内の同じ位置にあるビットが N オクテットの最初のセットによって制約されていることを示します。
For example, a constraint that specifies that 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.
たとえば、EUI-48 アドレスの場合、許容される名前がすべて「00-00-5e」の組織固有識別子 (OUI) 内にある必要があることを指定する制約は、値部分が「00005E000000」H、マスク部分が「FFFFFFFF000000」H になり、OCTET STRING としてエンコードされます。「00005E000000FFFFFF000000」H。
The bit patterns encoded in both the value bit pattern and mask bit pattern are encoded with the most significant bit encoded first ("big-endian" or "left-to-right" encoding).
値ビット パターンとマスク ビット パターンの両方でエンコードされたビット パターンは、最上位ビットが最初にエンコードされてエンコードされます (「ビッグ エンディアン」または「左から右」エンコード)。
If a bit is not asserted in the mask bit pattern, then the CA MUST NOT assert the corresponding bit in the value bit pattern. This rule ensures that a canonical encoding is used for a given mask bit pattern and value bit pattern.
マスク ビット パターンでビットがアサートされていない場合、CA は値ビット パターンで対応するビットをアサートしてはなりません (MUST NOT)。このルールにより、指定されたマスク ビット パターンと値ビット パターンに正規のエンコーディングが使用されることが保証されます。
Per Section 4.2.1.10 of [RFC5280], NCE are valid in and "MUST be used only in a CA certificate".
[RFC5280] のセクション 4.2.1.10 によれば、NCE は有効であり、「CA 証明書でのみ使用しなければなりません (MUST)」。
The CA MUST ensure that MACAddress otherName values included in certificates that it issues are owned by (or are expected to be owned by) the subject device for the certificate's lifetime. The same MAC address MUST NOT be included in certificates issued to different devices, unless different devices share the same Layer 2 interface.
CA は、発行する証明書に含まれる MACAddress otherName 値が、証明書の有効期間中、対象デバイスによって所有される (または所有されると予想される) ことを保証しなければなりません (MUST)。異なるデバイスが同じレイヤ 2 インターフェイスを共有しない限り、異なるデバイスに発行される証明書に同じ MAC アドレスを含めてはなりません (MUST NOT)。
A relying party that matches a presented MAC address to a certificate SHALL perform a byte-for-byte comparison of the OCTET STRING contents.
提示された MAC アドレスと証明書を照合する証明書利用者は、OCTET STRING の内容のバイトごとの比較を実行するものとします (SHALL)。
Wildcards are not supported.
ワイルドカードはサポートされていません。
Self-signed certificates that carry a MACAddress otherName MUST include the address of one of the device's physical ports.
MACAddress otherName を伝送する自己署名証明書には、デバイスの物理ポートの 1 つのアドレスが含まれなければなりません (MUST)。
The MACAddress otherName follows the general rules for otherName constraints in [RFC5280], Section 4.2.1.10. An NCE MAY impose permittedSubtrees and excludedSubtrees on OtherNames of type id-on-MACAddress.
MACAddress otherName は、[RFC5280] セクション 4.2.1.10 の otherName 制約の一般規則に従います。NCE は、タイプ id-on-MACAddress の OtherNames に allowedSubtrees およびexcludedSubtrees を課すことができます (MAY)。
In the pseudocode below, 'mask' is shorthand for the bit string formed from the mask portion of a constraint (e.g., the second set of N octets in the constraint, where N is 6 for an EUI-48 constraint or 8 for an EUI-64 constraint). Similarly, 'value' refers to the bit string formed from the first set of N octets in the constraint.
以下の疑似コードでは、「マスク」は制約のマスク部分から形成されたビット文字列の短縮形です (たとえば、制約内の N オクテットの 2 番目のセット。N は EUI-48 制約の場合は 6、EUI-64 制約の場合は 8)。同様に、「値」は、制約内の最初の N オクテットのセットから形成されたビット文字列を指します。
The declaration 'constraint' used below indicates an OtherName.MACAddress constraint value/mask pair -- with fields 'mask', 'value', and 'length'. '.length' as a field returns the byte length of the complete encoded constraint -- either 12 or 16, depending on the type of constraint. The declaration 'name' used below represents an OtherName.MACAddress name with fields 'value' and 'length'. The length is either 6 or 8 representing the encoded name's length.
以下で使用される宣言「constraint」は、フィールド「mask」、「value」、および「length」を持つ OtherName.MACAddress 制約値/マスクのペアを示します。'.length' フィールドは、完全なエンコードされた制約のバイト長 (制約のタイプに応じて 12 または 16) を返します。以下で使用される宣言「name」は、フィールド「value」および「length」を持つ OtherName.MACAddress 名を表します。長さは、エンコードされた名前の長さを表す 6 または 8 です。
To determine if a name matches a given constraint, the certificate-consuming application performs the following algorithm:
名前が特定の制約に一致するかどうかを判断するために、証明書を使用するアプリケーションは次のアルゴリズムを実行します。
1. If the name is 6 octets (representing an EUI-48 value) and the constraint is 16 octets (representing an EUI-64 constraint), then the name does not match the constraint.
1. 名前が 6 オクテット (EUI-48 値を表す) で、制約が 16 オクテット (EUI-64 制約を表す) の場合、名前は制約と一致しません。
2. If the name is 8 octets (representing an EUI-64 value) and the constraint is 12 octets (representing an EUI-48 constraint), then the name does not match the constraint.
2. 名前が 8 オクテット (EUI-64 値を表す) で、制約が 12 オクテット (EUI-48 制約を表す) の場合、名前は制約と一致しません。
3. Extract the value bit pattern from the upper (big-endian) N octets of the constraint, where N is "6" for EUI-48 identifiers and "8" for EUI-64 identifiers.
3. 制約の上位 (ビッグエンディアン) N オクテットから値ビット パターンを抽出します。ここで、N は EUI-48 識別子の場合は「6」、EUI-64 識別子の場合は「8」です。
4. Extract the mask bit pattern from the lower (big-endian) N octets of the constraint, where N is "6" for EUI-48 identifiers and "8" for EUI-64 identifiers.
4. 制約の下位 (ビッグエンディアン) N オクテットからマスク ビット パターンを抽出します。ここで、N は EUI-48 識別子の場合は「6」、EUI-64 識別子の場合は「8」です。
5. Perform an exclusive OR (XOR) operation with the value bit string extracted in step 3 and the octets of the name value.
5. 手順 3 で抽出した値ビット文字列と名前値のオクテットを使用して排他的論理和 (XOR) 演算を実行します。
6. Perform a bitwise AND operation with the bit string calculated in step 5 and the mask bit pattern.
6. 手順 5 で計算したビット列とマスク ビット パターンを使用してビット単位の AND 演算を実行します。
7. If the result of step 6 is a bit string consisting of entirely zeros, then the name matches the constraint. Conversely, if the result of the operation is a bit string with at least one bit asserted, then the name does not match the constraint.
7. ステップ 6 の結果が完全にゼロで構成されるビット文字列である場合、名前は制約に一致します。逆に、演算の結果が少なくとも 1 つのビットがアサートされたビット文字列である場合、その名前は制約に一致しません。
The algorithm can be alternatively expressed as:
アルゴリズムは次のように表すこともできます。
// Returns true if 'name n' matches 'constraint c'
boolean nameMatchesConstraint (name n, constraint c) {
return ((2 * n.length) == c.length &&
((c.value ^ n.value) &
c.mask) == 0) ;
}
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 an 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 (Section 1.3 of [RFC9542]).
たとえば、「000000000000 030000000000」H という制約は、00-00-5e-00-50-34 などのユニバーサル/ユニキャスト EUI-48 アドレスと一致します。'00005E000000 FFFFFF000000'H という制約は、OUI が 00-00-5E のユニバーサル/ユニキャスト アドレスと一致します。つまり、00-00-5e-00-50-34 とも一致します。「00-00-5E」は IANA によって管理される OUI であることに注意してください ([RFC9542] のセクション 1.3)。
Implementations are not required to implement this algorithm, but they MUST calculate an identical result to this algorithm for a given set of inputs.
実装はこのアルゴリズムを実装する必要はありませんが、指定された入力セットに対してこのアルゴリズムと同じ結果を計算しなければなりません (MUST)。
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_subtrees" 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.
このセクションでは、OtherName.MACAddress 制約に固有のパス検証処理について説明します。注意: 意図していなかったとしても、すべての名前を禁止する OtherName.MACAddress の NCE 階層を構築することができます。たとえば、レベル 1 NCE には (OtherName.MACAddress) グローバル/ユニキャスト EUI-48 のみの「permitted_subtrees」のみが含まれ、レベル 2 NCE には「任意のアドレス」(つまり、初期制約セット) の「permitted_subtrees」のみが含まれていたとします。「任意のアドレス」制約が「グローバル/ユニキャスト」制約内に含まれないため、空の allowed_subtrees セットが生成されます。実際に動作する例は読者に委ねられます。
The following is a utility function used to determine whether or not the set of matching addresses for one MACAddress constraint is a subset of the matching addresses for another constraint.
以下は、1 つの MACAddress 制約に一致するアドレスのセットが、別の制約に一致するアドレスのサブセットであるかどうかを判断するために使用されるユーティリティ関数です。
For example, given the following (using the IANA-assigned DOI), 'child' is a constraint wholly contained within 'parent':
たとえば、次の場合 (IANA が割り当てた DOI を使用)、「child」は完全に「parent」内に含まれる制約です。
constraint parent = '000000000000 000000000000'H
constraint child = '00005E000000 FCFFFF000000'H
'child' is a subset of parent because 1) they are the same length (both EUI-48 constraints); and 2) the child.mask ANDed with the parent.mask equals the parent mask; and 3) the bits in the child.value under the parent.mask are set to the same values as the bits in the parent.value under the parent mask.
'child' は、1) 同じ長さ (両方の EUI-48 制約) であるため、親のサブセットです。2) child.mask とparent.mask の論理積が親マスクと等しい。3)parent.mask の下の child.value のビットは、親マスクの下のparent.value のビットと同じ値に設定されます。
Note that the child mask allows for any combination of the local/ universal and unicast/multicast address bits within the OUI of 00-00-5e.
子マスクでは、00-00-5e の OUI 内のローカル/ユニバーサル アドレス ビットとユニキャスト/マルチキャスト アドレス ビットの任意の組み合わせが許可されることに注意してください。
If constraint child2 = '00005E005000 FFFFFFFFFF00'H and 'child' are compared, 'child2' would be a subset of 'child'. 'child2' uses the same OUI as 'child' but further restricts the matching addresses to universal/unicast by turning on the '030000000000'H mask bits and also restricts the range of valid addresses from 00-00-5E-00-50-00 to 00-00-5E-00-50-FF, i.e., to the 'example' range for the 00-00-5E OUI.
制約 child2 = '00005E005000 FFFFFFFFFF00'H と 'child' を比較すると、'child2' は 'child' のサブセットになります。「child2」は「child」と同じOUIを使用しますが、「030000000000」Hマスクビットをオンにすることで一致するアドレスをユニバーサル/ユニキャストにさらに制限し、有効なアドレスの範囲を00-00-5E-00-50-00から00-00-5E-00-50-FF、つまり、00-00-5E OUI。
// Both 'child' and 'parent' are OtherName.MACAddress
// constraints.
// Returns true if all addresses that match child also match
// parent; false otherwise.
// Used to calculate INTERSECTION sets for
// OtherName.MACAddress constraints.
boolean childIsSubsetOfParent (constraint c, constraint p) {
return (
// if the lengths are the same
c.length == p.length &&
// and if there are no bits set in the parent's mask that
// are not also set in the child's mask
// e.g., we can add mask bits to the current set, we cannot
// remove them
(c.mask & p.mask) == p.mask &&
// and if the child's value has at least all the bits set that
// were set (and live) in the parent's value
// e.g., we can't change the values of the live bits from the
// superior constraint
(c.value & p.mask) == (p.value & p.mask)
);
}
Per (h) and (i) in Section 6.1.1 of [RFC5280], we need to specify NCE OtherName.MACAddress set values for both the initial-permitted-subtrees and for initial-excluded-subtrees. For initial-permitted-subtree, the first constraint is "accept all EUI-48 MACAddresses", and the second constraint is "accept all EUI-64 MACAddresses":
[RFC5280] のセクション 6.1.1 の (h) および (i) に従って、初期許可サブツリーと初期除外サブツリーの両方に NCE OtherName.MACAddress 設定値を指定する必要があります。初期許可サブツリーの場合、最初の制約は「すべての EUI-48 MACAddresses を受け入れる」、2 番目の制約は「すべての EUI-64 MACAddresses を受け入れる」です。
initial-permitted-subtrees{} += { 000000000000000000000000H,
00000000000000000000000000000000H }
initial-excluded-subtrees{} += { };
See (g) (1) in Section 6.1.4 of [RFC5280]. As we walk down the tree from the root, the set of permitted_subtrees can only stay the same or shrink. At each level, we clear the set of permitted_subtrees and for each NCE OtherName.MACAddress.permitted_subtree constraint in the certificate, we look to see if there is a permitted_subtree constraint at the previous level that equals or encloses this new constraint. If so, we add this new constraint to the current level's set of permitted_subtrees. We repeat this going down the tree for the remaining CA certificates.
[RFC5280] のセクション 6.1.4 の (g) (1) を参照してください。ルートからツリーを下っていくにつれて、 allowed_subtree のセットは同じままになるか、縮小することしかできません。各レベルで、 allowed_subtree のセットをクリアし、証明書内の各 NCE OtherName.MACAddress.permitted_subtree 制約について、この新しい制約と等しいか、またはそれを囲む、前のレベルの allowed_subtree 制約があるかどうかを確認します。そうである場合、この新しい制約を現在のレベルの allowed_subtree のセットに追加します。残りの CA 証明書に対してツリーを下ってこれを繰り返します。
The intersection of the set of OtherName.MACAddress current permitted_subtrees with each certificate in the path is as follows:
OtherName.MACAddress の現在の allowed_subtree のセットとパス内の各証明書の交差部分は次のとおりです。
// This logic can be used for both MACAddress and iPAddress
// OtherName types
// Initialize -
permitted_subtrees{} (0) = initial-permitted-subtrees;
// foreach (certificate i = (1..n) in the path) {
set constraint prevSubtrees{} =
{ the set of OtherName.MACAddress.permitted_subtrees
from the permitted_subtree{} (i-1) variable};
constraint tempPermittedSubtrees {} = {};
constraint tempRequestedSubtrees {} =
{ the set of OtherName.MACAddress.permitted_subtrees from
the Name Constraints extension in the current certificate };
// 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 += rst;
break;
}
}
}
permitted_subtrees{} (i) = tempPermittedSubtrees;
// } end foreach CA cert on path
See (g) (2) in Section 6.1.4 of [RFC5280]. Unlike permitted_subtrees, which is the intersection of the NCEs at each level, excluded_subtrees is the union of all constraints. Starting with an excluded_subtrees empty set, at each level add to that set any constraints from the CA certificates that are not already in the set, or that are not covered by a constraint already in the set.
[RFC5280] のセクション 6.1.4 の (g) (2) を参照してください。各レベルの NCE の共通部分である allowed_subtrees とは異なり、excluded_subtrees はすべての制約の結合です。excluded_subtrees の空のセットから始めて、各レベルで、セットにまだ含まれていない CA 証明書からの制約、またはセットにすでに含まれている制約の対象になっていない制約をそのセットに追加します。
The union of the excluded_subtrees set with the OtherName.MACAddress excluded_subtrees for each certificate in the path is computed as follows:
パス内の証明書ごとに、OtherName.MACAddress のexcluded_subtrees セットとexcluded_subtrees セットの和集合は、次のように計算されます。
// Initialize
excluded_subtrees{} (0) = initial-excluded-subtrees;
// foreach (certificate i = (1..n) in the path) {
// Since we are doing a union operation we start with
// what was excluded at the previous level and try and
// add to it.
tempExcludedSubtrees {} =
{ the set of OtherName.MACAddress.excluded_subtrees from
excluded_subtrees (i-1) };
tempRequestedSubtrees {} =
{ the set of OtherName.MACAddress.excluded_subtrees from
the current certificate };
// 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 (childIsSubsetOfParent (rExcl, est)) {
matches = true;
break;
}
}
if (!matches) {
tempExcludedSubtrees += rExcl;
}
}
// } end foreach certificate in the path
excluded_subtrees{} (i) = tempExcludedSubtrees;
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. The validation process MUST account for the possibility that MAC addresses can be spoofed.
MAC アドレスと証明書のバインドは、CA の検証プロセスと同じくらい強力です。CA は、加入者がアサートされた MAC アドレスを正当に制御または所有していることを検証しなければなりません (MUST)。検証プロセスでは、MAC アドレスがスプーフィングされる可能性を考慮しなければなりません (MUST)。
Some systems dynamically assign or share MAC addresses. Such practices can undermine the uniqueness and accountability that this name form aims to provide.
一部のシステムでは、MAC アドレスを動的に割り当てまたは共有します。このような慣行は、この名前形式が提供することを目的とした独自性と説明責任を損なう可能性があります。
Unlike IP addresses, MAC addresses are not typically routed across Layer 3 boundaries. Relying parties SHOULD NOT assume uniqueness beyond their local network unless the relying party has information that addresses are stable across network boundaries.
IP アドレスとは異なり、MAC アドレスは通常、レイヤー 3 境界を越えてルーティングされません。信頼当事者は、アドレスがネットワーク境界を超えて安定しているという情報を持っている場合を除き、ローカル ネットワークを越えて一意性を想定すべきではありません (SHOULD)。
The Security Considerations section of [RFC5280] applies to this specification as well.
[RFC5280] のセキュリティに関する考慮事項のセクションもこの仕様に適用されます。
A MAC address can uniquely identify a physical device and by extension, its user. Certificates that embed unchanging MAC addresses facilitate long-term device tracking. Deployments that use the MACAddress name SHOULD consider rotating addresses, using short-lived certificates, or employing MAC address randomization where feasible.
MAC アドレスは、物理デバイス、ひいてはそのユーザーを一意に識別できます。不変の MAC アドレスを埋め込んだ証明書により、長期的なデバイス追跡が容易になります。MACAddress 名を使用するデプロイメントでは、可能であればアドレスのローテーション、有効期間の短い証明書の使用、または MAC アドレスのランダム化の採用を検討する必要があります (SHOULD)。
IANA has made the following assignment in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:
IANA は、「SMI Security for PKIX Module Identifier」(1.3.6.1.5.5.7.0) レジストリに次の割り当てを行っています。
+=========+====================================+===========+
| Decimal | Description | Reference |
+=========+====================================+===========+
| 126 | id-mod-mac-address-other-name-2025 | RFC 10031 |
+---------+------------------------------------+-----------+
Table 1
IANA has made the following assignment in the "SMI Security for PKIX Other Name Forms" (1.3.6.1.5.5.7.8) registry:
IANA は、「PKIX Other Name Forms の SMI Security」(1.3.6.1.5.5.7.8) レジストリに次の割り当てを行いました。
+=========+==================+===========+
| Decimal | Description | Reference |
+=========+==================+===========+
| 12 | id-on-MACAddress | RFC 10031 |
+---------+------------------+-----------+
Table 2
This section contains the ASN.1 module for the MAC address; it follows the conventions established by [RFC5912].
このセクションには、MAC アドレスの ASN.1 モジュールが含まれています。[RFC5912] によって確立された規則に従います。
MACAddressOtherName-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-mac-address-other-name-2025(126) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
OTHER-NAME FROM PKIX1Implicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) }
id-pkix FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ;
-- id-pkix 8 is the otherName arc
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
-- OID for this name form
id-on-MACAddress OBJECT IDENTIFIER ::= { id-on 12 }
-- Contents of the otherName field
MACAddressOtherNames OTHER-NAME ::= { on-MACAddress, ... }
on-MACAddress OTHER-NAME ::= {
MACAddress IDENTIFIED BY id-on-MACAddress }
MACAddress ::= OCTET STRING (SIZE (6 | 8 | 12 | 16))
END
The following is a human-readable summary of the Subject Alternative Name extension from a certificate containing a single MACAddress otherName with value 00-24-98-7B-19-02:
以下は、値 00-24-98-7B-19-02 を持つ単一の MACAddress otherName を含む証明書のサブジェクト代替名拡張子の人間が判読可能な概要です。
SEQUENCE {
otherName [0] {
OBJECT IDENTIFIER id-on-MACAddress
[0] OCTET STRING '0024987B1902'H
}
}
An EUI-64 example (AC-DE-48-00-11-22-33-44):
EUI-64 の例 (AC-DE-48-00-11-22-33-44):
[0] OCTET STRING 'ACDE480011223344'H
The first octet of a MAC address contains two flag bits. IEEE bit numbering has bit '0' as the least significant bit of the octet because that is the bit transmitted first.
MAC アドレスの最初のオクテットには 2 つのフラグ ビットが含まれます。IEEE ビット番号付けでは、オクテットの最下位ビットがビット「0」になります。これは、最初に送信されるビットだからです。
* Individual(I)/Group(G) bit (bit 0 or mask 0x01): 0 = unicast, 1 = multicast. Multicast prefixes are never OUIs.
* 個別 (I)/グループ (G) ビット (ビット 0 またはマスク 0x01): 0 = ユニキャスト、1 = マルチキャスト。マルチキャスト プレフィックスは OUI ではありません。
* Universal(U)/Local(L) bit (bit 1 or mask 0x02): 0 = universal (IEEE-assigned), 1 = local.
* ユニバーサル (U)/ローカル (L) ビット (ビット 1 またはマスク 0x02): 0 = ユニバーサル (IEEE 割り当て)、1 = ローカル。
These flags let the implementations exclude multicast and local addresses but still cannot prove that a 24-bit value is an IEEE-registered OUI. 36-bit Company IDs (CIDs) share the same first 24 bits, and enterprises MAY deploy pseudo-OUIs. CAs MUST include only addresses the subscriber legitimately controls (registered OUI or CID). Before issuing a certificate that contains a MACAddress or a name constraint based on such a permitted set of addresses, the CA MUST verify that control: for example, by consulting the IEEE registry [IEEERA] or reviewing manufacturer documentation.
これらのフラグを使用すると、実装ではマルチキャスト アドレスとローカル アドレスを除外できますが、それでも 24 ビット値が IEEE に登録された OUI であることを証明することはできません。36 ビットの企業 ID (CID) は同じ最初の 24 ビットを共有しており、企業は擬似 OUI を展開してもよい(MAY)。CA には、加入者が合法的に制御するアドレス (登録済みの OUI または CID) のみを含める必要があります。MACAddress またはそのような許可されたアドレスのセットに基づく名前制約を含む証明書を発行する前に、CA は、たとえば、IEEE レジストリ [IEEERA] を参照したり、製造元のドキュメントを確認したりすることによって、その制御を検証しなければなりません (MUST)。
The following constraint definition constrains EUI-48 values to only those that are universal and unicast; locally assigned or multicast values will not match the constraint.
次の制約定義は、EUI-48 値をユニバーサルかつユニキャストのもののみに制限します。ローカルに割り当てられた値またはマルチキャスト値は制約と一致しません。
[0] OCTET STRING '000000000000 030000000000'H
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X680] ITU-T, "Information Technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[IEEERA] IEEE Standards Association, "Guidelines for Use of
Extended Unique Identifier (EUI), Organizationally Unique
Identifier (OUI), and Company ID (CID)", 3 August 2017,
<https://standards.ieee.org/wp-
content/uploads/import/documents/tutorials/eui.pdf>.
[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters", BCP 141, RFC 9542,
DOI 10.17487/RFC9542, April 2024,
<https://www.rfc-editor.org/info/rfc9542>.
We thank the participants on the LAMPS Working Group mailing list for their insightful feedback and comments. In particular, the authors extend sincere appreciation to Bob Beck, David von Oheimb, Deb Cooley, Francois Rousseau, Jacqueline McCall, John Preuß Mattsson, Mahesh Jethanandani, Mohamed Boucadair, Murray Kucherawy, Sean Turner, and Tim Hollebeek for their reviews and suggestions, which greatly improved the quality of this document.
LAMPS ワーキング グループ メーリング リストの参加者の洞察力に富んだフィードバックやコメントに感謝します。特に、著者らは、このドキュメントの品質を大幅に向上させたレビューと提案に対して、Bob Beck、David von Oheimb、Deb Cooley、Francois Rousseau、Jacqueline McCall、John Preuß Mattsson、Mahesh Jethanandani、Mohamed Boucadair、Murray Kucherawy、Sean Turner、および Tim Hollebeek に心から感謝の意を表します。
Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Corey Bonnell
TurboLight Solutions, LLC
Email: corey.bonnell@turbolightsolutions.com
Joe Mandel
AKAYLA, Inc.
Email: joe@akayla.com
Tomofumi Okubo
Penguin Securities Pte. Ltd.
Email: tomofumi.okubo+ietf@gmail.com
Michael StJohns
NthPermutation Security LLC
Email: msj@nthpermutation.com