요약

  • RFC 9881은 순수(pure) ML-DSA-44, ML-DSA-65, ML-DSA-87 변형을 인증서와 CRL에서 PKIX 방식으로 사용하는 방법을 정의한다.
  • 전체 OID는 ML-DSA-44의 경우2.16.840.1.101.3.4.3.17, ML-DSA-65는2.16.840.1.101.3.4.3.18, ML-DSA-87은2.16.840.1.101.3.4.3.19이며, 각각 보안 수준 2, 3, 5에 대응한다.
  • AlgorithmIdentifier의parameters필드는NULL로 인코딩되어서는 안 되며 반드시 생략되어야 한다. 원시 서명은 빈 컨텍스트로 DER로 인코딩된 서명 대상 구조에 대해 계산된다.

PKIX에서 알고리즘 식별은 바이트 단위의 규약이다. OID는AlgorithmIdentifier에 담기고 ML-DSA 원시 서명은signatureValue에 담긴다. 검증자는 겉보기에 유사한 새 직렬화가 아니라 서명 대상 구조의 DER 인코딩에 대해 서명을 검증해야 한다. 이 PKIX 용도에서는 선택적 컨텍스트가 비어 있어야 한다.

SubjectPublicKeyInfo에는 추가 ASN.1 감싸기 없이 ML-DSA 공개 키 바이트 문자열이 직접 담긴다. 크기는 ML-DSA-44의 경우 1,312바이트, ML-DSA-65는 1,952바이트, ML-DSA-87은 2,592바이트이다.keyUsage가 존재하는 경우 서명 관련 비트 중 최소 하나는 설정되어야 하며, ML-DSA 키에서는 암호화와 키 교환 비트가 반드시 없어야 한다. 이는 운영 조언이 아니라 규범적 요구사항이다.

OneAsymmetricKey는 시드, 확장된 키, 또는 둘 다를 담을 수 있다. 공간 절약을 위해 시드만 담는 형태가 권장된다. 파서는 가정된 길이가 아니라 ASN.1 태그에 따라 표현을 선택해야 한다. 두 형태가 모두 존재하고 일관성 검사가 실패하면, 수신자는 해당 키를 형식 오류로 반드시 거부해야 한다.

RFC 9881은 순수 ML-DSA를 유지한다. HashML-DSA OID는 해당 PKIX 프로토콜에서 사용해서는 안 된다. 표준화 이전 Dilithium과의 경계도 명확하다. ML-DSA와 Dilithium은 호환되지 않는다. 따라서 익숙한 이름이 다른 와이어 형식의 수용을 정당화하지 않는다.

출처