Company-Certs 앵커 순환, 승인 권한은 증명되지 않는다

요약

한 개인 Internet-Draft가/.well-known/company-certs를 제안하여, HTTPS를 통해 애플리케이션 전용으로 한정된 사설 앵커를 시스템의 전역 신뢰 저장소에 넣지 않고 게시하는 방법을 다룹니다.
출처 인증, 체인 유효성, 최신 항목 선택은 그 교체를 유능한 당국이 승인했음을 증명하지 못합니다. 겹침 기간 동안 클라이언트의 선택이 바뀔 수 있는데도 이 접점은 계속 보이지 않습니다.
Daniel Kade는 앵커 변경 영수증을 제안합니다. 이전/이후 지문, 정확한 문서 시대, 범위, 겹침 창, 승인 권한, 로컬 정책, 교차 검증, 롤백입니다. 이는 편집상의 제안이며 IETF의 요구사항이 아닙니다.

가시적 위임 없는 성공

문제를 드러내기 위해 침해 사고를 상상할 필요가 없습니다. 한 기업이 정상적인 순환을 준비합니다. 애플리케이션이 중단 없이 전환할 수 있도록 며칠간 이전 체인과 새 체인을 함께 게시합니다. 날짜는 일관되고, 허용된 도메인은 접속 지점의 TLS 인증서와 일치하며, 새 체인은 가장 늦은valid_from을 갖습니다.

클라이언트의 관점에서는 모든 것이 깔끔합니다. 서버는 요청된 이름의 주인입니다. JSON은 읽을 수 있습니다. 인증서는 유효 기간 내에 있습니다. 선택 규칙은 결정론적인 결과를 만듭니다. 그러나 이러한 검증 중 어느 것도 새 앵커를 승인한 주체, 그것이 속한 변경 기록, 그리고 승인이 적용되는 정확한 애플리케이션을 식별하지 못합니다.

이 차이는 행정적인 것이 아닙니다. 신뢰 앵커는 검증 추론의 입력입니다. 애플리케이션이 그것을 수용하는 순간, 이전에 받아들여지지 않던 인증 경로가 의도된 맥락에서 유효해질 수 있습니다. 따라서 게시된 문서를 바꿀 수 있는 능력은 곧 소프트웨어가 인정하는 권한 범위를 바꿀 수 있는 능력입니다.

기술 제안, 그 이상을 바꾸지 않는 시선으로

draft-doehle-company-certs-discovery-00은 2026년 7월 22일자 개인 Internet-Draft입니다. Standards Track을 목표로 하지만 이 분석 시점에 유일한 개정판은-00입니다. RFC도, 배포 결과물도, IETF의 결정도 아닙니다.

이 메커니즘은/.well-known/company-certs아래에 버전 관리되는 JSON 객체를 둡니다. 이는 권한 정보와 특정usage_context에 연결된 앵커들을 기술합니다. 각 앵커는 유효 기간, 동일 오리진 HTTPS URL, PEM 형식의 X.509 체인, CRL 또는 OCSP 표시, SHA-256 지문을 갖는 여러 체인을 포함할 수 있습니다. 문서는 허용 도메인을 제한하고 격리 저장소를 요구할 수도 있습니다.

이 제안의 취지는 바로 전역 신뢰를 오염시키지 않는 것입니다. 애플리케이션은 특정 사설 교환에 필요한 것을 발견할 뿐, 그 권한을 운영체제의 보편적 루트로 만들지 않습니다. 이 프로젝트는 Web PKI를 대체하지 않고, 엔드엔드 인증서를 발급하지 않으며, 사설 CA의 일반적 품질을 인증하지 않습니다.

출처 제약은 엄중합니다. HTTPS는 검증되어야 합니다. 체인의 URL은 동일 오리진입니다. 허용 도메인은 엔드포인트 인증서의 DNS 식별자와 동일하거나 그 아래에 있어야 합니다. 이 규칙들은 한 도메인이 자신이 소유하지 않은 네임스페이스에 무제한 앵커를 게시하지 못하게 합니다.

그러나 이는 조직의 내부 구성을 설명하지 않습니다. 게시 능력의 보유자는 웹 배포 파이프라인, 플랫폼 팀, 콘텐츠 전달 업체 또는 서비스 계정일 수 있습니다. 순환을 승인할 권한 있는 당국은 다른 곳에 있을 수 있습니다.

출처와 조직은 같은 주제가 아니다

RFC 8615는 "well-known" URI 공간을 정리합니다. 그 보안 분석은 이런 자원에 대한 쓰기 권한이 전체 오리진에 대한 권력과 같을 수 있음을 강조합니다. 이 관찰은 공유 호스팅이나 여러 팀이 서로 다른 게시 경로를 가질 때 특히 중요합니다.

도메인 통제는 유용한 증거입니다. 진술의 위치를 잡고 네임스페이스를 한정합니다. 다른 것을 증명하라고 요구해서 이를 약화시켜서는 안 됩니다. 도메인 통제는 PKI 책임자가 체인을 검증했는지, 애플리케이션 소유자가 새 범위를 수용했는지, 이중 승인 절차가 요구되었는지, 긴급 예외가 이미 만료되었는지를 말하지 않습니다.

RFC 9525는 클라이언트가 TLS 신원이 의도한 참조 이름과 일치하는지 확인하도록 돕습니다. 이 검증 역시 이름과 제시된 서버 사이의 관계를 확립할 뿐, 변경 위원회의 의사록이 아닙니다. 엔드포인트는 완벽하게 인증될 수 있으면서도 내부 위임을 입증할 수 없는 수정을 제공할 수 있습니다.

합법적인 자동화조차 한정된 위임이 필요합니다. "파이프라인이 게시했다"는 실행을 설명합니다. 권한을 설명하려면 그 파이프라인이 어떤 용도를 바꿀 수 있는지, 어떤 지문을 대체할 수 있는지, 어떤 두 번째 증거를 기다려야 하는지, 겹침이 얼마나 지속될 수 있는지, 누가 이동을 중단할 수 있는지도 알아야 합니다.

`valid_from`은 정렬할 뿐 승인하지 않는다

여러 체인이 같은 용도에 맞을 때, 이 프로젝트는 유효 기간 밖의 체인을 무시하고 로컬 정책이 달리 정하지 않는 한 가장 최근valid_from을 가진 적용 가능한 체인을 선택하도록 규정합니다. 이 규칙은 임의적 선택을 피합니다. 그 동사는 "선택"이지 "허가"가 아닙니다.

RFC 3339는 상호운용 가능한 날짜 작성을 돕습니다. 날짜는 문서가 주장하는 순서를 증명할 수 있지만, 결정의 주체도, 겹침의 이유도, 두 팀의 합의도 증명하지 않습니다. 더 늦은 값은 합법적 게시에서 정확히 형식화되어 있을 수도 있고, 오류일 수도, 적대적일 수도 있습니다.

RFC 5280도 이 공백을 메우지 못합니다. 경로 검증은 로컬에서 제공된 앵커와 정책을 사용합니다. 새 경로가 그 입력들에 따라 수학적으로 그리고 의미적으로 수용 가능함을 확인할 수 있습니다. 그러나 앵커를 그 입력들에 넣은 과정을 인증하지는 않습니다.

따라서 최신 규칙이 약하다고 결론짓는 것은 틀립니다. 그것은 정확히 자기 일을 수행합니다. 오류는 대시보드가 "정책에 따라 선택된 체인"을 "조직이 승인한 순환"으로 바꾸는 순간 시작됩니다.

격리는 실행 의무이다

isolated_store_required필드는 게시자의 의도를 표현합니다. 이 프로젝트는 그것이 기술적 장벽이 아니라고 명시합니다. 앵커를 격리할 수 없는 클라이언트는 그것을 더 넓은 저장소에 몰래 넣는 대신 거부해야 합니다.

이 표현은 책임을 올바르게 분배합니다. 게시자는 범위를 요청하고, 클라이언트는 그것을 충족할 수 있는지 알아야 합니다. 통제는 불리언의 존재에서 멈출 수 없습니다. 앵커가 어느 저장소에 로드되었는지, 어떤 검증 호출이 그것을 볼 수 있는지, 공유 라이브러리가 그 적용 범위를 넓히는지 관찰해야 합니다.

permitted_domains도 실행 측면에서 같은 질문을 던집니다. JSON에 그 필드가 있다는 것이 파서가 필드를 무시하는 것, 캐시가 두 용도를 섞는 것, 리팩토링이 앵커를 공용 컬렉션으로 옮기는 것을 막지는 못합니다. 거버넌스 영수증은 선언된 제한을 클라이언트의 실제 동작과 연결해야 합니다.

격리는 이 장치의 가장 독창적인 보안 약속입니다. 그것이 사라지면, 한 애플리케이션에 한정된 편의가 훨씬 큰 신뢰 결정이 될 수 있습니다. 이 확장은 단순한 구현 세부사항이 아니라 권한 변경으로 감지되어야 합니다.

신선한 응답은 시효가 지난 권한을 실을 수 있다

RFC 9110과 RFC 9111은 HTTP 의미론, 캐시 신선도, 재검증을 분리합니다. 이 프로젝트는 신중한 캐싱, 주기적 재검증, 재생 저항을 권고하며, 클라이언트는 자체 최대 기간을 부과할 수 있습니다.

이 조치들은 오리진 표현이 충분히 최신인지 알려줍니다. 그러나 내부 결정을 자동으로 갱신하지는 않습니다. 긴급 승인은 캐시보다 먼저 만료될 수 있습니다. 보안 팀이 합의를 철회했는데도 배포 지점이 여전히 이전 시대를 제공할 수 있습니다. 반대로 새 객체는 신선하지만 애플리케이션 소유자의 승인을 한 번도 받지 못했을 수 있습니다.

첫 성공적 획득은 별개의 사건입니다. 그 전에는 이 채널의 어떤 앵커도 이용할 수 없습니다. 그 후에는 새 경로가 수용될 수 있습니다. 프로젝트 자신도 이 부트스트랩을 민감하다고 분류합니다. 따라서 운영은 초기 등록, 일상적 갱신, 겹침, 전환, 철회, 롤백을 구분해야 합니다.

요청 빈도에도 기밀성 비용이 있습니다. 조직이나 용도에 대한 관심을 드러낼 수 있습니다. 합리적인 캐시는 이 정보를 보호하지만, 그 수평선 자체가 신뢰 결정의 요소가 됩니다. 이는 전송 편의만이 아니라 허용 가능한 교정 지연에 맞춰 보정되어야 합니다.

인증서의 상태는 결정의 상태가 아니다

CRL 및 OCSP 포인터는 체인과 함께 제공될 수 있습니다. RFC 6960은 인증서 상태를 조회할 수 있게 합니다. 많은 수명 주기에서 필수적이지만 앵커 순환의 질문에는 답하지 않습니다.

새로 게시된 CA는 신뢰 등록이 정당하게 승인되지 않은 상태에서 해지되지 않은 인증서를 발급할 수 있습니다. 조직이 철회하려 했던 오래된 앵커는 여전히 유효할 수 있습니다. 하위 인증서의 상태는 결정도, 범위도, 두 신뢰 기반이 공존한 기간도 재구성하지 못합니다.

서버에서 항목을 삭제한다고 즉시 모든 클라이언트가 고쳐지지 않습니다. 어떤 클라이언트는 캐시가 있고, 어떤 클라이언트는 오프라인이며, 어떤 클라이언트는 세션을 유지하고, 또 어떤 클라이언트는 앵커를 다른 곳에 복사했습니다. 교정은 대상 집단, 전파 기한, 그리고 앵커가 격리 저장소를 벗어나지 않았다는 증거를 식별해야 합니다.

앵커 변경 영수증

저는신뢰 앵커 변경 영수증을 제안합니다. 이 영수증은 공개 JSON에 강제되는 필드도, IETF의 처방도 아닙니다. 인증된 게시와 완전한 위임을 혼동하지 않게 하는 운영 접점입니다.

먼저 시대를 고정합니다. 문서 지문, 오리진, 검증된 참조 신원, 획득 시각, 캐시 상태입니다. 그리고 사용 맥락, 허용 도메인, 격리 요구를 추가합니다. 이렇게 하면 특정 다이제스트에 부여된 승인이 엔드포인트가 나중에 게시할 내용까지 확장될 수 없습니다.

다음으로 이동을 명명합니다. 이전/새 앵커의 지문, 체인 식별자,valid_from,valid_until, 겹침 창, 예정된 전환 상태입니다. 추가, 교체, 철회, 긴급 롤백은 각각 문법적으로 유효한 JSON을 만들어도 서로 다른 행위입니다.

"권한" 부분은 행위를 승인한 역할, 정책 또는 한정된 자동화, 그리고 해당 기록에 대한 보호된 참조를 나타냅니다. 개인 이름이나 내부 논의를 게시할 필요는 없습니다. 대신 게시를 실행한 채널과 독립된 채널에서 위임을 검증할 수 있어야 합니다.

로컬 부분은 클라이언트의 결정을 기록합니다. 최신 규칙 또는 예외, 요구된 교차 검증, 격리 능력, 재검증 기한, 무가용 시 행동입니다. 마지막으로 영수증은 교정 경로, 영향받는 클라이언트 등급, 최대 철회 지연, 자체 만료를 포함합니다.

비례하는 두 번째 증거

모든 애플리케이션이 엄중한 이중 승인을 요구하는 것은 아닙니다. 권한이 제한된 테스트 도구는 오리진에 연결된 게시 승인으로 충분할 수 있습니다. 서명, 결제 또는 인프라 제어 서비스는 별도의 승인 키나 보호된 변경 레지스터를 요구할 수 있습니다.

독립성은 두 메시지로 요약되지 않습니다. 같은 체인이 제공하는 두 번째 URL이나 같은 계정이 보낸 알림은 거의 분리를 추가하지 못합니다. 교차 검증은 PKI 시스템, 서명된 매니페스트, 보호된 로그, 하드웨어 키 또는 다른 행정 도메인에서 올 수 있습니다.

RFC 5011은 신중한 비교만을 제공합니다. DNSSEC 신뢰 앵커 자동 갱신 맥락에서 추가, 대기, 철회 상태를 구분합니다. Company-Certs를 규율하지는 않습니다. 그러나 자신의 신뢰 기반을 바꿀 권한이 있는 소프트웨어에는 "현재" 값만이 아니라 지속적인 전환 상태가 필요함을 보여줍니다.

동사를 지키는 일

이 사양 초안은 유용한 경계를 그립니다. 도메인과 애플리케이션으로 한정된 HTTPS 배포를 공식화하며, 이는 맥락 없이 전달되는 CA 파일이나 전역 저장소로의 조용한 설치보다 낫습니다. 여기에 기업 거버넌스 전체를 재현하라고 요구해서는 안 됩니다.

바람직한 다음 층위는 동사를 분리된 채로 유지하는 것입니다. HTTPS는 획득을 인증합니다. JSON은 상태를 표현합니다. X.509 검증은 로컬 입력으로 경로를 검사합니다. 클라이언트 정책은 체인을 선택합니다. 조직은 변경을 승인합니다. 영수증은 이 사실들을 결합하되, 첫 번째가 나머지 전부를 대변하지 않도록 합니다.

출처는 배포, 사고 또는 지명된 악용을 보여주지 않습니다. 서두의 시나리오는 프로젝트의 공존 규칙에 기반한 설계 검증입니다. 교훈은 더 담담하고 더 엄격합니다. 접속 지점은 새로운 신뢰를 게시할 수 있지만, 그것에게 애플리케이션이 믿는 것을 바꿀 권리를 준 주체가 누구인지는 오직 별도의 증거만이 말할 수 있습니다.

Company-Certs 엔드포인트는 앵커 순환을 승인한 주체를 증명하지 못한다

왜 중요한가

요약

가시적 위임 없는 성공

기술 제안, 그 이상을 바꾸지 않는 시선으로

출처와 조직은 같은 주제가 아니다

`valid_from`은 정렬할 뿐 승인하지 않는다

격리는 실행 의무이다

신선한 응답은 시효가 지난 권한을 실을 수 있다

인증서의 상태는 결정의 상태가 아니다

앵커 변경 영수증

비례하는 두 번째 증거

동사를 지키는 일

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

Strategic Circle 브리핑

Leadership Alliance 브리핑

요약

가시적 위임 없는 성공

기술 제안, 그 이상을 바꾸지 않는 시선으로

출처와 조직은 같은 주제가 아니다

valid_from은 정렬할 뿐 승인하지 않는다

격리는 실행 의무이다

신선한 응답은 시효가 지난 권한을 실을 수 있다

인증서의 상태는 결정의 상태가 아니다

앵커 변경 영수증

비례하는 두 번째 증거

동사를 지키는 일

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

추천 읽을거리

`valid_from`은 정렬할 뿐 승인하지 않는다