요약

  • RFC 9925는 2026년 2월 IETF 제안 표준으로 발표되었으며, 매개변수가 생략되고 서명 값 길이가 0인 X.509 서명 알고리즘id-alg-unsigned를 정의합니다.
  • 이 프로파일은 발급자의 증명 없이 주체 정보를 전달합니다. 발급자 필드를 호환성을 위한 자리표시자로 채워 둘 수 있지만, 해당 개체는 여전히 자체 서명도 자체 발급도 아닙니다.
  • 애플리케이션은 X.509 서명을 검증하지 않는 경우에만 이 개체를 수용할 수 있습니다. 인증 경로 검증기는 서명 대신 사용된id-alg-unsigned를 반드시 거부해야 합니다.
  • 장식적인 자체 서명을 제거하면 포스트 양자 환경에서 크기를 줄이고, 프로토콜 간 키 재사용을 피하며, 서명할 수 없는 키도 지원할 수 있습니다. 이 표준은 보안 우회가 아니라 빠진 연결을 명시적으로 만듭니다.
  • 따라서 신뢰, 무결성, 권한은 반드시 다른 메커니즘을 통해 와야 합니다. 신뢰 출처 및 범위 영수증은 바이트, 외부 근거, 설치자, 신뢰 저장소, 허용 용도, 변경 이력, 제거 경로를 식별해야 합니다.

서명 필드가 의도적으로 비어 있는 인증서

RFC 9925에서 가장 말해 주는 가치는 0입니다.

무서명 인증서는id-alg-unsigned를 위해 개체 식별자1.3.6.1.5.5.7.6.36을 사용합니다. 알고리즘 매개변수는 없습니다.signatureValue는 길이 0의 BIT STRING입니다. 구조 자체는 여전히 X.509처럼 보입니다. 주체 이름, 공개 키, 확장을 담기 위한 그 구조가 널리 지원되기 때문입니다. 그러나 더 이상 파서에게 발급자가 해당 필드를 암호학적으로 보증했다고 가장하라고 요구하지 않습니다.

이것은 서명 확인을 잊은 것과 같지 않습니다. 표준은 이 부재에 이름과 처리 규칙을 부여합니다. 인증서 서명을 검증하지 않는 수신자는 무서명 알고리즘을 수용할 수 있습니다. 검증하는 수신자는 이를 거부해야 합니다. 인증 경로 검증기는 발급자 서명이 있어야 할 자리에 빈 값이 남아 있도록 절대 허용해서는 안 됩니다.

이 구분은 유난히 깔끔합니다: 같은 개체가 문법상으로는 유용하면서 암호학적으로는 연결(edge)로서 무효일 수 있습니다.

여기서 거버넌스가 등장합니다. 보안 인터페이스는 익숙한 형태로부터 권한을 빌려 오는 경우가 많습니다. 인증서라 불리는 파일은 발급자, 유효 기간, 초록 아이콘과 함께 표시될 수 있습니다. 자산 목록은 CA 발급 자격 증명 옆에서 이를 함께 셀 수 있습니다. 운영자는 신뢰할 만한 어플라이언스 이미지에서 왔다는 사실은 기억하면서 그 이미지를 누가 승인했는지의 기록은 잃을 수 있습니다. RFC 9925는 이런 실수 중 어느 것도 요구하지 않습니다. 오히려 그 정밀성이 실수를 더 잘 보이게 합니다.

노드는 남고, 연결은 사라진다

RFC 9925는 자체적인 그래프 모델을 제시합니다. 평범한 X.509 인증서는 두 개체를 연결합니다: 주체에 대한 정보와 발급자의 증명. 공개 키 인프라 그래프에서 주체와 발급자는 노드이고, 인증서는 그 둘 사이의 연결입니다.

일부 애플리케이션은 노드만 필요로 합니다. 트러스트 앵커는 위의 인증서로부터 권한을 받는 것이 아니라 경로를 시작합니다. 고정(pinned) TLS 배포는 별도의 프로비저닝 채널을 통해 공개 키나 지문을 알 수 있습니다. 기기는 서명을 만들 수 없는 KEM 키를 위해 X.509 형태의 컨테이너가 필요할 수 있습니다. 이런 경우 자체 서명을 만드는 것은 유용한 신뢰 없이 문법만 충족할 수 있습니다.

무서명 프로파일은 가공의 연결을 제거합니다. 이는 표현의 진실성을 높입니다. 또한 자체 서명 래퍼가 가릴 수 있는 질문을 드러냅니다: 무엇이 이 특정 노드를 여기서 권위 있는 것으로 만들었는가?

RFC 5280은 이미 그 질문의 일부에 답합니다. 트러스트 앵커 정보가 자체 서명 인증서로 표현될 때 그 인증서는 예상되는 인증 경로에 포함되지 않습니다. 이름, 알고리즘, 공개 키는 입력값입니다. 그 정보가 신뢰되는 이유는 신뢰할 만한 대역외 절차가 경로 처리에 이를 전달했기 때문입니다. 신뢰할 인증 기관의 선택은 지역적 결정이며 애플리케이션이나 경로에 따라 달라질 수 있습니다.

따라서 자체 서명은 결코 궁극적인 신뢰의 원천이 아니었습니다. 공개 키 보유자가 같은 개체에 대한 서명을 만들었음을 보여줄 수 있고, 일부 애플리케이션은 이를 손상 확인용으로 사용했습니다. 그러나 관리자가 키를 설치해야 한다는 것, 주체 이름이 정확하다는 것, 모든 용도에 대해 키가 권위를 가져야 한다는 것을 증명할 수는 없었습니다.

RFC 9925는 그 모호성을 걷어냅니다. 노드는 보입니다. 빠진 연결도 보입니다. 이제 외부의 결정이 자체 근거를 갖추어야 합니다.

채워진 발급자 필드도 자리표시자일 수 있다

가장 어려운 필드는 빈 서명이 아니라 발급자 이름입니다.

X.509는 발급자 필드를 요구하며 비우는 것을 허용하지 않습니다. 기존 애플리케이션은 트러스트 앵커 표현에서 주체와 발급자 이름이 일치하기를 기대할 수도 있습니다. 그래서 RFC 9925는 발신자가 주체를 발급자 필드에 복사하는 것을 허용합니다. 또한 짧은 전용 자리표시자 이름을 정의합니다.

어느 쪽도 발급자를 만들지 않습니다. 표준이 이를 명시적으로 말합니다. 반복된 주체는 호환성 값이지 주체가 자신을 발급했다는 증거가 아닙니다. 무서명 인증서는 서명이 없으므로 자체 서명이 아니고, 발급 관계가 존재하지 않으므로 자체 발급도 아닙니다.

이것은 Lu Heng의 Policy Mirror를 보여주는 작지만 중요한 사례입니다. 기록은 존재하는 권력과 사건을 보여야 하며, 레거시 문법이 암시하는 것처럼 보이는 것을 보여서는 안 됩니다. 자리표시자를 자격 없이 “발급자(Issued by)”라고 표시하는 소프트웨어 화면은 필수적인 문법 슬롯을 제도적 주장으로 바꿉니다. 주체에서 자신으로 고리를 그리는 경로 시각화 도구는 표준이 제거한 연결을 조작해 낼 것입니다.

같은 규율이 확장에도 적용됩니다. 권위 키 식별자와 발급자 대체 이름은 발급자를 기술하므로 보통은 생략해야 합니다. 키 용도와 기본 제약은 주체의 의도된 역할을 기술해야 합니다. CA 능력이 있는 주체는 그렇게 표시될 수 있지만, 그 표시가 트러스트 앵커로서의 설치를 승인하지는 않습니다. 이는 능력을 기술할 뿐이며, 별도의 권위가 그것을 신뢰할지 어디에서 신뢰할지를 결정합니다.

인식은 검증이 아니다

IANA는id-alg-unsigned를 등록했습니다. 이 할당은 독립적인 시스템이 값을 인식하고 명세를 찾도록 합니다. 그러나 빈 서명을 유효하게 만들거나, 주체를 인증하거나, 신뢰 저장소 변경을 승인하지는 않습니다.

레지스트리가 종종 승인 목록처럼 읽히기 때문에 이 차이는 중요합니다. 이 경우 레지스트리 항목은 거의 반대 역할을 합니다: 소프트웨어가 비서명(non-signature)을 식별하고 검증 맥락에서 거부를 강제하는 데 쓰는 정확한 값을 제공합니다.

가장 안전한 기본 동작은 의도적으로 평범합니다. 변경되지 않은 X.509 검증기는 검증할 수 없는 알고리즘을 보고 경로를 거부합니다. 소프트웨어는 자체 서명 확인 없이 주체 정보를 소비할 준비가 되어 있던 제한된 맥락에서만 특수 처리를 필요로 합니다.

RFC 9925는 이 실패 모드에 대해 경고합니다. 애플리케이션이 인증 경로 안에서, 또는 X.509 서명을 검증해야 하는 어느 곳에서든 무서명 식별자를 수용하면 검증을 우회한 것입니다. 문서는 이 위험을 다른 토큰 시스템의 알고리즘 혼동 실패와 비교합니다. RFC 8725는 더 넓은 원칙을 진술합니다: 암호학 라이브러리는 호출자가 지원되는 알고리즘을 선택하도록 해야 하고, 선언된 알고리즘을 실제 수행되는 연산에 결합해야 합니다.

알고리즘 레지스트리는 상태 기계를 명시적으로 만들 수 있습니다. 그러나 모든 제품 안에서 상태 전이를 강제할 수는 없습니다. 그 증명은 구현 테스트, 구성, 운영 증거에 속합니다.

서명을 제거하는 것이 더 안전할 수 있는 이유

“무서명 인증서”를 약화로 읽기 쉽습니다. 그러나 의도된 맥락에서는 오히려 반대일 수 있습니다.

트러스트 앵커 표현에 붙은 많은 자체 서명은 검사되지 않습니다. X.509에 서명 슬롯이 있고 소프트웨어가 인증서 모양 컨테이너를 기대하기 때문에 존재하는 것입니다. 포스트 양자 알고리즘에서는 쓰이지 않는 서명이 클 수 있습니다. 주체가 최종 개체(end 주체)라면 그것을 만드는 일은 X.509 맥락과 키의 실제 프로토콜에서 같은 키를 재사용하여 프로토콜 간 공격 표면을 만듭니다. 공개 키가 서명이 아니라 키 캡슐화용이라면 그 자리표시자를 만들 수 없을 수도 있습니다.

무시되는 암호학적 몸짓을 이름 붙은 빈 값으로 바꾸면 연극성(theatre)이 줄어듭니다. 구현자에게 그 필드에서 신뢰를 끌어내지 말라고 말합니다. 검증기가 안전하게 실패(fail closed)하도록 합니다. 그리고 키에게 자신의 목적 밖의 기능을 수행하라고 요구하는 일을 피합니다.

따라서 RFC 9925의 가장 강한 방어는 주장을 좁힌다는 것입니다. 인증서는 발급자 증명을 갖고 있다고 거짓 말을 하지 않습니다. 애플리케이션은 결코 신뢰의 이유가 아니었던 자체 서명을 검증하느라 노력을 낭비하지 않습니다. 실제 신뢰 메커니즘은 지역적이고 배포에 적합하게 남을 수 있습니다.

이 방어가 성공하는 조건은 지역 메커니즘이 책임 있는 사람들에게 보이는 것입니다. “대역외(out of band)”는 경계 설명이지 설명이 아닙니다. 대면으로 확인한 지문일 수 있고, 서명된 펌웨어 이미지일 수 있고, 보호된 구성 저장소일 수 있고, 기업 관리 트랜잭션일 수 있고, 제조 세리머니일 수 있고, 수동 관리자 선택일 수 있습니다. 이 경로들은 서로 다른 소유자, 범위, 복구 특성을 가집니다.

신뢰는 설치자로 옮겨진다

RFC 6024는 빠진 계층에 유용한 어휘를 제공합니다. 트러스트 앵커는 공개 키와 관련 제약을 통해 권위 있는 개체를 대표합니다. 트러스트 앵커 관리자는 하나 이상의 저장소를 통제합니다. 저장소는 애플리케이션별, 기기별 또는 공유될 수 있습니다. 인식은 사용자나 용도의 하위 집합으로 제한될 수 있습니다. 관리 작업은 앵커를 추가, 제거, 교체하며, 건전한 프로토콜은 변경을 공급하는 당사자의 출처와 권위를 모두 인증합니다.

이 세부사항들은 거버넌스의 이동을 드러냅니다. 파일에 발급자 증명이 없는 이상, 그것을 설치하는 사람이나 시스템은 더 이상 사무적인 가져오기를 수행하는 것이 아닙니다. 실질적인 신뢰 결정을 내리는 것입니다.

설치자는 최소 네 가지 질문에 답해야 합니다. 승인된 정확한 바이트인가? 공급 당사자가 이 앵커를 제안할 권한이 있는가? 설치자가 이 저장소를 변경할 권한이 있는가? 어떤 애플리케이션, 이름, 정책, 기간에 대해 키를 신뢰해야 하는가?

어느 것도 빈 서명에서 복구할 수 없습니다. 해시는 바이트 동일성을 보호할 수 있지만 범위를 설명할 수 없습니다. 보안 채널은 출처를 인증할 수 있지만 그 출처가 이 애플리케이션에 결합할 권한이 있는지 증명할 수 없습니다. 관리자 권한은 변경을 실행할 수 있지만 그 자체로 정책 권한을 공급하지 않습니다. 성공한 경로 검증 테스트는 새로 구성된 앵커가 경로를 가능하게 함을 증명할 뿐, 그 경로를 가능하게 하기로 한 결정이 정당했다는 것은 증명하지 않습니다.

그래서 외부 신뢰에는 단지 메커니즘만이 아니라 기록이 필요합니다.

신뢰 출처 및 범위 영수증

유용한 영수증은 파일 이름이 아니라 개체로 시작합니다. 정확한 바이트의 다이제스트, 무서명 알고리즘 식별자, 주체 공개 키, 관련 주체 역할 필드를 기록합니다. 이 개체가 발급자 서명을 공급하지 않으며 인증 경로의 서명 단계를 충족할 자격이 없음을 명시적으로 진술합니다.

다음 절은 출처를 기록합니다. 어느 저장소, 기기 이미지, 패키지, 세리머니 또는 관리자에서 개체를 얻었는가? 어떤 외부 해시, 서명, 보호된 채널 또는 물리적 비교가 무결성을 확립했는가? 어떤 근거가 출처를 인증했고, 어떤 규칙이 출처가 신뢰 정보를 제공할 권한이 있음을 보여주었는가?

그다음은 결정입니다. 영수증은 권한 있는 설치 역할, 결정 시각, 대상 저장소, 영향을 받는 애플리케이션 또는 기기 집단을 이름으로 적습니다. 일반 저장소에의 존재를 보편적 권위로 취급하지 않고, 수용된 네임스페이스, 정책, 용도, 유효 기간을 열거합니다.

마지막으로 수명 주기를 보존합니다. 어떤 기록이 이 기록을 대체하는가? 어떤 사건이 교체나 제거를 요구하는가? 다음 검토의 소유자는 누구인가? 잘못된 설치는 어떻게 바로잡으며, 침해된 관리자나 키는 모든 저장소를 조용히 재구축하지 않고 어떻게 복구할 수 있는가?

공용 또는 팀 간 뷰는 얇게 남을 수 있습니다. 루트 저장소 내용, 관리자 자격 증명, 보안 민감한 배포 경로를 노출할 필요가 없습니다. 개체 다이제스트, 결정 권위, 제한된 범위, 현재 상태, 변경 계보, 바로잡음 연락처를 공개하면서 운영 세부사항은 보호된 증거 저장소에 둘 수 있습니다.

영수증이 개체를 서명된 것으로 만들지는 않습니다. 보편적 권위를 만들거나 지역 신뢰의 중앙 등록을 요구하지 않습니다. 이미 존재하는 결정이 익숙한 파일 확장자 뒤에서 사라지지 않게 할 뿐입니다.

근거 경계

확인된 출처 중 어느 것도 RFC 9925가 얼마나 널리 배포되었는지, 어떤 제품이 지원하는지, 어떤 구현이 이를 잘못 다루는지를 확립하지 않습니다. 승인된 LAMPS 헌장은 포스트 양자 PKIX와 S/MIME 메커니즘에 대한 계속되는 작업을 보여주지만, 헌장은 배포 텔레메트리가 아닙니다. IANA 항목은 할당을 증명할 뿐 올바른 처리를 증명하지 않습니다.

이 글은 모든 자체 서명이 쓸모없다고도 주장하지 않습니다. RFC 9925는 일부 애플리케이션이 사고로 인한 저장소 손상 감지를 위해 자체 서명을 사용한다는 것을 인정하며, 무서명 프로파일은 그 사용을 위해 다른 무결성 메커니즘을 요구합니다. 또한 모든 무서명 인증서가 트러스트 앵커라는 주장도 하지 않습니다. 이 형식은 다른 외부 인증 맥락에서 독립적인 주체 정보를 담을 수 있습니다.

증명할 수 있는 것은 더 좁지만 충분합니다. RFC 9925는 주체 데이터를 발급자 증명에서 의도적으로 분리합니다. 경로 검증기가 빈 서명을 거부하도록 요구합니다. 무결성과 신뢰를 개체 밖에 위치시킵니다. 이것은 건전한 기술적 경계입니다. 거버넌스는 외부 절반을 내부 절반만큼 검사 가능하게 만들어야 합니다.

출처

  1. Lu Heng, “The Policy Mirror”
  2. RFC 9925, “무서명 X.509 인증서”
  3. RFC 5280, “인터넷 X.509 공개 키 인프라 인증서 및 CRL 프로파일”
  4. RFC 4158, “인터넷 X.509 공개 키 인프라: 인증 경로 구축”
  5. RFC 5914, “트러스트 앵커 형식”
  6. RFC 6024, “트러스트 앵커 관리 요구사항”
  7. RFC 8446, “전송 계층 보안(TLS) 프로토콜 버전 1.3”
  8. RFC 8725, “JSON Web Token 모범 현재 관행”
  9. IANA, “관리 정보 구조(SMI) 번호”
  10. IETF, LAMPS 워킹 그룹 헌장