요약

  • RFC 9691은 트러스트 앵커가 대체(successor) 키를 대역 내(in-band)로 알릴 수 있게 하지만, 신뢰 당사자(relying party)는 30일 수용 타이머가 진행되는 동안 현재 키를 계속 사용합니다.
  • 전환 기록은 대체 키 공개, 상호 키 검증, 안정적 관찰, 신뢰 당사자 전환, 그리고 레거시 지원의 의도적 은퇴를 구분해야 합니다.
  • 한 검증기 또는 한 집단에서 얻은 근거가 모든 신뢰 당사자가 새 키를 채택했다는 증명이 되지는 않습니다.

트러스트 앵커 로케이터(TAL)는 의도적으로 작게 유지됩니다. RFC 8630에 따라 TAL은 RPKI 신뢰 당사자에게 트러스트 앵커 CA 인증서를 어디서 가져올지 알려주고, 가져온 자체 서명 인증서가 의도된 앵커임을 검증하는 데 필요한 공개 키를 제공합니다. 이 대역 외(out-of-band) 핀은 강력하지만, 그만큼 트러스트 앵커 키 변경을 일반적인 리포지토리 갱신처럼 다룰 수 없다는 의미이기도 합니다.

RFC 9691은 대역 내 트러스트 앵커 키(TAK) 객체를 추가합니다. TAK는 현재 공개 키와 인증서 위치를 명시하고, 대체 공개 키와 그 위치를 함께 알릴 수 있습니다. 대체 키는 단지 나타났다는 이유만으로 수용되지 않습니다. 신뢰 당사자는 대체 키 계층을 검증하고 양방향 연속성을 확인합니다. 즉, 현재 TAK가 대체 키를 식별하고, 대체 TAK가 현재 키를 선행 키로 식별해야 합니다.

이 검증이 처음 성공하면 신뢰 당사자는 30일 수용 타이머를 시작합니다. 그동안 현재 키로 운영 검증을 계속합니다. 이후의 성공적인 실행에서는 알림된 키와 인증서 URL이 변하지 않아야 합니다. 대체 키가 사라지거나 검증에 실패하면 타이머는 취소됩니다. 지정된 조건 하에서 타이머가 만료된 후에야 신뢰 당사자는 현재 트러스트 앵커 정보를 대체 키로 옮깁니다.

이 절차는 서로 다른 여러 사실을 만들어냅니다. 운영자가 대체 키를 공개했을 수 있습니다. 특정 신뢰 당사자가 그것을 검증했을 수 있습니다. 그 신뢰 당사자가 필요한 기간 동안 동일한 전환을 연속적으로 관찰했을 수 있습니다. 이후 전환했을 수도 있습니다. 그러나 이 어느 사실도 모든 검증기가 똑같이 했다는 것을 입증하지 않습니다.

이 구분이 중요한 이유는 TAK 지원이 정의상 보편적이지 않기 때문입니다. RFC 9691은 TAK 객체를 처리할 수 없는 신뢰 당사자는 TAL 또는 이에 준하는 수동 구성의 키를 계속 사용한다고 명시합니다. 따라서 운영자는 오래된 클라이언트를 보호할 수 있을 만큼 오랫동안 별도의 리포지토리 디렉터리를 둔 채 이전 키 쌍과 새 키 쌍을 함께 유지해야 할 수 있습니다. 낡은 TAL과 수용 타이머가 아직 진행 중인 TAK 인지 신뢰 당사자는 서로 다른 상태입니다.

RFC 6489는 CA 키에 대한 유사한 보수적 롤오버를 기술합니다. 새 CA 인스턴스를 준비하고, 인증서·CRL·매니페스트를 공개하고, 하위 산출물을 재발급한 뒤에야 이전 인스턴스를 은퇴시킵니다. RFC 6916은 알고리즘 마이그레이션 규모에서 같은 제도적 논점을 제시합니다. CA 준비, 산출물 재발급, 신뢰 당사자 준비, 트와일라잇(twilight)과 수명 종료는 각각 별개의 이정표입니다.

따라서 수용 장부(acceptance ledger)는 현재 키 지문, 대체 키 지문, 인증서 URL 집합, 현재 및 대체 TAK 해시, 최초 검증된 관찰, 타이머 시작, 연속성 관찰, 전환 시점, 검증기 식별자와 소프트웨어 버전을 묶어 기록해야 합니다. 또한 TAL 전용 또는 수동 구성 집단 중 어느 것이 계속 지원되는지, 그리고 그 지원을 종료할 결정이 무엇인지를 별도로 기록해야 합니다.

이것은 추가 프로토콜 요구사항이 아니라 편집적 거버넌스 추론입니다. RFC 객체는 암호학적 관계와 국소 검증 이벤트를 증명합니다. 수용 장부는 그러한 경계가 분명한 증명들을 결합하되, 표본을 전역적 주장으로 바꾸지는 않습니다.

출처