HTTPS certificates in the age of quantum computing

양자 컴퓨팅 시대에 대비한 HTTPS 인증서 체계의 근본적 재설계가 IETF에서 논의되고 있음. 핵심은 포스트-양자 서명의 거대한 크기 문제를 머클 트리로 우회하는 접근법임.

문제: 포스트-양자 서명의 크기 폭발

• 현재 인증서 체인은 약 3.5KB로, LWN 프론트페이지 HTML(압축 후)의 약 1/3 수준임
• ML-DSA-44(포스트-양자 서명)는 Ed25519 대비 37배 더 큰 서명을 생성함
• 단순 전환 시 인증서가 웹사이트 콘텐츠보다 더 큰 대역폭을 차지하게 됨
• 다만 인증 키는 "지금 저장, 나중에 복호화" 공격에 취약하지 않아 키 교환보다 긴급도는 낮음

PLANTS 워킹그룹의 핵심 아이디어

• PLANTS(PKI, Logs, and Tree Signatures) 워킹그룹이 CA 서명과 투명성 로그의 관계를 역전시키는 방식을 제안함

graph TD
    subgraph "현재 방식"
        A1[CA가 인증서 생성] --> A2[투명성 로그에 기록]
        A2 --> A3[로그 서명을 인증서에 포함]
        A3 --> A4[클라이언트에 서명 체인 전송]
    end

    subgraph "PLANTS 제안"
        B1[CA가 append-only 발급 로그 유지] --> B2[제3자 옵저버가 로그 검증/서명]
        B2 --> B3{클라이언트 상태}
        B3 -->|첫 방문| B4["Full 인증서 ~133KB
CA + 옵저버 서명 포함"]
        B3 -->|체크포인트 보유| B5["Signatureless 인증서
머클 증명만 ~384B"]
    end

• CA가 자체 append-only 발급 로그를 유지하고, 기존 투명성 로그 운영 조직들이 이를 모니터링/미러링함
• 브라우저는 신뢰할 옵저버와 쿼럼 기준을 자체적으로 설정 가능함

두 가지 인증서 타입

• Full 인증서: CA와 옵저버 서명 + 머클 증명 포함, ML-DSA-44 기준 약 133KB
• Signatureless 인증서: 머클 증명만 포함, 브라우저가 이미 해당 CA의 체크포인트를 검증한 경우 사용 가능

머클 트리의 효율성

• 머클 트리 증명은 트리 크기에 대해 로그 스케일로 성장함
• 해시 기반이라 양자 공격에 취약하지 않아 포스트-양자 전환 시에도 크기가 변하지 않음
• Let's Encrypt 기준 하루 약 600만 건 인증서 발급 → 1분 간격 체크포인트 시 인증서당 해시 12개(SHA-256 기준 384바이트) 필요
• 이는 ML-DSA-44 서명 1개 크기의 **16%**에 불과함

폐기(Revocation) 처리

• 만료된 인증서는 리프 노드 삭제로 자연스럽게 정리됨 (append-only 속성과 모순되지 않음)
• 오발급 인증서는 별도 폐기 세트로 관리되며, 체크포인트 서명에 포함됨
• 브라우저가 full 인증서를 검증할 때마다 최신 폐기 목록도 함께 수신함

도입 타임라인

• Google이 Chrome에서 머클 트리 기반 인증서의 성능 영향을 평가할 계획임
• 2027년 말까지 PLANTS 초안 기반의 실험적 포스트-양자 CA 시스템 배포 목표
• 실제 CA/서버 운영자/사용자 업데이트는 2029~2030년 예상