요약

  • RFC 9919는 경량 프로파일의 신규 클라이언트에 대해CertID내 발급자 이름 및 키 해시에 SHA-256을 사용하도록 요구하며, 기존 RFC 5019 클라이언트에는 실질적으로 가능해지는 시점에 SHA-1에서 전환하도록 요구합니다.
  • 응답기는 일시적으로 두 개의SingleResponse요소를 포함할 수 있습니다. 하나는 SHA-1CertID이고 다른 하나는 SHA-256입니다. 클라이언트 요청 알고리즘 로그는 구버전 사본을 제거할 시점을 판단하는 데 도움이 될 수 있습니다.
  • 그러나 그 로그는 측정 지점에 도달한 요청만 볼 수 있습니다. 클라이언트나 프록시 캐시 내 사용, 사전 생성된 응답, TLS 스테이플링, 대체 응답기, 프로토콜 외부 운영 배열 속에서 사용이 남아 있을 수 있습니다.
  • CertID알고리즘은 발급자 인증서의 해시 방식을 결정하며, OCSP 응답의 서명 알고리즘은 결정하지 않습니다.
  • 종료에는 관측 지점과 분모, 이중 응답 정책, 종료 기준, 의사결정자, canary 테스트, 롤백 경로, 예외 만료, 컷오버 이후 결과를 연결하는 근거 기록이 필요합니다.

‘0’은 실제로 무엇을 의미하는가?

그것은 특정 분류자가 특정 기간 동안 특정 수신 지점에서 SHA-1 요청을 발견하지 못했다는 의미일 뿐입니다. 모든 구형 클라이언트가 사라졌다고 말하려면, 모든 사용이 이 수신 지점을 통과할 수 있었고 모든 사용이 새 요청을 생성했다는 두 가지 가정이 필요합니다. 로그는 어느 쪽도 입증하지 못합니다.

고용량 OCSP 프로파일은 원본 접근을 최소화하도록 설계되었습니다. 응답은 요청 전에 생성될 수 있고, 클라이언트는 유효한 응답을 로컬에 저장하며, HTTP 중개자는 재사용하고, 서버가 캐시에서 제공할 수도 있습니다. stapling이나 piggybacking을 쓰면 응답이 다른 프로토콜 교환 안에 도달하므로, 클라이언트는 OCSP 응답기와 새 HTTP 세션을 열지 않습니다. 요청 수의 감소는 클라이언트 업데이트의 증거가 아니라 확장 설계의 성공일 수 있습니다.

또한 트래픽은 여러 지역, hostnames, 백업, 사설 네트워크로 분산될 수 있습니다. OCSP는 프로토콜 내에서 응답기의 능력을 광고하지 않으므로, 서비스 프로파일은 프로토콜 외부의 배열에 의존할 수 있습니다. 이러한 계약이나 장비 목록은 단일 수신 지점 그래프에는 나타나지 않습니다.

따라서 카운터 감소는 업그레이드, 더 긴 응답 유효기간, 더 나은 캐싱, 스테이플링 확대, 트래픽 리라우팅 때문일 수 있습니다. 감소가 종료의 증거가 되려면 대체 경로가 먼저 공개되어야 합니다.

SHA-1의 실제 위치

RFC 5019는issuerNameHash와issuerKeyHash에 SHA-1을 요구했습니다. RFC 9919는 그 프로파일을 폐기하고 새 프로파일에 맞는 클라이언트에게 SHA-256을 요구하며, 기존 호환 클라이언트에게는 가능한 한 빨리 전환하도록 요구합니다.

응답 측은 통제된 브리지를 허용했습니다. 기본은 단일SingleResponse이지만, 사전 생성, 캐싱 또는 호환성을 개선하기 위해 요소를 추가할 수 있습니다. RFC 9919는 SHA-1 요소와 SHA-256 요소의 명확한 예시를 제시합니다. SHA-1이 필요한 클라이언트가 남아 있지 않다면 응답기는 그 형식을 배포해서는 안 되며, 운영자는 판단을 돕기 위해 요청 알고리즘을 기록할 수 있습니다.

그러나 문서는 전 세계적인 침묵 일수나 허용 비율, 또는 OCSP 배포별 기준을 지정하지 않습니다. 측정은 결정에 대한 입력이지 자동 위임이 아닙니다.

RFC 6960은 기술적 혼란을 해소합니다.CertID.hashAlgorithm은 발급자의 고유 이름(DN)과 공개 키의 해시를 정의하고, 일련번호가 인증서를 완성합니다.BasicOCSPResponse.signatureAlgorithm은 별도의 필드입니다. RFC 9919의 8.7절은 이 계산에 SHA-1을 쓰는 것 자체는 암호학적 보안 문제가 아니라고 말합니다. 문제는 복잡성과 잠재적 공격 표면을 늘리는 소프트웨어 지원의 지속입니다.

따라서 서명 계층을 별도로 검사하지 않는 한 이 프로젝트를 “SHA-1 서명 종료”라고 부를 수 없습니다. 여기서 다루는 대상은 인증서 식별의 호환성 측면입니다.

비율보다 분모를 먼저

목록 작성은 응답기의 모든 사본, 이름, 지역, 경로에서 시작하고, 그다음 인증서 패밀리와 클라이언트 모집단으로 확장됩니다. 각 행에는 직접 요청, 캐시 재검증, 프록시 트래픽, 스테이플링, 오프라인 사용, 다른 서비스로의 폴백이 나타나는지를 기록합니다. “관측되지 않음”은 독립적 상태로 남아 있어야 합니다.

측정 창은 응답 유효기간과 갱신 주기를 포함해야 합니다. 유효한 응답을 보유한 구형 클라이언트는 만기 전까지 다시 요청하지 않습니다. 유지보수 창이 드문 기기나 폐쇄형 PKI는 독립적인 테스트가 필요합니다. canary는 가장 많이 보이는 인증서가 아니라 서로 다른 경로를 대표해야 합니다.

모집단을 측정할 수 없다면, 예외 소유자는 제외 사유와 재검토 시점을 기록합니다. 이렇게 해야 미지의 영역이 근거 없이 SHA-256으로 변하지 않습니다.

종료의 근거 기록

근거 기록은 결정의 범위와 소유자, 관측 지점과 분모, SHA-1 예외 목록, 단일/이중 응답 정책, 캐싱과 스테이플링 커버리지, 측정 기간과 종료 기준을 담습니다. 여기에 canary 모집단과 기간, 롤백 조건, 폴백 경로, 예외가 갱신되지 않을 경우의 만료일을 추가합니다.

컷오버 이후에는 재발한 SHA-1 요청, 응답기 오류, 검증 실패, 폴백 작동, 영향받은 인증서 패밀리, 서비스 영향이 추가됩니다. 승인 자체는 계획일 뿐이며, 결과가 이를 완전한 기록으로 만듭니다.

IETF는 상호운용 동작을 정의하지만 각 조직의 환경을 운영하지는 않습니다. 따라서 변경을 수행하는 운영자가 자신의 근거와 책임을 소유합니다. 호환성은 아무도 소유하지 않는다는 이유로 영원히 살아남아서도, 단 하나의 대시보드가 조용해졌다는 이유로 끝나서도 안 됩니다.

출처