미해결 논점

Label 309 v1은 동결되었습니다. 메타데이터 라벨 309 아래의 와이어 포맷, 정규 CBOR 인코딩, 알고리즘 레지스트리, 봉인된 PoE 엔벨로프, 그리고 서명 구성은 모두 확정되었습니다. v1 적합 검증자는 모든 v1 레코드를 읽고, v1 적합 생성기는 모든 v1 검증자가 받아들이는 레코드를 출력합니다. 이 페이지의 목적은 그것을 바꾸는 데 있지 않습니다. 여기는 오늘날의 표준에서 무엇이 확정되었는지, 그리고 무엇이 향후 과제로 남아 있는지 — 즉 향후 개정판을 위해 예약된 후보 암호 구성과, 그중 하나가 채택될 때 암호 상수를 규율 있게 변경하기 위한 절차를 기록한 목록입니다.

여기에 적힌 내용 가운데 제품 로드맵에 해당하는 것은 없습니다. 각 항목은 프로토콜 수준의 기술적 결정, 즉 알고리즘 식별자, 유도, 검증자 정책, 또는 버전 관리 규칙입니다. 표준을 구현하는 독자는 오늘 v1 구현을 만들기 위해 확정된 절반을 필요로 하며, 향후의 포스트 양자 또는 RFC 전용 후속 버전이 다시 작성하는 일이 아니라 추가적인 레지스트리 항목이 되도록 구현하기 위해 향후 과제의 절반을 필요로 합니다.

확정된 구성

이것들은 결정되었습니다. 구현자가 한곳에서 가장 자주 확인하고 싶어 하는 핵심 선택이기에 여기서 분명하게 서술합니다. 완전한 구성은 링크된 각 페이지에 담겨 있습니다.

포스트 양자 KEM은 v1로 출시됩니다

하이브리드 KEM인 X-Wing(ML-KEM-768을 X25519와 결합한 것)은 첫 릴리스부터 enc.kem 레지스트리에 식별자 mlkem768x25519로 등록되어 있습니다. 이것은 향후의 후보가 아닙니다. 고전적인 x25519 KEM과 나란히 enc.scheme: 1에 존재하며, 와이어상의 enc.kem 필드가 레코드마다 슬롯 단위의 KEM, 슬롯 형태, 그리고 키 암호화 키 유도를 선택합니다.

X-Wing은 블랙박스로 소비됩니다. 구성은 그 공개 인터페이스, 즉 캡슐화·역캡슐화· 32바이트 공유 비밀만 사용하며, 컴바이너 내부 해싱에 대해서는 어떤 가정도 하지 않습니다. 두 KEM 모두 슬롯 자신의 와이어 바이트에 대해 계산되는 하나의 레이블된 해시 솔트 형태 SHA-256(label || enc.nonce || <slot KEM material> || pub_R) 아래에서 슬롯 단위 KEK를 유도합니다. 하이브리드 경로에서는 SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R)입니다. 고정 길이 32바이트로 해싱함으로써 엔벨로프 nonce, 암호문, 수신자 공개 키를 KEK에 결합하는 동시에, 가변 길이 포스트 양자 암호문이 단순 연결 솔트 아래에서 만들어낼 파서 모호성을 해소합니다. 외부에 노출되는 것은 하이브리드 변형뿐입니다. 순수 ML-KEM은 의도적으로 보류되어, 혹시 ML-KEM-768이 깨지더라도 X25519 레그가 고전적 보안성을 유지하도록 합니다. 봉인된 PoE와 알고리즘 레지스트리를 참조하십시오.

봉인 키 커밋먼트는 헤더와 해시 주장을 결합합니다

두 봉인 경로 모두 콘텐츠 암호화 키를 닫힌 트랜스크립트에 커밋합니다. 이 트랜스크립트는 엔벨로프의 나머지 부분이 사용하는 것과 동일한 정규 CBOR 함수로 직렬화되며, 헤더 필드와 항목의 평문 해시 주장(hashes_hash)을 고정합니다. 수신자 주소 지정 (enc.slots) 경로에서는 이 커밋먼트가 온체인에 있습니다. slots_mac은 스킴, 경로, AEAD 및 KEM 식별자, nonce, 셔플된 슬롯 집합, 그리고 hashes_hash를 담은 트랜스크립트에 대한 CEK 키 부착 HMAC입니다. 따라서 릴레이는 암호문을 가져오기 전에 온체인 MAC 검사가 실패하지 않고서는, 어떤 암호문을 다른 슬롯 집합이나 다른 해시 주장에 이어 붙일 수 없습니다. 패스프레이즈(enc.passphrase) 경로는 Argon2id 솔트와 매개변수를 추가한 트랜스크립트에 대한 동등한 커밋먼트를 암호문 블롭 내부의 32바이트 헤더에 담습니다. 이로써 KDF 입력을 조작하면 커밋먼트 검사가 실패합니다. 그런 다음 콘텐츠 자체는 CEK에서 유도한 콘텐츠 키 아래, 세그먼트화된 STREAM으로 봉인됩니다. 청크별 AAD는 비어 있는데, 모든 헤더 필드가 이미 그 키에 전이적으로 결합되어 있기 때문입니다. 완전한 구성은 봉인된 PoE에 있습니다.

확인 깊이는 검증자 정책입니다

레코드는 그 트랜잭션이 포함되는 순간 기록되지만, 판정을 보고하기 전에 얼마만큼의 정산을 요구할지 결정하는 검증자는 확인 깊이 임계값을 적용합니다. Label 309는 이것을 규범적 MUST가 아니라 검증자 정책으로 규정합니다. 표준이 정의하는 것은 기계 판독 가능한 표면입니다. 즉 임계값을 밑도는 트랜잭션은 pending(타입화된 코드 INSUFFICIENT_CONFIRMATIONS)으로 보고되며, 결코 failed가 되지 않고, 재시도 시 valid로 해소될 수 있습니다. 한편 임계값 자체(권장은 15블록 이상)는 와이어 포맷에 구워 넣은 상수가 아니라 배포 시 설정되는 입력입니다. 고가치 주장에 대해 더 깊은 정산을 요구하는 검증자도 완전히 적합합니다. 검증을 참조하십시오.

Ed25519 검증은 엄격합니다

레코드 수준 서명은 더 관대한 ZIP-215 일괄 검증 허용치가 아니라 RFC 8032 §5.1.7의 엄격한 규칙 아래에서 검증되어야 합니다(MUST). 엄격한 검증은 관대한 검증자라면 받아들일 비정규 인코딩과 소위수 점을 거부하므로, 두 적합 검증자는 동일한 서명에 대해 항상 동일한 판정에 도달합니다. 구현자는 자신의 Ed25519 백엔드가 엄격 모드인지 확인해야 합니다. 일부 라이브러리는 기본적으로 관대한 변형을 사용합니다. 서명을 참조하십시오.

정규 CBOR은 결정성 계약입니다

모든 레코드는 RFC 8949 §4.2.1에 따른 정규 CBOR로 인코딩됩니다. 즉 정수는 선호 형식, 배열과 맵은 확정 길이, 맵 키는 바이트 단위로 정렬, 중복 키 없음, 태그 없음입니다. 결정성이야말로 한 구현이 본문에 대해 계산한 서명을 다른 구현이 검증할 수 있게 하고, 동일한 논리적 레코드를 생성하는 두 생성기가 바이트 단위로 동일한 바이트를 출력할 수 있게 합니다. 이는 모든 적합 구현에 걸쳐 타협의 여지가 없으며, 언어 간 패리티 계약의 토대입니다.

향후 과제 후보

아래 항목들은 후보이지, 출시된 구성이 아닙니다. 어느 것도 v1의 결함이 아니며, 어느 것도 확약되지 않았습니다. 이것들을 기록해 두는 까닭은 오늘 구축되는 구현이 이것들을 추가적인 레지스트리 항목으로 받아들일 여지를 남기도록, 그리고 미래의 검토자가 알고리즘 교체 가능(algorithm-agile) 설계가 이미 어떤 진화를 내다보고 있는지 파악할 수 있도록 하기 위함입니다.

예약된 대체 콘텐츠 AEAD 프로파일

v1 봉인된 PoE의 콘텐츠 계층은 chacha20-poly1305-stream64k, 즉 세그먼트화된 STREAM 레이아웃으로 만든 RFC 8439 ChaCha20-Poly1305입니다. 이것 자체가 RFC에 뒷받침되므로, 현재의 콘텐츠 암호의 형식적 지위에 관해서는 미해결 문제가 없습니다. 예약된 채 남아 있는 것은, 어떤 배포 환경이 장차 그것을 요구할 경우 다른 콘텐츠 AEAD로 이르는 경로입니다. 식별자 aes-256-gcm(NIST SP 800-38D)은 그 목적으로 AEAD 레지스트리에 예약되어 있으며 enc.scheme: 1의 일부가 아닙니다. 이를 지정한 레코드는 오늘날 미지의 엔벨로프 규칙을 따릅니다.

이것을 도입한다면, 그것은 기존의 slots[] + slots_mac 모델과 패스프레이즈 커밋먼트 모델을 보존하면서 콘텐츠 계층만 교체하는 향후의 enc.scheme: 2 구성이 될 것이며, 그 암호에 대한 새로운 청크 크기, 콘텐츠 키 유도, 청크별 nonce 구성, 청크별 AAD, 그리고 최종 청크 인증을 고정합니다. 이것은 대체물이 아니라 폴백 프로파일입니다. 기존의 enc.scheme: 1 레코드는 유효한 채로 남고, 이 프로파일은 규범적인 enc.scheme: 2 정의와 그 테스트 벡터가 존재하기 전에는 구현되어서는 안 됩니다.

예약된 포스트 양자 서명 알고리즘

포스트 양자 궤적의 KEM 절반은 v1로 출시됩니다(위 참조). 서명 절반은 예약되어 있으나 아직 구현되지 않았습니다. IETF COSE가 포스트 양자 알고리즘 식별자를 안정화하는 대로 기존 서명 레지스트리에 들어갈 후보로 두 계열이 있습니다.

서명 알고리즘은 COSE 보호 헤더 내의 명명된 식별자이므로, 후속 알고리즘을 등록하는 것은 순수하게 추가적입니다. 기존 Ed25519 레코드는 계속 검증되며, 새 서명 알고리즘을 인식하지 못하는 검증자는 콘텐츠 주장을 거부하는 대신 미지원 알고리즘 신호를 보고합니다. 인식되지 않는 서명이 그 바탕에 있는 존재 증명을 무효화하는 일은 결코 없습니다. 서명을 참조하십시오.

잠재적인 v: 2 발행 경로

개별적인 추가 — 새 KEM, 새 콘텐츠 AEAD, 새 서명 알고리즘 — 는 최상위 레코드 스키마를 바꾸지 않는 레지스트리 항목입니다. 특히 KEM 추가는 스킴 범프가 아니라 enc.scheme: 1 아래의 레지스트리 항목입니다. enc.scheme 범프는 KEM을 가로지르는 구성 변경(모든 KEM에 한꺼번에 적용되는 새 slots_mac이나 콘텐츠 AEAD)을 위해 예약되어 있습니다.

레코드 스키마를 바꾸는 후보가 충분히 쌓이면, 그 누적된 변경은 v1과 나란히 발행되는 최상위 v: 2 레코드를 정당화할 수 있습니다. 두 버전 모두 라벨 309 아래의 유효한 메타데이터 스키마로 남고, 검증자는 레코드 내부의 v 판별자에 따라 선택합니다. 표준화로 가는 단계들은 새 개정판에 대해 반복됩니다. 이것은 가장 영향 범위가 넓은 진화이며, 오직 누적에 의해서만 촉발됩니다. 여기에 일정이 잡힌 것은 아무것도 없습니다.

선택적인 단일 홉 대체 관계 해석

레코드의 선택적 supersedes 필드는 트랜잭션 해시로 더 이른 레코드 하나를 가리킵니다. 그 포인터를 해석하는 것은 검증자에게 선택 사항입니다. supersedes가 구조적으로 32바이트 해시임을 확인하되 이전 트랜잭션을 가져오지 않는 검증자도 적합하지만, 대체 관계 사슬을 드러낼 기회를 놓치게 됩니다. 지침은 다음과 같습니다. 검증자는 한 홉만 해석해도 됩니다 (MAY). 즉 참조된 해시에 대해 트랜잭션 리졸버에 다시 질의하여 그 존재와 블록 시각을 보고하되, 그 이상 재귀하지는 않습니다. 한 홉으로 충분하며, 그보다 깊은 탐색은 호출자의 책임입니다. 그리고 대체 관계는 더 이른 레코드를 결코 폐기하지 않으며, 그 레코드는 체인이 독립적으로 검증 가능한 상태로 영구히 보존합니다.

암호 상수 마이그레이션

위의 확정된 구성은 모두 명명된 상수, 즉 알고리즘 식별자, HKDF info 문자열, KDF 솔트, AEAD nonce 길이, 도메인 분리 레이블에 의존합니다. 그중 어느 하나의 의미를 바꾸는 것은 와이어 포맷 파괴이며, 표준은 그것을 위한 단 하나의 규율 있는 경로를 규정합니다. 통괄하는 규칙은 다음과 같습니다. 문제를 해결하는 최소 범위의 변경을 사용하고, 동일한 이름공간 아래에서 기존 상수의 의미를 몰래 바꾸어서는 결코 안 됩니다.

이 절차는 추가적이고 하위 호환적입니다. 오래된 레코드는 발행될 당시의 상수 아래에서 계속 검증되며, 범위에 따라 다음과 같이 진행됩니다.

1. 값이 아니라 이름공간에 버전을 매깁니다. 유도가 바뀌면 그것이 건드리는 모든 도메인 분리 문자열의 -vN 접미사를 증가시킵니다. 즉 HKDF info 문자열(…-v1 → …-v2), HMAC 메시지 접두사, 솔트, 그리고 레이블입니다. 새 상수는 새 접미사 아래에 존재하고, 오래된 상수는 옛 접미사 아래에서 유효한 채로 남습니다. 더 오래된 검증자는 새 레코드를 잘못 해석하는 대신 판별자 단계에서 깔끔하게 거부합니다.

2. 영향 범위에 맞는 판별자를 범프합니다. 하나의 슬롯 계열에 국한된 변경은 enc.kem으로 선택됩니다. 콘텐츠 계층이나 슬롯 집합 커밋먼트에 대한 KEM을 가로지르는 변경은 enc.scheme 범프입니다. 레코드 스키마 자체에 대한 변경은 최상위 v 범프입니다. 각 판별자는 파괴를 실제로 바뀐 가장 작은 계층에 국한시킵니다.

3. 선행 버전을 검증 가능하게 유지합니다. 더 오래된 레코드 버전은 동결된 스키마로 계속 읽을 수 있습니다. 검증자는 레코드 자신의 버전 판별자로 구성을 선택하므로, 단일 구현이 v1과 미래의 후속 버전을 나란히 검증할 수 있습니다. 후속 버전이 출시되었다는 이유로 검증되지 않게 되는 레코드는 단 하나도 없습니다.

관련 페이지

• 알고리즘 레지스트리 — 마이그레이션 아래에서 이름공간이 버전을 매기는, 명명된 식별자.
• 봉인된 PoE — X-Wing 하이브리드 KEM, 키 커밋먼트 트랜스크립트 결합, 그리고 enc.scheme / enc.kem 판별자.
• 서명 — 엄격한 Ed25519 검증과, 예약된 포스트 양자 알고리즘이 합류할 서명 레지스트리.