요약

  • RFC 9908은 IETF Proposed Standard로, 2026년 1월에 발표되었으며 RFC 7030과 RFC 9148을 갱신합니다.
  • CSR Attributes에서 속성 OID와 속성 값의 인코딩을 명확히 하고, 특히 X.509 확장 값을 처리하며, CertificationRequestInfoTemplate 방식을 도입합니다.
  • 서버는 부분적으로 채워진 템플릿을 보낼 수 있습니다. 자신이 요구하는 값은 고정하고, 클라이언트가 결정해야 할 값은 빈 상태로 남깁니다. 이는 CSR 승인, 발급 또는 CA 정책을 나타내는 것이 아닙니다.

EST의 핵심 변화는 허용 가능한 속성을 더 많이 나열한 것이 아니라,/csrattrs가 이어지는 CSR의 형태를 기술하도록 만든 것입니다. 클라이언트는 OID와 대응 값을 읽은 뒤 “필드가 존재하지 않음”, “필드는 존재하지만 값이 비어 있음”, “서버가 이미 값을 제공함”을 구분해야 합니다. 이러한 ASN.1 구조적 차이를 구현이 임의로 하나의 불리언 요구로 축소해서는 안 됩니다.

CertificationRequestInfoTemplate에는 subject가 포함될 수 있습니다. subject는 선택 사항입니다. 서버에 RDN 요구가 있을 때만 나타납니다. 서버가 제공한 RDN 값은 클라이언트가 그대로 사용해야 하며, 어떤 RDN이 나타났는데 값이 없다면 클라이언트가 적절한 값을 제공합니다. 따라서 빈 값은 “제약 없음”의 동의어가 아니라, 클라이언트가 완성하도록 명시적으로 맡겨진 슬롯입니다. subjectPKInfo는 서버에 키 요구가 없으면 결여됩니다. 나타날 때 그 알고리즘이 의도된 키 쌍 유형을 식별합니다. subjectPublicKey도 보통 결여되지만, RSA 모듈러스 길이 요구를 표현해야 할 때는 자리표시자 값을 담을 수 있습니다. 이 자리표시자 값은 클라이언트가 최종 생성하는 공개 키가 아닙니다.

이 점은 ACP와 BRSKI의 입망(onboarding) 시나리오와 직접 대응합니다. 서버는/csrattrs를 통해 특정 subjectAltName을 전달해야 하며, 클라이언트에게 “어떤 확장을 담아도 된다”고만 말하는 것으로는 부족합니다. RFC 8994의 자율 제어 평면(autonomic control plane)과 RFC 8995의 부트스트랩 절차가 요구 배경을 이룹니다. RFC 9908의 목표는 기존 EST 의미를 명확히 하고 강화하는 것이며, 기존 사용 방식을 향한 호환 방향을 유지합니다. EST 신원 인증을 대체하지도, CA의 승인 및 인증서 정책을 대체하지도 않습니다.

**Theo March 분석:** 템플릿은 제약 표현이지 승인 신호가 아닙니다. 서버가 템플릿을 보낸다고 해서 CSR에 서명하거나 승인한다는 뜻이 아닙니다. 인증은 여전히 EST 절차에 따라 수행되어야 하며, CA는 자체 정책에 따라 요청을 거절할 수 있습니다. 디코딩 성공이 곧 요구가 CSR과 최종 인증서에 올바르게 반영되었다는 뜻도 아닙니다.

출처