요약

  • ACME 개인 인터넷 초안 01판은 00판의 엄격한 양자 대비 프로필을 없앴다. 이전 프로필은 TLS 서버와 JWS 요청에 양자 내성 또는 혼합 서명을 요구하고, 기존 서명만 사용하는 대체 경로를 거부했다.
  • 새 문안은 서버가 ES256 구현을 생략할 수 있게 한다. 현재 RFC 8555 6.2절은 ES256 구현을 의무로 둔다. ES256을 유지한 서버는 자신이 정한 전환 기간 동안 기존 방식의 JWS 서명을 받을 수 있다.

암호화된 통로와 인증서 주문서는 다른 문이다

자동 인증서 갱신을 운영하는 조직이 ACME 연결의 키 교환을 양자 내성 또는 혼합 방식으로 바꾼다. 오늘 수집된 통신 내용을 미래에 해독하려는 공격에는 중요한 변화다. 그러나 인증서 발급 요청은 별도의 계정 키로 JWS 서명을 한다. 서버가 그 서명에 옛 알고리즘을 계속 허용하면, 누가 발급 주문을 넣을 수 있는지 결정하는 문은 그대로 남는다. 새 통로가 주문서를 대신 심사하지 않는다.

6월 문안은 이 차이를 엄격 프로필로 구분했다. TLS 서버 인증과 고객의 JWS 요청 인증 모두 양자 내성 단독 또는 혼합 서명을 써야 했고, 기존 방식만으로 돌아갈 수 없었다. 10월 문안은 해당 조항을 지웠다. 남은 ‘Quantum-Ready Mechanism’은 TLS 1.3 이상과 양자 내성 또는 혼합 키 교환을 요구하고 새 인증 방식을 지원한다. 기존 방식만 쓰는 인증은 명시적으로 한정된 전환기 동안 허용할 수 있다. 모든 사업자에게 적용되는 종료일은 없다.

4.2절의 선택지도 달라졌다. 6월에는 참여 서버가 특정 ML-DSA 방식들과 복합 서명을 구현해야 했고 ES256도 남겨야 했다. 10월에는 JOSE 등록부의 JWS 알고리즘을 서버가 지원할 수 있다고 하면서, 특정 알고리즘이나 매개변수 집합을 의무로 지정하지 않는다. ES256을 구현하지 않는 선택도 가능하다. 반대로 옛 고객을 위해 유지한다면, 사업자가 고른 기간에는 기존 JWS 서명을 계속 받을 수 있다. 같은 ‘양자 대비’ 명칭 아래에서도 한 서버는 요청을 거절하고 다른 서버는 통과시킬 수 있다.

문서 안에는 아직 맞춰야 할 문장도 있다. 도입부는 양자 내성 및 혼합 서명을 구현 의무라고 부르지만, 4.2절은 ‘MAY’를 쓰고 특정 JWS 알고리즘을 강제하지 않는다고 밝힌다. 상호운용 시험의 합격 조건을 만들려면 어느 표현이 실제 요구사항인지 먼저 정리해야 한다. IETF 추적 페이지는 이를 10월 28일 갱신된 개인 초안으로 분류한다. 실제 배포 수치나 공통 차단 시점은 제시되지 않았다. 서버가 허용 알고리즘과 종료일을 공개하고, 그 날짜 이후 옛 서명을 거부하는 시험 결과가 나오면 판단 근거가 생긴다.

자료: 10월 개정판; 6월 원안; RFC 8555; IETF 상태.