요약

  • RFC 6916은 RPKI 알고리즘 마이그레이션을 인증기관, 공개 저장소, 신뢰 당사자가 함께 조율해야 하는 순차적 절차로 규정한다. 국지적인 소프트웨어 전환이 아니다.
  • 상위 우선(parent-first) 계획은 단계적 중첩 기간 동안 구 알고리즘 체계와 신 알고리즘 체계 아래 대응하는 산출물을 유지한 뒤, 검증자를 위한 이정표와 최종 수명 종료일을 정한다.
  • 문서는 이 과정이 수년 걸릴 수 있다고 밝히며 긴급 전환은 규정하지 않는다. 이는 질서 있는 변경을 위한 계획이지, 갑작스러운 암호 실패에 대한 즉석 해답이 아니다.

암호 변경은 소프트웨어 업데이트가 아니다

애플리케이션 하나에서 서명 알고리즘을 바꾸는 일은 통제된 엔지니어링 작업처럼 들릴 수 있다. 그러나 Resource Public Key Infrastructure에서는 서명된 각 진술이 계층 구조 안에 놓인다. 인증기관(CA)은 그 아래의 CA를 인증하고, 그 자식 CA는 트리 더 아래 자원에 대한 인증서와 서명 객체를 발급할 수 있다. 신뢰 당사자(RP)는 공개된 자료를 가져와 체인과 그 서명 산출물이 검증되는지 판단한다. 그런 다음 네트워크 운영자는 RPKI 검증 결과를 자체 라우팅 정책에 사용할 수 있다.

이것들은 서로 다른 행동이다. 인증서가 발급되었다고 해서 모든 저장소가 일치하는 자료를 공개했다는 뜻은 아니다. 공개되었다고 해서 모든 RP가 이를 검증할 수 있다는 뜻도 아니다. 검증 결과 하나가 라우터가 무엇을 받아들일지를 그 자체로 규정하지도 않는다. 운영자는 그 이후 지점에서 정책을 정한다. RFC 6916의 설계 문제는 이 각 단계를 지나는 사용 가능한 경로를 유지하면서 암호 체계를 어떻게 바꿀 것인가였다.

기록의 흔적은 귀속에 중요하다. RFC 6916, “Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)”는 2013년 4월 Best Current Practice 182로 발표되었다. 저자로는 Roque Gagliano, Stephen Kent, Sean Turner가 명시되어 있다. 이 문서는 IETF 합의 표준이며, 어느 한 저자가 내린 개인적 지시가 아니다.RFC 6916

일정이 대체 알고리즘보다 먼저 나왔다

RFC 6916은 새 알고리즘을 지목하지 않는다. 2013년 당시 이 문서는 향후 전환이 RFC 6485가 정의한 RPKI 알고리즘 프로파일을 먼저 갱신하는 것으로 시작해야 하며, 그 뒤에 별도의 전환 일정이 따라야 한다고 밝혔다. 이후 RFC 7935가 RFC 6485를 폐기하고 현재 적용되는 프로파일을 규정한다. 향후 전환에는 인증서에 새 라벨을 붙이는 것만으로는 부족하고 해당 프로파일 자체가 갱신되어야 한다. 일정에는 다섯 개의 날짜가 명시될 것으로 예상된다. CA가 새 체계로 발급할 준비를 갖춰야 하는 시점, 산출물을 재발급해야 하는 시점, RP가 준비를 갖춰야 하는 시점, 구 체계가 선택 사항이 되는 시점, 그리고 수명이 종료되는 시점이다.RFC 7935

정밀도는 의도적으로 거칠지만 조율되어 있다. RFC 6916은 각 이정표가 UTC 자정 1분 후에 발효된다고 가정한다. 또한 각 단계마다 CA와 RP의 준비 지표를 요구한다. 따라서 날짜는 단순한 프로젝트 관리상의 편의가 아니다. 날짜는 저장소, 신뢰 당사자 소프트웨어, 자원 인증서, 운영자에게 특정 시점에 어떤 버전의 신뢰 체인을 사용할 수 있어야 하는지를 알려준다.

새 알고리즘과 새 키의 구분도 똑같이 중요하다. RFC 6489는 이미 알고리즘 체계가 동일하게 유지될 때의 CA 키 롤오버를 설명한다. RFC 6916은 암호 체계 자체가 바뀌는 더 파괴적인 경우를 다룬다. 키 하나를 교체할 수 있는 절차가 인증서, 폐기 목록, 매니페스트, 서명 객체에 사용되는 알고리즘의 변경까지 해결한다고 단순히 가정할 수는 없다.RFC 6489

상위가 먼저 움직이는 이유

RFC 6916은 하향식 마이그레이션을 요구한다. 자식 CA는 상위 CA가 새 체계로 인증서를 발급할 수 있기 전까지 상위에 새 체계 인증서를 요청할 수 없다. 이 규격은 또한 서명 알고리즘과 주체 키 알고리즘이 서로 다른 체계에 속하는 CA 인증서를 피한다. 이런 순서가 없다면 마이그레이션은 혼합 체계 인증서와 더 복잡한 저장소 구조를 관리해야 했을 것이다. RFC는 하향식이 아닌 접근이 저장소 데이터의 기하급수적 증가를 초래할 수 있다고 경고한다.

이것은 신뢰 계층이 제어면으로 작동하는 모습이다. 상위 CA의 준비 상태는 자식들에게 의존 조건이며, 자식이 우회할 수 있는 표결이 아니다. 이 표준은 그 순서를 가시화함으로써 대응한다. 먼저 준비, 다음 발급, 다음 신뢰 당사자 지원, 마지막으로 구 체계의 은퇴다. 그리고 하나의 중앙 행위자가 모든 하위 시스템을 명령으로 움직일 수 있다고 주장하지 않는다.

병행 산출물이 시간을 번다

RFC는 전환을 여러 단계로 나누어, 새 체계가 도입되고 시험되는 동안 구 체계가 계속 운영을 지원할 수 있게 한다.

Phase 0에서는 현재 체계만 지원된다. Phase 1은 CA Ready 날짜에 시작된다. 비말단 기관은 새 체계를 사용하는 요청을 처리할 수 있어야 하지만, RP는 여전히 운영 목적으로 구 체계를 사용한다. 새 체계 산출물은 시험용으로 발급될 수 있으며, 가급적 별도의 공개 지점에서 이뤄진다.

Phase 2는 CA Go 날짜에 시작된다. 이제 각 서명 산출물 집합은 두 체계 모두에 대응하는 버전을 가져야 한다. 구 집합은 계속 사용 가능하며, 준비된 RP는 새 집합 검증을 시작할 수 있다. 이 중첩 기간 동안 RFC는 ROA에 담긴 경로 발원 데이터처럼 대응하는 산출물이 일치할 것으로 기대하며, 타이밍 차이는 감안한다. 많은 CA가 준비되지 않았다면 일정은 다시 발표되어야 한다. RP 지원은 아직 의무가 아니지만, 그쪽에 문제가 있으면 다음 이정표를 늦출 이유가 된다.

Phase 3은 RP Ready 날짜에 시작된다. 모든 RP는 새 체계를 검증할 수 있어야 하며, 두 집합이 모두 남아 있는 동안 새 체계 산출물을 우선하도록 권장된다. 상당수가 그렇게 할 수 없다면 전환 일정은 움직여야 한다. Phase 4는 Twilight 날짜에 시작된다. 새 체계는 RP와 CA에 필수가 되고, 구 체계 산출물은 여전히 존재할 수 있지만 더 이상 완전하지 않을 수 있다. 수명 종료 시점에는 구 체계가 폐기되고 그 신뢰 앵커 로케이터가 공개 지점에서 제거되어야 한다.RFC 6916, Sections 4 and 10

대비책은 일정 자체에 설계되어 있다. 새 산출물을 검증하지 못하는 신뢰 당사자는 구 산출물이 여전히 요구되고 사용 가능한 동안 그것으로 계속할 수 있다. 이는 두 버전이 영원히 공존한다는 약속이 아니다. 양쪽이 시험하고 비교하며 준비 문제를 드러낼 수 있는, 한정된 중첩 기간이다. 구 경로가 은퇴하기 전까지 말이다.RFC 6481

실패 경계는 공유된다

이 절차는 발급자와 검증자 모두에게 실패할 수 있는 지점을 준다. RFC 6916은 구 체계의 수명 종료 이후까지 마이그레이션을 마치지 못한 CA가 더 이상 유효하지 않은 서명 산출물을 갖게 된다고 경고한다. 자체 전환을 완료하지 못한 RP는 새 체계 산출물을 검증할 능력을 잃는다. 그 결과 RPKI가 보여주는 라우팅 정보의 시야가 더 좁아지거나 불완전해질 수 있다.

이것은 신뢰성 문제이지, 모든 경로가 사라진다는 주장이 아니다. RP는 검증 데이터를 만들어내고, 라우터와 운영자가 그것을 어떻게 다룰지 결정한다. 누락되거나 유효하지 않은 산출물은 경로 발원 검증에 영향을 줄 수 있지만, 최종적인 라우팅 효과는 로컬 정책, 소프트웨어, 어떤 자원이 포함되는지에 달려 있다. 이 표준은 불완전한 검증의 위험을 지목하며, 장애 규모를 수치화하거나 보편적인 경로 거부 결과를 부여하지 않는다.

설계의 보수적 일정에는 분명한 한계도 있다. 초록은 전환이 수년 걸릴 것으로 예상되며 긴급 전환은 규정되지 않는다고 밝힌다. 계획된 교체에서는 이런 생략이 합리적일 수 있다. 새 체계는 광범위한 구현과 공개 지원을 필요로 하기 때문이다. 그러나 다른 질문은 답하지 않은 채 남는다. 다년 마이그레이션이 끝나기 전에 기존 체계나 키가 안전하지 않게 된다면 어떻게 되는가? RFC 6916은 그 위기 절차를 제공하지 않는다.

기록 속 Gagliano의 자리

Cisco의 공개 프로필은 Gagliano를 Principal Solutions Engineer로 소개하며, 그가 이전에 LACNIC, ANTEL, Sprint에서 엔지니어링 및 아키텍처 역할을 맡았다고 밝힌다. 그 배경은 운영자, 레지스트리, 벤더 경험을 그의 표준화 작업과 나란히 놓지만, 그 프로필이 그가 특정 RFC 조항을 지지한 이유를 입증하지는 않는다. RFC 자체가 기록하는 더 안전한 주장은 이것이다. 그는 마이그레이션 준비 상태를 다음 서명 알고리즘만이 아니라 RPKI 체인 전체의 속성으로 다루는 합의 절차를 공동 집필했다.Cisco author profile

RFC 7935의 현재 알고리즘 프로파일은 2048비트 키를 쓰는 RSA와 SHA-256을 규정한다. 2026년에는 정보성 인터넷 드래프트가 병행 공개와 혼합 트리 접근을 포함해 포스트 양자 후보와 마이그레이션 구조를 검토하고 있다. 저자들은 이 문서가 RFC 7935나 RFC 6916을 갱신하지 않고, 운영 프로파일을 선택하지 않으며, 평가된 선택지를 실제 RPKI 사용에 승인하지도 않는다고 밝힌다. 그 경계는 중요하다. 새로운 실험은 엔지니어링 질문이 탐구되고 있다는 증거이지, 운영 전환이 승인되거나 일정에 올랐다는 증거가 아니다.RFC 7935;draft-yoshikawa-sidrops-pqc-rpki-02

RFC 6916의 오래 남는 기여는 절차적이다. “더 강한 알고리즘을 지원하라”를 관찰 가능한 의존 조건의 집합으로 바꾼다. CA가 새 체계를 발급해야 하고, 각 공개 지점이 대응하는 서명 산출물을 실어야 하며, RP가 그것을 검증해야 하고, 준비가 입증될 때까지 구 신뢰 경로가 유지되어야 한다. 이 규칙집은 또한 스스로 해결하지 않는 것도 드러낸다. 준비 상태를 어떻게 측정하는지, 늦은 참여자를 어떻게 지원하는지, 긴급 상황이 계획된 마이그레이션과 어떻게 다른지다. 다음 결정들은 바로 그 지점에서 운영자와 표준 참여자들이 내려야 한다.