요약

  • RFC 9964는 범용 Algorithm Key Pair 유형을 도입하고 JOSE와 COSE를 위해 ML-DSA-44, ML-DSA-65, ML-DSA-87을 등록하여, 키와 그 알고리즘 매개변수를 일관되게 표현할 수 있게 합니다.
  • 요구되는 표현 필드와 알고리즘 레지스트리는 키의 출처, 발급자 신뢰, 클레임 검증, 수용 정책, 또는 신뢰 당사자(relying party)가 내리는 운영상 결정을 규정하지 않습니다.

보안 시스템에는 유혹적인 실수가 있습니다. 어떤 대상을 식별 가능하게 만드는 필드가 그 대상을 정당한 것으로 만들게 하는 것입니다.alg값은 결정적인 것처럼 보입니다. 검증자에게 기대할 암호학 계열을 알려 주고, 공개 자료와 비밀 자료의 표현 방식을 제한할 수 있으며, 수신된 대상을 소프트웨어가 더 쉽게 처리하도록 만듭니다. 그러나 알고리즘 식별자는 좁은 질문에 답합니다. 이것은 어떤 종류의 계산인가? 이 키가 이 관계에서 신뢰할 만한지, 서명된 진술이 어떤 결과를 가져야 하는지에는 답하지 않습니다.

Michael Prorock와 Orie Steele의 RFC 9964는 이 좁은 역할을 견고한 상호운용성 궤도 위에 올려 놓습니다. 이 IETF 표준 트랙 문서는 JOSE(JSON 주체 Signing and Encryption)와 COSE(CBOR 주체 Signing and Encryption)를 위한 ML-DSA 키와 서명을 규정합니다. 또한 이 RFC가 등록한 특정 알고리즘에 국한되지 않는 알고리즘을 위한 범용 키 유형으로 Algorithm Key Pair, 즉 AKP를 도입합니다. AKP는alg와pub를 반드시 담아야 하며,priv는 비공개 정보를 담고 공개 키에 나타나서는 안 됩니다. 이 구조는 구현이 무엇을 수신했는지, 그 자료에 어떤 규칙을 적용해야 하는지 확정합니다.

이 선택은 비밀 키 처리에서 특히 뚜렷하게 드러납니다. FIPS 204는 ML-DSA에 대해 시드와 확장된 비밀 키 표현을 모두 허용합니다. RFC 9964는 JOSE와 COSE를 위해 하나의 압축 표현을 선택했습니다.priv매개변수는 32바이트 시드입니다. 이것은 실질적인 역할을 합니다. 그렇지 않으면 갈라질 수 있는 표현 하나를 제거하고, 두 생태계에 걸친 키 처리를 단순화하며, 구현이 검증할 수 있는 경계를 고정합니다. 그러나 시드를 누가 생성했는지, 보호되었는지, 공개 키가 어떻게 배포되었는지, 신뢰 당사자가 그것으로 서명된 것을 수용해야 하는지는 증명하지 않습니다.

이 RFC는 또한 ML-DSA-44, ML-DSA-65, ML-DSA-87을 등록합니다. 등록은 명명된 매개변수 선택을 JOSE와 COSE 레지스트리에 연결하기 때문에 유용합니다. 그러나 등록은 보증 엔진이 아닙니다. 검증자는 여전히 발급자, 키 배포 채널, 서명된 대상이 지명하는 주체, 자기 맥락에서 의미 있는 클레임, 그리고 유효한 서명을 허용된 작업으로 전환하는 정책에 대한 독립적인 판단을 필요로 합니다. 유효한alg는 올바른 암호학적 검증을 수행할 수 있게 합니다. 그러나 빠져 있는 연결을 대신 채워 주지는 않습니다.

문서 자체의 운영상 주의 사항도 이 구분을 뒷받침합니다. 이 문서는 ML-DSA 키와 서명이 더 작은 아티팩트를 기준으로 설계된 방식에 비해 크며, 대역폭, 메모리, 처리 제약 때문에 일부 환경에서 부적합할 수 있다고 밝힙니다. 이것은 특정 배포에 대한 평가가 아닙니다. 형식의 정확성과 운영상 적합성은 별개의 질문이라는 상기입니다. 이 표준은 상세한 보안 분석을 명시적으로 범위 밖으로 두고 독자를 FIPS 204와 RFC 9881로 안내합니다.

따라서 Prorock의 공동 기여에 대한 가장 내구적인 독해는 영웅적이라기보다 규율적입니다. RFC 9964는 모호한 표현 문제를 명시적 필드, 단일 시드 형식, 등록된 식별자로 바꿉니다. 이것은 ML-DSA 자료를 교환해야 하는 시스템에 필요한 구성 요소입니다. 신뢰는 원래 있어야 할 곳, 즉 자신의 신뢰 앵커를 명명하고, 키 출처를 설명하고, 클레임을 평가하고, 결정에 대한 책임을 지는 기관 또는 검증자에게 남겨 둡니다.

출처