유출된 중간 CA의 개인 키 하나만 있으면 공격자가 어떤 웹사이트나 서비스든 사칭할 수 있다고 함. 이런 일을 몇 번이나 더 겪어야 Web PKI를 덜 비정상적인 체계로 교체할 건가?
도메인 소유권을 계층적으로 위임하고, 침해 범위를 해당 주체 아래의 하위 트리로 제한하는 체계는 이미 작동하고 있음. 이를 도메인 검증에 하루빨리 활용해야 함.
마치 교체가 쉽고 간단한데 우리가 그냥 하지 않기로 선택한 것처럼 얘기하는 것 아닌가?
DANE이 주류가 됐어야 함. NameConstraints도 좋겠지만, 누가 CA에 사용을 강제할 수 있을까? 클라이언트라도 최소한 가끔은 CRL을 확인해야 함.
이 서비스가 주로 어디에 쓰이는지 알아보는 중임. 간단히 검색해 보니 인도 정부 사이트나 세금 신고 같은 서비스와 관련 있어 보이는데, 피해도 이를 이용하는 인도 국민에게 집중될 것으로 예상하는 건가?
웹에서는 어떤 CA든 거의 모든 웹사이트의 TLS 인증서를 발급할 수 있음. 따라서 키를 가진 공격자는 이 CA가 인증서를 발급한 사이트뿐 아니라, 거의 모든 HTTPS 연결을 대상으로 중간자 공격을 할 수 있음.
인도 기업들이 사용하며 전자서명 서비스도 제공함. 널리 쓰이는 플랫폼임.
Web PKI는 근본적으로 잘못된 구조임. 인증서 하나를 폐기하려고 Go, Electron, webpki-roots 등의 새 버전을 배포해야 하는 이유가 뭔가? 그 배포조차 이미 침해된 TLS 연결을 거칠 수 있음. 왜 수많은 패키지가 신뢰의 출발점이 되는 민감한 인증 정보를 각각 배포하며, CA의 권한을 특정 국가 코드 최상위 도메인이나 일부 이름 영역으로 제한하지 않고 모든 도메인을 보증하게 두는 건가?
브라우저 업체들이 모든 제안에 거절만 하는 동안, 오히려 이메일 분야에서는 조용히 실질적인 혁신이 일어나고 있음. 신뢰를 브라우저 업체의 보안팀과 Let's Encrypt에 집중할 게 아니라 분산해야 함.
Web PKI가 모든 클라이언트에 자체 루트 인증서를 넣도록 강제하지는 않음. 나열한 클라이언트도 원한다면 중앙 관리형 신뢰 저장소를 사용하도록 설정할 수 있음. 기본값이 다른 것은 클라이언트가 의도적으로 선택한 절충이지, 표준의 잘못이 아님.
이메일 분야에서 일어나고 있다는 PKI 관련 혁신을 좀 더 구체적으로 설명해 줄 수 있을까?