요약

  • 투표 SC-104가 지정한 Baseline Requirements 커밋 기준으로, TLS Subscriber Certificate는 비(非)크리티컬 Authority Information Access 확장을 반드시(MUST) 포함해야 한다. 그러나 확장 내부에서id-ad-caIssuers항목은SHOULD,id-ad-ocsp항목은MAY이다.
  • SC-104는 두 가지 문구 수정을 제안한다. 확장의 존재 요건을MUST에서SHOULD로 바꾸고, 하나 이상의AccessDescription요건을 확장이 존재하는 경우에 한해 적용하도록 조건화한다. 방식(method) 수준의 두 규칙은 바뀌지 않는다.
  • 투표 공고는 2026년 8월 27일부터 UTC 기준 9월 3일 00:00까지 투표 기간으로 명시했다. 본 기사의 조사 기준일인 9월 2일 시점에서 이 제안에는 귀속 가능한 최종 투표, 완료된 IPR 검토 또는 공개된 가이드라인 지위가 없었다.
  • caIssuers는 경로 구성을 위한 발급자 인증서 탐색을 지원하고,OCSP는 온라인 상태 확인 서비스를 가리킨다. 두 항목은 하나의 ASN.1 컨테이너에 담기지만 서로 다른 역할을 한다. 클라이언트는 AIA 가져오기 대신 서버, 캐시 또는 사전 로딩(preload)을 통해 중간 인증서를 얻을 수도 있다.
  • 따라서 신뢰할 수 있는 결과에는 절차 상태, 프로필 규칙, 방식 규칙, 발급된 인증서 바이트, 신뢰 당사자(relying party) 관찰이라는 다섯 개의 결합되었지만 서로 분리된 기록이 필요하다. 하나의 “AIA 준수” 플래그만으로 다섯 가지 모두를 증명할 수 없다.

강제 서비스가 없는 의무 박스

현재 요건은 중첩 퍼즐의 형태를 하고 있다. SC-104가 명시한 기준 커밋에서 Subscriber Certificate Extensions 표에 따르면authorityInformationAccess는MUST다. 이어지는 7.1.2.7.7절은 그AuthorityInfoAccessSyntax가 하나 이상의AccessDescription값을 포함해야 한다고 규정한다. 그러나 허용된 접근 방식이 모두 의무적인 것은 아니다.id-ad-caIssuers는SHOULD이고,id-ad-ocsp는MAY이며, 그 외의 방식은 금지된다.

이 구성은 내부적으로 비어 있지 않다. 존재하는 확장이 텅 빈 껍데기일 수는 없다. 위치 인코딩, 고유성, 순서 규칙은 여전히 적용되며,SHOULD는 실질적인 규범적 무게를 지닌다. 그럼에도 이 프로필은 모든 신뢰 당사자에게 특정 방식을 약속하지 않는다. 바깥 박스는 의무이지만, 그 안에 명명된 각 서비스는 더 약하고 서로 다른 존재 수준을 가진다.

SC-104는 이 불일치를 좁게 다룬다. 불변(immutable) 비교는 Subscriber Certificate Extensions 표의MUST를SHOULD로 바꾸고, 하나 이상의 접근 기술(description)을 요구하는 문장에 “If present(존재하는 경우)”를 추가한다. 방식 표는 바꾸지 않는다. caIssuers를MAY로 낮추거나, OCSP를SHOULD로 올리거나, 새 방식을 추가하거나, 허용되는 URI 유형을 바꾸거나, CA 인증서와 OCSP 응답자 인증서 규칙을 다시 쓰는 일은 하지 않는다.

두 줄만으로 감사(audit) 답변은 달라질 수 있다. 그러나 두 줄만으로 운영 결과를 예측할 수는 없다.

SHOULD는 규칙이지 빈칸이 아니다

일상 언어의 유혹은SHOULD를 선택 사양으로 읽는 것이다. 그러나 RFC 2119는 더 엄격하다.SHOULD는 권고에서 벗어날 정당한 이유를 허용하되, 그 영향이 이해되고 신중히 검토된 경우에만 허용한다. RFC 8174는 이렇게 대문자로 쓰인 단어들이 언제 표준적 의미를 지니는지 명확히 한다.

SC-104가 이후 발효된다면, AIA가 없는 Subscriber Certificate는 더 이상MUST존재 행을 위반하지 않게 된다. 그렇다고 생략이 규범적으로 보이지 않게 되는 것은 아니다. 발급자는 여전히SHOULD에서 벗어나고 있는 것이다. 유용한 준수 기록은 예외 이유, 그 예외를 승인한 발급 프로필, 영향을 받는 인증서의 범위를 함께 보존해야 한다. 기본적으로 존재함, 이유 있는 예외로 부재함, 무심코 생략함이라는 세 상태를 단순한 불리언 “허용됨”으로 줄이는 것은SHOULD와MAY를 구분하는 바로 그 규율을 버리는 일이다.

확장 내부에서도 같은 정밀함이 필요하다. 발급자는 제안된 바깥 권고를 충족하면서도 방식에 대해서는 서로 다른 선택을 할 수 있다. 변경되지 않은 표에 따라 caIssuers, OCSP 또는 둘 다 포함할 수 있다. 따라서 “AIA가 존재한다”는 말은 어떤 접근 경로가 존재하는지 말해주지 않는다. “AIA는 선택 사양이다”라는 말은 더 적은 정보를 준다.

바로 이 지점에서 Lu Heng(루헝)의 최소 규칙 규율이, 그것이 한 번도 논하지 않은 인증서 투표를 보증하도록 만들지 않고도 유용해진다. 공통 규칙은 그 상태가 결정론적이고 국소적으로 검증 가능할 때 가장 잘 작동한다. 도입과 배포는 공개와 분리되어야 한다. 이를 적용하면, 발급자가 무엇을 했는지 주장하기 전에 정확한 가이드라인 버전과 인증서 바이트를 기록하고, 생태계가 무엇을 경험했는지 주장하기 전에 클라이언트 행동을 별도로 기록한다는 뜻이다.

하나의 컨테이너, 두 가지 역할

RFC 5280은 Authority Information Access를 인증서 발급자에 관한 정보와 서비스를 식별하는 장소로 기술한다. 그 ASN.1 값은 접근 기술들의 시퀀스다. 익숙한 두 개체 식별자(주체 identifier)는 이후 서로 다른 방향으로 이어진다.

id-ad-caIssuers는 발급자 인증서를 획득할 수 있는 위치를 식별한다. 이것은 신뢰 당사자가 인증 경로를 선택하거나 구성하는 데 도움이 될 수 있다.id-ad-ocsp는 온라인 인증서 상태 프로토콜 서비스를 식별한다. 하나는 발급자 자료를 찾는 문제이고, 다른 하나는 상태 정보를 얻는 문제다. 확장을 공유한다고 해서 두 항목이 서로 대체재가 되는 것은 아니다.

Baseline Requirements 자체도 그 차이를 유지한다. 현재 Subscriber Certificate 표는 caIssuers에SHOULD, OCSP에MAY를 부여한다. 다른 곳에서는 CRL 시점과 CRL Distribution Point 규칙이 Subscriber Certificate가 AIA OCSP 포인터를 포함하는지에 따라 달라질 수 있다. 따라서 바깥 확장을 제거하는 것은 caIssuers URL을 제거하는 것과 의미상 동일하지 않고, caIssuers URL을 제거하는 것은 OCSP URL을 제거하는 것과 동일하지 않다. 관찰은 방식을 명명해야 한다.

이 구분은 흔한 서사 도약도 막는다. caIssuers가 없는 인증서가 그 사실만으로 클라이언트가 체인을 구성할 수 없음을 증명하지는 않는다. TLS 서버는 중간 인증서를 제공할 수 있다. 클라이언트는 로컬 스토어나 캐시에 이미 중간 인증서를 갖고 있을 수 있다. 공급업체가 다른 메커니즘으로 중간 인증서를 배포할 수도 있다. 반대로 URL의 존재만으로 클라이언트가 그것을 가져오겠지, 가져오기가 활성화되어 있겠지, 자원에 접근 가능하겠지, 반환된 자료가 유효한 경로로 이어지겠지라고 증명되지는 않는다.

인증서는 인코딩된 포인터에 대한 증거다. 검증 실행의 대본이 아니다.

두 가지 구현 사례, 그 어느 쪽도 보편 클라이언트가 아니다

마이크로소프트는 Windows에서 AIA 가져오기를 누락된 발급자 인증서를 가져올 수 있는 메커니즘으로 문서화하고, 관리 제어로 그 가져오기를 비활성화할 수 있음도 문서화한다. 이 단일 사례만으로 이미 여러 상태가 만들어진다: 제품과 버전, 정책 구성, 로컬 캐시, URL 가용성, 네트워크 접근, 경로 결과. “Windows는 AIA를 지원한다”는 관찰로는 충분하지 않다.

모질라는 2020년에 다른 접근을 기술했다. Remote Settings를 통해 공개된 중간 CA 인증서를 Firefox에 사전 로딩하는 것이다. 명시된 목표에는 사이트가 올바른 중간 체인을 보내지 못할 때 발생하는 알 수 없는 발급자(unknown-issuer) 오류를 줄이는 것이 포함되었다. 사전 로딩은 일부 경우에 라이브 caIssuers 가져오기에 대한 의존을 줄일 수 있지만, 모든 관련 중간 인증서가 항상 존재한다거나, 모든 Firefox 버전이 동일하게 동작한다거나, 서버 체인 구성이 더 이상 중요하지 않다는 증거는 아니다.

이 출처들은 가상의 단일 클라이언트 모델을 깨뜨린다는 점에서 가치 있다. 그러나 현재 시장 점유율, 보편적 동작, SC-104가 가져올 효과를 확립하지는 못한다. 가져오기가 비활성화된 기업용 Windows 배포, 중간 인증서 캐시가 채워진 Firefox 설치, 네트워크 가져오기가 없는 임베디드 TLS 스택, 새로 설치된 애플리케이션은 같은 인증서를 서로 다른 조건에서 만날 수 있다. 투표 문안이 그 조건들을 하나의 예측으로 압축할 수는 없다.

또한 서버 책임이 클라이언트 논의 속으로 사라져서도 안 된다. 잘 구성된 TLS 서비스는 적절한 체인을 제공한다. 클라이언트가 누락된 중간 인증서를 복구할 수 있는 것은 회복 경로(resilience path)이지, 불완전한 체인을 발송하는 일반 허가가 아니다. SC-104는 인증서 프로필 권고를 변경하는 것이지, TLS 핸드셰이크를 다시 쓰거나 서버 운영자가 체인 전달을 클라이언트 측 가져오기로 넘길 수 있음을 증명하지 않는다.

투표는 결과를 갖기 전에 수명 주기를 갖는다

공개된 SC-104 공고는 Google Trust Services의 Ethan Davis를 발안자로, SwissSign의 Roman Fischer와 DigiCert의 Stephen Davidson을 지지자(endorsers)로 명시한다. Baseline Requirements 버전 2.2.9를 명시하고 기준 커밋과 제안 커밋 사이의 불변 비교를 링크한다. 명시된 논의 기간은 UTC 기준 2026년 8월 20일부터 27일까지였고, 투표는 8월 27일부터 00:00 UTC 기준 9월 3일까지 진행되었다.

이 날짜들이 중요한 이유는 제안이 권한이 아직 확정되지 않은 채로 기술적으로는 판독 가능할 수 있기 때문이다. 9월 2일 기준일의 안전한 진술은 투표가 진행 중이었다는 것이다. 저장소 풀 리퀘스트, 투표 공고, 그 이후의 성공적 투표는 서로 다른 상태다. CA/Browser Forum 절차에 따라 성공한 투표는 최종 유지 관리 가이드라인(Final Maintenance Guideline)이 공개되기 전에 해당되는 지식재산권(IPR) 검토도 통과해야 한다. 이후 발효 버전과 효력 발생 일자에 대한 별도의 기록이 필요하다.

따라서 본 기사는 결과를 조기 보고하지 않는다. 투표가 이후 통과되더라도, 그것은 9월 2일의 문안을 소급하여 발효시키지 않는다. 투표가 부결되거나 변경되더라도, 불변 리드라인(redline)은 회원들이 검토한 내용의 증거이지, 인증서가 무엇을 포함하도록 요구받았는지에 대한 증거가 아니다.

절차적 접수증에는 투표 식별자, 발안자와 지지자, 명시된 기준, 제안 커밋, 논의 기간, 투표 기간, 자격 투표자 분모, 투표 수, 결과, IPR 상태, 제외 통지, 최종 가이드라인 버전과 효력 발생 일자가 담겨야 한다. 이후 각 사건은 상태를 추가할 뿐, 이전 상태를 조용히 덮어쓰지 않는다.

추론이 아니라 증거로 연결되는 다섯 상태

가장 작은 유용한 AIA 기록은 다섯 층으로 이루어진다.

1. 절차.투표 상태는 무엇인가? SC-104, 불변 기준과 제안, 투표 접수증, IPR 검토, 그리고 해당 사건들이 존재할 때 공개된 유지 관리 가이드라인을 기록한다. 이는 권한을 확립하는 것이지, 구현을 확립하는 것이 아니다.

2. 프로필.인증서 유형과 가이드라인 버전에 대해 바깥 확장의 존재 수준은 무엇인가?MUST,SHOULD,MAY,MUST NOT또는 다른 정확한 용어, 확장이 크리티컬인지 여부, 효력 발생 일자를 기록한다. 이는 정의된 프로필에 적용되는 규칙을 확립한다.

3. 방식.허용된 모든accessMethod에 대해 OID, 기능, 요구 수준, 위치 문법, 최대 개수, 순서 규칙을 기록한다. 이 Subscriber Certificate 프로필에서 caIssuers와 OCSP는 서로 다른 행으로 남아 있어야 한다. 이는 확장이 무엇을 포함할 수 있고 포함해야 하는지 확립한다.

4. 발급.발급 CA, 발급 프로필, 구성 버전을 식별한 뒤 특정 인증서를 지문(fingerprint)으로 검사한다. AIA가 인코딩되었는지, 실제로 존재하는 각 방식과 위치, 관찰 시각을 기록한다. 이는 클라이언트 행동이 아니라 바이트를 확립한다.

5. 신뢰.신뢰 당사자, 제품 버전, 플랫폼, 정책 설정, 로컬 스토어, 캐시 또는 사전 로딩 상태, 서버 제공 체인, 네트워크 조건을 식별한다. 가져오기가 시도되었는지, 어느 원천이 중간 인증서를 제공했는지, 어떤 상태 메커니즘이 작동했는지, 검증 결과가 무엇이었는지 기록한다. 이는 하나의 재현 가능한 관찰을 확립하는 것이지, 생태계의 진실이 아니다.

연결이 중요하다. 인증서 지문은 발급을 신뢰와 연결한다. 프로필 버전은 발급을 적용 규칙과 연결한다. 가이드라인 접수증은 그 프로필을 승인된 문안과 연결한다. 그러나 상태들은 병합되어서는 안 된다.SHOULD예외 하의 유효한 인증서는 특정 클라이언트 구성에서 여전히 실패할 수 있다. 두 방식을 모두 지닌 인증서도 접근 불가능한 서비스를 만날 수 있다. 클라이언트는 AIA 가져오기 없이 체인을 검증할 수 있다. 그 어떤 결과도 투표를 다시 쓰지 않는다.

증거가 확정할 수 없는 것

검토된 기록에는 현재 Subscriber Certificate 중 몇 개가 AIA, caIssuers, OCSP 또는 둘 다를 지니는지에 대한 측정이 없다. SC-104가 발효된다면 몇 개의 CA가 템플릿을 바꿀지도 보여주지 않는다. 인증서 크기 절감, 프라이버시 효과, 네트워크 트래픽, 경로 구성 성공, 상태 확인 동작, 장애를 정량화하지 않는다. 이 변경을 요청한 신뢰 당사자도 식별하지 않는다.

제안의 근거는 그 자체의 논리 안에서 여전히 일관성 있다: 방식 규칙이SHOULD와MAY인 상태에서 의무 컨테이너는 특정 방식 중 어느 하나도 보장하지 않는다. 그러나 일관성은 입증된 효익과 같지 않다. 구현자들이 별도로 어떤 집단이 기존 기본값에 의존하는지 측정하는 동안, 투표는 요구 수준을 합리적으로 정렬할 수 있다.

이 경계는 양쪽을 모두 가른다. 반대자들은 AIA 생략이 모든 클라이언트를 망가뜨릴 것이라고 추론할 수 없다. 찬성자들도 일부 클라이언트가 중간 인증서를 사전 로딩한다는 이유로 생략이 무해하다고 추론할 수 없다. 적절한 증거는 어느 한쪽 가장자리에서 골라낸 일화가 아니라 분절된 테스트 매트릭스다.

작은 변경을 판독 가능하게 만들기

SC-104는 Web PKI의 재설계가 아니다. 그렇기에 유용한 거버넌스 사례다. 작은 규범적 변경은 쉽게 체인지로그 한 문장으로 평면화되고, 그 평면화는 권한이 끝나는 지점과 운영 증거가 시작되는 지점을 가린다.

이 투표는 바깥 AIA 존재 규칙을MUST에서SHOULD로 옮기되, 허용된 두 방식은SHOULD와MAY에 그대로 두어야 하는지를 묻는다. 회원들은 확립된 절차를 통해 그 질문에 답할 수 있다. 발급자는 이후 발효 규칙을 어떻게 구현할지 결정할 수 있다. 신뢰 당사자들은 계속해서 제품별 체인 구성과 상태 선택을 할 수 있다. 서버 운영자는 자신의 체인 전달에 대한 책임을 유지한다. 이들은 서로 연관된 결정이지 하나의 결정이 아니다.

다섯 상태 접수증은 투표를 무겁게 만들지 않는다. 이후의 주장을 더 작게 만든다. “AIA가 선택 사양이 되었다” 또는 “클라이언트는 더 이상 필요 없다”라고 말하는 대신, 관찰자는 어떤 문안이 승인되었고, 어떤 인증서가 어떤 포인터를 담았고, 어떤 클라이언트가 어떤 조건에서 무엇을 했는지 정확히 말할 수 있다.

두 줄짜리 변경에 맞는 올바른 증거의 규모는 그것이다.

출처

  1. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  2. CA/Browser Forum servercert 풀 리퀘스트 665, SC-104
  3. 불변 SC-104 비교
  4. CA/Browser Forum servercert 이슈 673
  5. SC-104 투표 공고의 공개 아카이브
  6. 투표 기준 커밋 시점의 TLS Baseline Requirements
  7. CA/Browser Forum 정관
  8. RFC 5280, 4.2.2.1절
  9. RFC 2119
  10. RFC 8174
  11. 마이크로소프트, Authority Information Access retrieval
  12. Mozilla Security Blog, Firefox에 중간 CA 인증서 사전 로딩