요약

  • RFC 9323은 자원 보유자가 디지털 객체의 체크섬 목록에 서명해 그 목록을 자신이 만들었다고 증명하는 형식을 정한다.
  • RIPE NCC는 2024년 API 지원을 계획했고 연례 보고서에서 작업을 보류했다. 2026년 4분기 계획에서도 실행은 조건부다.

RSC 표준은 거의 4년 전에 나왔다. 운영자가 실제 업무에 쓸 API는 아직 일정표에 자리를 기다린다.

RPKI Signed Checklist(RSC)는 디지털 객체의 체크섬을 나열하고 특정 인터넷 번호 자원으로 서명한다. 서명을 검증하면 해당 자원의 보유자가 목록을 만들었다는 점을 확인할 수 있다. RFC 9323은 Bring Your Own IP 도입 과정이나 네트워크 간 물리적 상호접속에서 자원 보유를 확인하는 사례를 든다.

RSC가 답하는 질문은 구체적이다. 지정된 인터넷 번호 자원의 보유자가 이 체크섬 목록을 만들었는가? BYOIP 도입이나 네트워크 간 물리적 상호접속에서 받는 쪽은 이 증거를 확인 절차에 가져갈 수 있다.

전달 방식도 표준이 정하지 않는다. RSC는 전 세계 RPKI 저장소에 게시되지 않으며, 전송 채널은 구현자가 선택한다. 웹 화면이나 서명된 이메일, 다른 경로로 전달할 수 있다. API는 생성과 관리를 편하게 만들 수 있지만 서비스 접근 방식 중 하나이지 표준 자체는 아니다.

RIPE NCC의 기록을 보면 일정이 보인다. 2024년 활동 계획은 RSC와 BGPSec을 먼저 API로 구현하고 나중에 RPKI 대시보드에 넣는 순서를 제안했다. 2024년 연례 보고서는 이 약속을 “보류”로 표시했고, RSC·BGPSec·ASPA는 2025년 계획에 올랐다.

2026년 4분기 RPKI 계획에서 RSC API는 여전히 “계획됨”이다. 구현은 팀 여력과 두 가지 다른 작업의 진척에 달려 있다. 하나는 API 키와 OpenID Connect이고, 다른 하나는 조직 전체 ISO 27001 심사와 새 SOC 2 Type II 심사를 포함한 컴플라이언스 작업이다. 대시보드 화면은 수요가 있으면 나중에 추가될 수 있다. 계획에는 출시 분기도, 지연의 단일 원인도 적혀 있지 않다.

차이는 완성된 형식과 운영자가 업무에 넣을 수 있는 서비스 사이에 있다. 공개 문서에는 다른 도구나 채널을 통해 이미 쓰이는 RSC 수량이 없다. 대신 RFC의 시계와 호스팅 서비스의 시계가 다르게 간다는 점은 드러난다.

BYOIP 도입이나 상호접속을 준비하는 팀은 API가 “계획됨”인 동안 증거 전달과 확인 절차를 업무 흐름에 남겨둬야 한다. 미래의 API가 전달 단계를 줄일 수는 있다. 서명이 어떤 자원을 다루는지와 거래 상대가 누구인지는 여전히 따로 확인해야 한다.

RFC는 완성됐다. 이제 달력, 화면, 그리고 구현할 팀의 시간이 필요하다.

출처