요약

  • IANA는 알고리즘 18을 ML-DSA-44로 기록하고 서명과 검증의 사용 및 구현에 MAY를 부여했다. 제출한 DS 데이터는 등록기관의 EPP 규칙을 다음으로 통과해야 한다.
  • RIPE 93에서 Joe Abley는 검증보다 앞선 이 접수 장벽을 지적했다. 그의 10월 개인 초안은 DNSSEC 알고리즘과 다이제스트의 수용 기준을 IANA 등록부에 연결하자고 제안한다.

번호는 생겼다. 신청은 다음 창구에서 멈출 수 있었다.

10월 29일 RIPE 93 DNS 세션에서 Joe Abley는 EPP로 알고리즘 18을 제출하려던 경험을 들려줬다. 자신이 확인한 시스템에는 이를 수용하는 등록기관이 없었다고 했다. 이어 Garth Miller와 이야기를 나눈 뒤 유지관리자가 코드 변경을 병합한 사례를 예외로 들었다. 대화 한 번과 병합 한 번이 한 경로를 열었지만, 다른 등록기관이 예측할 공통 규칙을 만들지는 않았다.

IANA의 DNSSEC 알고리즘 표에는 18번이 ML-DSA-44로 올라 있다. 영역 서명에 쓸 수 있고, 서명 및 검증의 사용·구현 요구 수준은 MAY다. 이 표기는 허용되는 요구 수준을 기록한다. 등록기관, 서명 시스템, 검증 리졸버의 배포 여부는 별도의 운영 상태다.

EPP 세부 규칙은 작지만 부모 영역까지 데이터가 도달할지를 결정한다. RFC 5910은 EPP로 DS 데이터를 전달한다. alg는 DS가 가리키는 DNSKEY 알고리즘을, digestType은 DS를 만드는 데 쓴 다이제스트 방식을 가리킨다. 10월 14일자 Joe Abley의 개인 초안은 이 두 항목을 다룬다. DNSSEC 보호를 제공할 수 없는 값을 제외하고 IANA의 DNSSEC 알고리즘·다이제스트 등록부를 공통 수용 기준으로 삼자는 내용이다. Datatracker에는 개인 초안 00판만 I-D Exists 상태로 등록돼 있으며, IETF 표준 지위는 없다.

이제 통제 지점이 보인다. 서명자는 새 알고리즘을 준비하고 IANA는 번호를 부여할 수 있다. 그래도 부모 영역의 등록기관은 등록대행자가 DS를 제출하도록 허용할지 결정한다. 요청이 거부되면 자식 영역은 알고리즘 전환에 필요한 부모 측 단계를 끝내지 못한다. 공개되지 않은 로컬 허용 목록은 표준 변경을 추측 게임으로 만든다.

접수와 검증은 서로 다른 판단이다. 알고리즘을 지원하지 않는 리졸버는 해당 DS를 무시한다. 지원하는 DS가 하나도 남지 않으면 그 리졸버는 자식 영역을 서명되지 않은 것으로 취급한다. EPP는 제출 경로를 열고, 리졸버 지원은 별도의 배포 단계에서 결정된다.

초안에는 시험한 등록기관 이름, 날짜, EPP 수용값을 함께 적은 표가 없다. 이 자료가 공개되면 정책 차이의 범위를 확인할 수 있다.

1차 자료: RIPE 93 발표 · RIPE 93 DNS 세션 녹취록 · IANA DNSSEC 알고리즘 등록부 · RFC 5910 · RFC 4035 · Joe Abley 개인 초안 00판.