요약

  • X.509 v3는 각 인증서 확장 안에 객체 식별자, critical 불린, 그리고 인코딩된 값을 담았고, 이 불린의 기본값은 false입니다.
  • 알 수 없거나 처리할 수 없는 critical 확장은 거부 대상이며, 알 수 없는 non-critical 확장은 무시할 수 있습니다. 다만 인식된 확장은 플래그가 false라고 해서 선택 사항이 되지 않습니다.
  • criticality는 변경 비용을 발급자와 의존 소프트웨어 사이에서 배분했습니다. 중요도를 매기거나 서명을 강화하거나 발급자의 주장이 참임을 증명하지 않았습니다.

구형 인증서는 말할 곳이 일곱 곳뿐이었다

1993년 Privacy-Enhanced Mail 아키텍처에서 인증서는 버전, 일련번호, 서명, 발급자, 유효 기간, 주체, 주체 공개 키라는 일곱 가지 주요 내용으로 묘사될 수 있었습니다.RFC 1422는 이후 인증서 버전을 예상했지만, 그 인터넷 환경은 여전히 1988년 X.509 형식을 반영하고 있었습니다. 인증서는 이름을 키에 묶고, 그 바인딩을 확인하는 데 필요한 날짜와 권한을 담을 수 있었습니다. 인터넷이 미래에 발명할 모든 제약을 담을 일반적이고 반복 가능한 자리는 없었습니다.

인증서에 대체 신원, 키 용도, 정책 정보, 인증 경로에 대한 제한을 담으라는 요구가 늘면서 이는 제약이 되었습니다. 대응은 예상되는 아이디어마다 새 고정 필드를 예약하는 것이 아니었습니다. X.509 v3는 확장 시퀀스를 추가했습니다. 1999년에 발표된 최초의 인터넷 PKI 프로파일인RFC 2459는 표준 확장을 기술하면서 조직과 커뮤니티가 더 정의할 여지를 남겼습니다.

확장 가능성은 '자리 부족'을 해결했습니다. 그러나 더 어려운 질문을 낳았습니다. 서명된 인증서에 그 소프트웨어가 작성된 이후에 발명된 규칙이 담겨 있으면 구형 소프트웨어는 무엇을 해야 하는가?

모든 것을 조용히 수용하면 새 제약은 장식이 됩니다. 익숙하지 않은 모든 추가 사항을 거부하면 안전한 진화는 불가능해집니다. X.509의 작은 criticality 필드는 이 두 결과 사이를 나누었습니다.

세 필드가 하나의 능력 계약을 이루었다

이 내구성 있는 구조는RFC 5280에 나타납니다. 각 확장은extnID객체 식별자, 기본값이FALSE인critical불린, 그리고 확장 고유 값의 DER 인코딩을 담는extnValue옥텟 문자열을 포함합니다.

이 필드들은 서로 다른 역할을 합니다. OID는 값을 해석해야 하는 언어를 식별합니다. 값은 이름, 용도, 정책, 제약 또는 다른 주장을 담습니다. critical 플래그는 능력이 없을 때의 결과를 선언합니다. 인증서를 사용하는 시스템이 critical 확장을 인식하지 못하거나, 인식하더라도 그 정보를 처리할 수 없다면 인증서를 거부해야 합니다. 인식되지 않은 non-critical 확장은 무시할 수 있습니다. 다만 non-critical 확장을 인식한 경우 RFC 5280은 처리해야 한다고 규정합니다.

플래그는 인증서의 서명된TBSCertificate데이터 안에 있습니다. 중간자는 TRUE를 FALSE로 무해하게 바꾸면서 값을 보존할 수 없습니다. 그러면 서명된 바이트가 바뀌기 때문입니다. 인증서는 또한 같은 확장을 두 번 포함할 수 없습니다. 검증기가 상충하는 두 복사본 중 하나를 고르거나 나중 복사본이 이전 복사본을 무효화하도록 만들어진 것이 아닙니다.

따라서 critical는 '먼저 읽으라', '고심각도', '인증된 진실'을 의미하지 않습니다. 암호학적 강도를 더하지도 않습니다. CA는 올바른 주장만큼 충실히 잘못된 주장에도 서명할 수 있습니다. 이 비트는 의존 구현체가 확장의 의미를 적용할 수 없다면 수용이 금지된다는 것만 말합니다.

무시되면 살아남지 못하는 의미들이 있었다

RFC 5280은 모든 발급자에게 즉흥적 판단을 맡기지 않고 구분을 구체화했습니다.

일반 subject 필드가 비어 있고 인증서의 유일한 신원이subjectAltName에 있다면 그 확장은 critical이어야 합니다. 그렇지 않으면 구형 검증기가 키가 누구를 대표하는지 말하는 유일한 자리를 무시하고 빈 subject로 계속 진행할 수 있습니다.

공개 키가 다른 인증서의 서명을 검증하는 CA 인증서의 경우,basicConstraints는 존재하고 critical이어야 합니다. 그cA불린과 선택적 경로 길이 제한은 이 키가 인증 기관으로 동작할 수 있는지, 그 권한이 얼마나 멀리까지 미치는지를 결정합니다. 이 확장을 무시하는 것은 장식을 빼는 것이 아니라 위임에 대한 경계를 지워버릴 수 있습니다.

nameConstraints는 경로의 이후 인증서에 사용 가능한 네임스페이스를 제한합니다. 적합한 CA는 이를 critical로 표시해야 합니다. 이 규칙은 '제한된 이름 집합만 인증할 수 있는 중간 CA'와 '어떤 이름이든 인증할 수 있는 것처럼 보이는 중간 CA'의 차이를 보호합니다. 정책 제약과inhibitAnyPolicy도 그 목적이 경로에서 살아남을 수 있는 인증 정책을 바꾸는 것이기 때문에 프로파일에서 마찬가지로 critical입니다.

다른 확장은 의도적으로 non-critical로 남습니다. subject key identifier는 키를 찾거나 비교하는 데 도움이 되지만, 구형 애플리케이션은 그 힌트를 이해하지 못한 채로도 경로를 검증할 수 있을 수 있습니다. 따라서 criticality는 '보안 관련' 필드처럼 들리는 정도의 보편적 척도가 아니라 의미론과 의존 대상 집합에 따라 선택됩니다.

한쪽 선택은 의미를 보호했고, 다른 쪽은 도달 범위를 보호했다

발급자는 새 확장을 도입할 때 실질적인 마이그레이션 결정에 직면합니다. non-critical로 표시하면 구형 소프트웨어가 모르는 OID를 넘어갈 수 있습니다. 도달 범위는 보존되지만, 발급자는 수용하는 모든 검증기가 새 규칙을 강제했다고 동시에 주장할 수 없습니다. critical로 표시하면 의무적 의미가 보존됩니다. 검증기는 규칙을 이해하거나 인증서를 거부하는 둘 중 하나입니다. 그 대가는 지원이 없는 검증기와의 즉각적인 비호환입니다.

인터넷 번호 인증서는 의무적인 쪽을 보여줍니다.RFC 3779는 IP 주소 블록과 자율 시스템 식별자에 대한 사용 권리를 묶는 확장을 정의했습니다. 이를 critical로 표시할 것을 권장했는데, 이런 인증서를 목적대로 사용하는 애플리케이션은 자원 의미를 이해해야 하기 때문입니다. 좋은 서명만 보고 어떤 주소 공간이나 AS 번호가 위임되었는지 무시하는 검증기는 인증서의 요점을 놓친 것입니다.

TLS Feature 확장은 다른 기본값을 선택했습니다.RFC 7633은 구형 구현체가 인증서를 거부하게 되므로 critical로 표시하지 말아야 한다고 말합니다. 그 중단이 실제로 원하는 경우가 아니라면 critical 표시는 권장되지 않습니다. 이 확장은 여전히 이를 인식하는 클라이언트를 통제할 수 있으며, 설계자는 지원 부족을 보편적인 인증서 실패로 만들지 않았습니다.

이들은 criticality에 대한 경쟁적 정의가 아닙니다. 같은 배분 질문에 대한 반대 답입니다. 새 의미가 이 인증서의 모든 유효한 사용에 불가결한가, 아니면 능력을 갖춘 애플리케이션이 사용하는 동안 구형은 없이 계속할 수 있는가?

거부를 전달한 것은 문서가 아니라 경로 검증기였다

RFC 3280은 인터넷 프로파일의 확장 규칙을 상세한 경로 검증 절차로 바꾸었습니다.RFC 5280은 본질적 결과를 유지했습니다. 각 인증서에 적용되는 critical 확장을 처리하고, 요구된 처리가 실패하면 검증을 종료합니다. 구현체는 코드를 서로 다르게 조직할 수 있지만 적합한 외부 결과는 일치해야 합니다.

이 분리가 중요합니다. 표준 문서는 OID를 정의할 수 있고 발급자는 서명된 인증서에 넣을 수 있습니다. 어느 쪽도 의존 시스템에 의미를 설치하지 않습니다. 운영상의 권위는 실행 중인 검증 코드가 식별자를 인식하고, 값을 파싱하고, 규칙을 적용하고, 만족할 수 없는 경로를 거부하는 곳에서만 도래합니다. 발행은 명세이고, 수용이나 거부는 실행 가능한 로컬 결정입니다.

이 계약은 기능 제거도 여전히 구속합니다. 2024년 X.509 정책 검증을 갱신한RFC 9618은 정책 검증이 필요 없는 애플리케이션이 이를 비활성화하는 것을 허용합니다. 그러나 이 경우 critical 정책 관련 확장은 인식되지 않은 것으로 처리되고 경로는 거부되어야 합니다. 기능을 끄는 것은 허용됩니다. 그 의무적 제약을 강제하는 척하는 것은 허용되지 않습니다.

성공한 경로조차 유한한 판정이었다

Critical 확장 처리는 좁은 질문에 답합니다. 이 검증기가 이 경로에 대해 프로파일이 의무로 만든 모든 서명된 확장 의미를 이해하고 만족시켰는가? 이는 주체가 정직하다는 것, CA가 올바르게 조사했다는 것, 개인 키가 침해되지 않았다는 것, 애플리케이션이 가능한 모든 작업을 승인해야 한다는 것을 증명하지 않습니다.

신뢰 앵커와 로컬 정책은 여전히 입력입니다. 애플리케이션은 기본 경로 검증 이후 추가 제한을 둘 수 있습니다. 같은 최종 인증서에 대한 서로 다른 경로는 서로 다른 중간 제약을 노출할 수 있습니다. 인식된 확장조차 값이 형식에 맞지 않거나 조건이 충족되지 않으면 실패할 수 있습니다. '알려진 OID'는 '수용된 규칙'과 같지 않습니다.

근거 경계도 똑같이 중요합니다. 인용된 RFC들은 문법, 역사적 프로파일, 요구되는 동작을 정의합니다. 이들은 현재 인증서 집단, 브라우저 시장 점유율, 구현체 적합성 또는 미지 확장 실패의 빈도를 측정하지 않습니다.RFC 1422,RFC 2459,RFC 3280,RFC 5280,RFC 3779,RFC 7633,RFC 9618은 이 메커니즘과 그 진화를 뒷받침하며, 배포된 제품의 인구 조사를 뒷받침하지 않습니다.

역사적 성취는 마법 같은 보안 비트가 아니었습니다. 확장 가능성을 무시할 권리와 혼동하지 않겠다는 훈련된 거부였습니다. X.509 v3는 인증서가 새 문장을 배우게 했고, criticality는 발급자가 그 문장 중 하나는 인증서가 효력을 발휘하기 전에 반드시 이해되어야 한다고 말할 수 있게 했습니다.