공개 키 인증서의 주체 대체 이름(SAN)에 IEEE MAC 주소를 옥텟 문자열로 담는 방법이 2026년 8월 RFC 10031로 발행됐다. 표준화 트랙의 Proposed Standard 단계다. 이 규격이 정의한 otherName 형식은 OID 1.3.6.1.5.5.7.8.12를 받아 IANA 레지스트리에 12번째 항목으로 등록됐다. 용도로는 사물인터넷과 차량 네트워크의 계층 2 인증을 든다. 정작 규격 자신은 보안 절에서 MAC 주소가 위조될 수 있다고 적어 둔다.

원자료 제원

정확히 무엇을 정의했나

X.509 인증서는 주체 대체 이름(SAN) 확장에 도메인 이름, 이메일 주소, IP 주소 등을 담는다. RFC 5280은 이 목록을 확장할 통로로 otherName을 열어 두었고, RFC 10031은 그 통로에 MAC 주소용 칸을 만들었다. 인코딩은 단순하다. EUI-48은 6옥텟, EUI-64는 8옥텟의 OCTET STRING으로 넣고 최상위 옥텟을 먼저 쓴다. 7.1절 예시 00-24-98-7B-19-02는 '0024987B1902'H가, 7.2절 AC-DE-48-00-11-22-33-44는 'ACDE480011223344'H가 된다. 구분 기호나 대소문자 규칙이 개입할 여지가 없다. 3.3절은 검증자가 옥텟 단위로 그대로 비교하도록 하고, 와일드카드는 지원하지 않는다고 못 박는다.

6·8이 아닌 12·16옥텟이 함께 있는 이유

ASN.1 타입은 MACAddress ::= OCTET STRING (SIZE (6 | 8 | 12 | 16))이다. 길이가 네 종류인 것은 같은 타입이 이름과 제약 조건 양쪽에 쓰이기 때문이다.

매칭 규칙은 3.4.1절에 있다. 이름과 값 패턴을 배타적 논리합(XOR)한 뒤 마스크와 비트별 논리곱(AND)을 해서, 결과가 전부 0이면 통과다. 길이가 어긋나면 계산 전에 불일치로 끝난다.

7.3절 예시가 이 구조를 보여준다. 값 패턴은 전부 0, 마스크는 030000000000이고, 규격은 이 제약이 전역(universal)이고 유니캐스트인 값만 통과시킨다고 설명한다. 마스크 0x03이 검사하는 자리는 첫 옥텟의 하위 두 비트다. 7.3절은 그 비트 위치를 직접 풀어 쓴다. 비트 0(마스크 0x01)은 개별/그룹(I/G) 비트로 0이면 유니캐스트, 1이면 멀티캐스트다. 비트 1(마스크 0x02)은 전역/로컬(U/L) 비트로 0이면 IEEE가 할당한 전역 주소, 1이면 로컬 할당이다. 이 둘을 함께 묶은 값이 0x03이다.

레지스트리에서 대조한 것

• otherName 형식 레지스트리(1.3.6.1.5.5.7.8)는 12개 항목이고 12번이 id-on-MACAddress다. 다만 1번과 2번은 "Reserved and Obsolete"로 표시돼 있어 살아 있는 형식은 10개다.
• ASN.1 모듈 식별자 레지스트리(1.3.6.1.5.5.7.0)는 128개 항목이며 126번이 id-mod-mac-address-other-name-2025다. 모듈 이름의 연도는 2025인데 RFC 발행은 2026년 8월이다.
• 규격 5장의 IANA 등록 요청 표는 참조를 RFC 10031로 적어 두었지만, 두 레지스트리 모두 참조란이 아직 RFC 번호가 아니라 초안 이름([RFC-ietf-lamps-macaddress-on-07])으로 남아 있다. 레지스트리 페이지에 적힌 마지막 갱신일은 2026년 7월 20일로 RFC 발행 이전이다.

규격이 스스로 붙인 단서

4장은 이 이름 형식의 신뢰도가 전적으로 CA의 검증 절차에 달렸다고 적는다. CA는 신청자가 해당 주소를 실제로 보유·통제하는지 확인해야 하고, 그 과정에서 주소가 위조될 수 있음을 고려해야 한다. 주소를 동적으로 할당하거나 공유하는 운용 방식은 이 이름 형식이 노리는 유일성과 책임 추적을 약화시킬 수 있다고도 적는다. MAC 주소는 통상 계층 3 경계를 넘어 라우팅되지 않으므로, 검증자는 주소가 망 경계를 넘어서도 안정적이라고 볼 근거가 따로 없는 한 로컬 네트워크 밖에서까지 유일하다고 가정해서는 안 된다. 같은 주소를 서로 다른 기기의 인증서에 넣지 못하게 하는 조항은 4장이 아니라 3.3절에 있다(계층 2 인터페이스를 공유하는 경우는 예외).

4.1절은 프라이버시를 따로 다룬다. 바뀌지 않는 주소가 담긴 인증서는 기기와 사용자의 장기 추적을 쉽게 만든다고 지적하며 주소 교체, 단명 인증서, 무작위화를 권고한다. 긴장이 남는 지점이다. 안정적 식별자여서 인증서에 넣을 값어치가 생기는데 프라이버시 절은 그 안정성을 줄이라고 권한다. 반대로 볼 여지도 있다. 관리 주체가 하나인 폐쇄망이라면 추적 위험이 크지 않아 실무에서 거의 문제되지 않을 수도 있다.

이 자료가 말하지 않는 것

• 채택 현황이 없다. 어떤 CA가 이 형식을 발급하고 어떤 검증 라이브러리가 처리하는지는 문서 밖의 일이다.
• 서론이 든 용도는 "사물인터넷과 차량 네트워크"라는 넓은 범주다. 계층 2 인증과 함께 흔히 거론되는 개별 프로토콜 이름은 서론에 없었다.
• 상호운용 시험 결과나 성능 수치가 없다. 기존 구현이 새 규칙을 어떻게 다루는지는 규격 범위 밖이다.
• RFC 5280 4.2.1.10절은 구현이 반드시(MUST) 이름 제약을 처리해야 하는 형식으로 directoryName 하나만 들고, rfc822Name·uniformResourceIdentifier·dNSName·iPAddress는 처리하는 것이 바람직하다(SHOULD)고 한다. 새 형식은 어느 쪽 목록에도 들어가지 않는다.

정리하면

• RFC 10031(2026년 8월, 표준화 트랙 Proposed Standard)은 MAC 주소용 otherName 형식을 OID 1.3.6.1.5.5.7.8.12로 정의했다.
• EUI-48은 6옥텟, EUI-64는 8옥텟으로 최상위 옥텟 우선 인코딩하며 와일드카드는 지원하지 않는다.
• 12·16옥텟은 이름이 아니라 제약이며, 값 패턴과 마스크를 이어 붙여 XOR 후 AND 결과가 0이면 통과한다.
• IANA otherName 레지스트리 12개 항목 중 12번이 이 형식이고, 1·2번은 폐기 표시가 붙어 유효 항목은 10개다.
• 규격 스스로 위조 가능성, 로컬 네트워크 밖 유일성 미보장, 장기 추적 위험을 명시했다.

출처와 확인 범위

• RFC 10031 (RFC Editor 전문) — 초록, 1장, 3.1~3.4.1절, 4장·4.1절, 5장, 6장, 7.1~7.3절, 8장 참조 목록까지 확인. 3.4.2절(경로 검증 처리)과 그 하위 절은 확인하지 않음.
• IETF Datatracker — RFC 10031 — 메타데이터(발행 연월, 상태, 스트림, 워킹그룹, 원 초안 이름·판번호, 개정·폐기 관계 없음)만 확인.
• IANA — PKIX Other Name Forms (1.3.6.1.5.5.7.8) — 전체 12개 행을 항목별로 확인. 레지스트리 페이지의 마지막 갱신일(2026-07-20)도 확인.
• IANA — PKIX Module Identifier (1.3.6.1.5.5.7.0) — 총 행 수와 마지막 15개 행만 확인.
• RFC 5280 (X.509 인증서 프로파일) — 4.2.1.6절 otherName 설명과 4.2.1.10절의 필수·권장 지원 형식 문장만 확인.