다음을 통해 공유

프로그램 요구 사항 - Microsoft 신뢰할 수 있는 루트 프로그램

  • 아티클

1. 소개

Microsoft 루트 인증서 프로그램은 고객이 Windows 제품을 신뢰할 수 있도록 루트 인증서 배포를 지원합니다. 이 페이지에서는 프로그램의 일반적 요구 사항과 기술적 요구 사항을 설명합니다.

참고 항목

2. 지속적인 프로그램 요구 사항

감사 요구 사항

  1. 프로그램 참가자는 상업적 작업을 수행하기 전에 매년 각 루트, 제약이 없는 하위 CA 및 교차 서명된 인증서에 대한 적격 감사(참조 https://aka.ms/auditreqs)의 증거를 Microsoft에 제공해야 합니다.
  2. 프로그램 참가자는 제약이 없는 모든 하위 CA 및 교차 서명된 인증서가 프로그램 감사 요구 사항을 충족하는지 확인해야 합니다.
  3. CA는 제약이 없는 하위 CA에 대한 모든 감사 보고서를 공개적으로 공개해야 합니다.
  4. CA 공급자는 S/MIME 사용 루트 CA와 S/MIME 인증서를 발급할 수 있는 모든 하위 CA가 아래 조건 집합 중 하나 이상 최신 버전에 대해 계속 감사되었는지 확인해야 합니다. 이 감사는 적어도 일년에 한 번 발생해야 합니다. 초기 감사 기간은 늦어도 2023년 9월 1일까지 시작해야 합니다.
    • 인증 기관에 대한 WebTrust 원칙 및 조건 – S/MIME
    • ETSI EN 119 411-6 LCP, NCP 또는 NCP+

통신 및 공개 요구 사항

  1. 프로그램 참가자는 프로그램에 대한 대표자 역할을 하려면 Microsoft에 "신뢰할 수 있는 에이전트" 두 개 이상의 ID와 하나의 일반 전자 메일 별칭을 제공해야 합니다. 프로그램 참가자는 담당자를 신뢰할 수 있는 에이전트로 제거하거나 추가하는 경우 Microsoft에 알려야 합니다. 프로그램 참가자는 전자 메일로 알림을 받는 데 동의하며 공식 알림을 받으려면 Microsoft에 전자 메일 주소를 제공해야 합니다. 프로그램 참가자는 Microsoft에서 전자 메일 또는 공식 편지를 보낼 때 알림이 유효하다는 데 동의해야 합니다. 제공된 연락처 또는 별칭 중 하나 이상은 해지 요청 또는 기타 인시던트 관리 상황에 대해 24/7 모니터링되는 통신 채널이어야 합니다.

  2. 프로그램 참가자는 CCADB 내의 외부 제3자가 운영하는 CA에 발급된 인증서를 포함하여 전체 PKI 계층 구조(비상근 CA, 교차 서명되지 않은 루트 CA, 하위 CA, EKU, 인증서 제약 조건)를 Microsoft에 매년 공개해야 합니다. 프로그램 참가자는 변경이 발생할 경우 이 정보를 CCADB에 정확하게 유지해야 합니다. 하위 CA가 공개적으로 공개되거나 감사되지 않는 경우 도메인 제한이어야 합니다.

  3. 프로그램 참가자는 등록된 루트 또는 하위 CA의 소유권을 다른 엔터티 또는 사람에게 연결하기 전에 적어도 120일 전에 이메일을 통해 Microsoft에 알려야 합니다.

  4. 이유 코드는 중간 인증서의 해지에 포함되어야 합니다. CA는 30일 이내에 중간 인증서를 해지할 때 CCADB를 업데이트해야 합니다.

  5. 프로그램 참가자는 Microsoft가 임박한 프로그램에서의 루트 CA 제거로 인해 상당한 영향을 받을 수 있다고 생각하는 경우 고객에게 연락할 수 있다는 데 동의합니다.

기타 요구 사항

  1. 상업적 CA는 조직 내에서 주로 내부적으로 신뢰하도록 되어 있는 프로그램에 루트 CA를 등록하지 않을 수 있습니다(예: 엔터프라이즈 CA).

  2. CA가 하도급 업체를 사용하여 비즈니스의 모든 측면을 운영하는 경우 CA는 하청 업체의 비즈니스 운영에 대한 책임을 맡게 됩니다.

  3. Microsoft가 단독 재량에 따라 사용 또는 특성이 신뢰할 수 있는 루트 프로그램의 목적에 반하는 것으로 판단되는 인증서를 식별하는 경우 Microsoft는 책임 있는 CA에 알리고 인증서를 해지하도록 요청합니다. CA는 Microsoft의 알림을 받은 후 24시간 이내에 인증서를 해지하거나 Microsoft에서 예외를 요청해야 합니다. Microsoft는 제출된 자료를 검토하고 자신의 재량으로 예외를 인정하거나 거부하는 최종 결정을 CA에 알립니다. Microsoft에서 예외를 부여하지 않는 경우 CA는 예외가 거부된 후 24시간 이내에 인증서를 해지해야 합니다.

3. 프로그램 기술 요구 사항

프로그램의 모든 CA는 프로그램 기술 요구 사항을 준수해야 합니다. Microsoft에서 CA가 아래 요구 사항을 준수하지 않는 것으로 확인되면 Microsoft는 해당 CA를 프로그램에서 제외합니다.

A. 루트 요구 사항

  1. 루트 인증서는 x.509 v3 인증서여야 합니다.
    1. CN 특성은 게시자를 식별해야 하며 고유해야 합니다.
    2. CN 특성은 CA 시장의 일반적인 고객이 읽을 수 있는 해당 시장에 적합한 언어로 되어 있어야 합니다.
    3. 기본 제약 조건 확장: cA=true여야 합니다.
    4. 키 사용 확장이 있어야 하고 중요한 것으로 표시되어야 합니다. KeyCertSign 및 cRLSign의 비트 위치를 설정해야 합니다. 루트 CA 프라이빗 키가 OCSP 응답에 서명하는 데 사용되는 경우 digitalSignature 비트를 설정해야 합니다.
      • 루트 키 크기는 아래의 "서명 요구 사항"에 자세히 설명된 요구 사항을 충족해야 합니다.
  2. 신뢰할 수 있는 루트 저장소에 추가되는 인증서는 자체 서명된 루트 인증서여야 합니다.
  3. 새로 발행된 루트 CA는 제출 날짜로부터 최소 8년, 최대 25년 동안 유효해야 합니다.
  4. 참여 루트 CA는 이러한 요구 사항이 적용되는 루트에서 새 1024비트 RSA 인증서를 발급하지 않을 수 있습니다.
  5. 발급되는 모든 CA 인증서에는 유효한 CRL이 있는 CDP 확장 및/또는 OCSP 응답자에 대한 AIA 확장이 포함되어야 합니다. 최종 엔터티 인증서에는 유효한 OCSP URL이 있는 AIA 확장 및/또는 CRL을 포함하는 유효한 HTTP 엔드포인트를 가리키는 CDP 확장이 포함될 수 있습니다. 유효한 OCSP URL이 있는 AIA 확장이 포함되지 않은 경우 결과 CRL 파일은 10MB여야 <합니다.
  6. 프라이빗 키와 주체 이름은 루트 인증서마다 고유해야 합니다. 동일한 CA의 후속 루트 인증서에서 프라이빗 키 또는 주체 이름을 다시 사용하면 예기치 않은 인증서 체인 문제가 발생할 수 있습니다. CA는 Microsoft에서 배포하기 전에 새 루트 인증서를 생성할 때 새 키를 생성하고 새 주체 이름을 적용해야 합니다.
  7. 정부 CA는 서버 인증을 정부에서 발급한 최상위 도메인으로 제한해야 하며, 국가가 주권을 제어할 수 있는 ISO3166 국가 코드에만 다른 인증서를 발급할 수 있습니다("정부 CA"의 정의는 섹션 III 참조 https://aka.ms/auditreqs ). 이러한 정부 발급 TLD는 각 CA의 해당 계약에서 참조됩니다.
  8. 참여하는 루트 CA에 연결된 CA 인증서를 발급하려면 서버 인증, S/MIME, 코드 서명 및 타임스탬핑 사용을 구분해야 합니다. 즉, 단일 발급 CA는 서버 인증을 S/MIME, 코드 서명 또는 타임스탬핑 EKU와 결합해서는 안 됩니다. 사용 사례마다 별도의 중간 인증서를 사용해야 합니다.
  9. 최종 엔터티 인증서는 다음 위치에 있는 https://cabforum.org/baseline-requirements-documents/CAB 포럼 기준 요구 사항의 부록 A에 나열된 구독자 인증서의 알고리즘 유형 및 키 크기에 대한 요구 사항을 충족해야 합니다.
  10. CA는 인증서 정책 확장 최종 엔터티 인증서에서 다음 정책 OID 중 하나를 선언해야 합니다.
    1. DV 2.23.140.1.2.1.
    2. OV 2.23.140.1.2.2.
    3. EV 2.23.140.1.1.
    4. IV 2.23.140.1.2.3.
    5. 비 EV 코드 서명 2.23.140.1.4.1.
    6. S/MIME 사서함에서 레거시 2.23.140.1.5.1.1의 유효성을 검사했습니다.
    7. S/MIME 사서함 유효성이 검사된 다목적 2.23.140.1.5.1.2.
    8. S/MIME 사서함 유효성 검사 엄격한 2.23.140.1.5.1.3.
    9. S/MIME 조직에서 레거시 2.23.140.1.5.2.1의 유효성을 검사했습니다.
    10. S/MIME 조직에서 다목적 2.23.140.1.5.2.2의 유효성을 검사했습니다.
    11. S/MIME 조직에서 Strict 2.23.140.1.5.2.3의 유효성을 검사했습니다.
    12. S/MIME 스폰서가 레거시 2.23.140.1.5.3.1의 유효성을 검사했습니다.
    13. S/MIME 스폰서 유효성을 검사한 다목적 2.23.140.1.5.3.2.
    14. S/MIME 스폰서 유효성 검사 엄격한 2.23.140.1.5.3.3.
    15. S/MIME 개별 유효성 검사된 레거시 2.23.140.1.5.4.1.
    16. S/MIME 개별 유효성 검사 다목적 2.23.140.1.5.4.2.
    17. S/MIME 개별 유효성 검사 엄격한 2.23.140.1.5.4.3.
  11. 2024년 8월부터 신뢰할 수 있는 루트 프로그램과 해당 도구에서 관리하는 모든 사용자 지정 EV SSL OID가 제거되고 CA/B 포럼 규격 EV SSL OID(2.23.140.1.1)로 대체됩니다. Microsoft Edge 팀은 브라우저에서 EV SSL OID(2.23.140.1.1)에 대한 검사를 구현하므로 다른 EV SSL OID는 더 이상 Edge와 일치하고 비호환성을 방지하기 위해 허용되지 않습니다.
  12. CA는 루트 인증서에 2개 이상의 OID를 적용하지 않을 수 있습니다.
  13. IETF RFC 5280에 따라 기본 제약 조건 확장을 포함하는 최종 엔터티 인증서에는 cA 필드가 FALSE로 설정되어 있어야 하며 pathLenConstraint 필드는 없어야 합니다.
  14. CA는 OCSP 서명만 허용되도록 기술적으로 OCSP 응답자를 제한해야 합니다.
  15. CA는 Microsoft가 요청한 특정 날짜까지 인증서를 해지할 수 있어야 합니다.

B. 서명 요구 사항

알고리즘 코드 서명 및 타임스탬프를 제외한 모든 사용 코드 서명 및 타임스탬프 사용
다이제스트 알고리즘 SHA2(SHA256, SHA384, SHA512) SHA2(SHA256, SHA384, SHA512)
RSA 2048 4096(새 루트에만 해당)
ECC / ECDSA NIST P-256, P-384, P-521 지원되지 않음

참고:

  • ECDSA와 같은 ECC(타원형 곡선 암호화)를 사용하는 서명은 Windows 및 최신 Windows 보안 기능에서 지원되지 않습니다. 이러한 알고리즘 및 인증서를 활용하는 사용자는 다양한 오류와 잠재적인 보안 위험에 직면하게 됩니다. Microsoft 신뢰할 수 있는 루트 프로그램은 알려진 비호환성 및 위험으로 인해 ECC/ECDSA 인증서를 구독자에게 발급해서는 안 된다고 권장합니다.
  • 코드 서명은 ECC 또는 키 4096을 > 지원하지 않습니다.

C. 해지 요구 사항

  1. CA에는 문서화된 해지 정책이 있어야 하며 발급된 인증서를 해지할 수 있는 기능이 있어야 합니다.

  2. OCSP 응답자 요구 사항: a. 최소 유효 기간은 8시간입니다. 최대 유효 기간은 7일입니다. 및 b. 다음 업데이트는 현재 기간이 만료되기 최소 8시간 전에 사용할 수 있어야 합니다. 유효성이 16시간을 초과하는 경우 다음 업데이트는 유효 기간 1/2에서 사용할 수 있어야 합니다.

  3. OCSP가 없는 경우 CRL 권장 사항: a. Microsoft 관련 확장 1.3.6.1.4.1.311.21.4(다음 CRL 게시)를 포함해야 합니다. b. 새 CRL은 다음 CRL 게시 시간에 사용할 수 있어야 합니다. c. CRL 파일의 최대 크기(전체 CRL 또는 분할된 CRL)는 10M을 초과하지 않아야 합니다.

    참고 항목

    OCSP가 없을 때 섹션 3.C.3- CRL 권장 사항의 목표는 대량 해지 시 최종 사용자에게 적용 범위를 제공하는 것입니다.

  4. CA는 루트 인증서를 사용하여 최종 엔터티 인증서를 발급해서는 안 됩니다.

  5. CA가 코드 서명 인증서를 발급하는 경우 RFC 3161 " "Internet X.509 공개 키 인프라 TSP(타임스탬프 프로토콜)"를 준수하는 타임스탬프 기관을 사용해야 합니다.

D. 코드 서명 루트 인증서 요구 사항

  1. 코드 서명 사용을 지원하는 루트 인증서는 교체 롤오버 루트 인증서 배포 날짜로부터 10년 후 또는 CA에서 요청한 경우 더 빨리 프로그램별로 배포에서 제거될 수 있습니다.
  2. 알고리즘 보안 수명(예: RSA 1024 = 2014, RSA 2048 = 2030)을 넘겨 코드 서명 사용만 지원하도록 배포에 남아 있는 루트 인증서는 Windows 10 OS에서 '사용 안 함'으로 설정할 수 있습니다.
  3. 2024년 2월부터 Microsoft는 더 이상 EV 코드 서명 인증서를 수락하거나 인식하지 않으며 CCADB는 EV 코드 서명 감사 수락을 중단합니다. 2024년 8월부터 모든 EV 코드 서명 OID가 Microsoft 신뢰할 수 있는 루트 프로그램의 기존 루트에서 제거되고 모든 코드 서명 인증서가 동일하게 처리됩니다.

E. EKU 요구 사항

  1. CA는 루트 인증서에 할당된 모든 EKU에 대한 비즈니스 근거를 제공해야 합니다. 근거는 형식 또는 형식의 인증서를 발급하는 현재 비즈니스의 공개 증거 또는 단기간에 해당 인증서를 발급하려는 의도를 보여주는 비즈니스 계획(프로그램에 의한 루트 인증서 배포 후 1년 이내)의 형태일 수 있습니다.

  2. Microsoft는 다음 EKU만 사용하도록 설정합니다.

    1. 서버 인증 =1.3.6.1.5.5.7.3.1
    2. 클라이언트 인증 =1.3.6.1.5.5.7.3.2
    3. 보안 전자 메일 EKU=1.3.6.1.5.5.7.3.4
    4. 타임스탬프 EKU=1.3.6.1.5.5.7.3.8
    5. 문서 서명 EKU=1.3.6.1.4.1.311.10.3.12
    • 이 EKU는 Office 내에서 문서에 서명하는 데 사용됩니다. 다른 문서 서명 용도에는 필요하지 않습니다.

F. Windows 10 KMCS(커널 모드 코드 서명) 요구 사항

Windows 10은 커널 모드 드라이버의 유효성을 검사하기 위한 요구 사항을 강화했습니다. Microsoft와 프로그램 파트너가 확장 유효성 검사 요구 사항을 사용하여 드라이버에 서명해야 합니다. 커널 모드 드라이버를 Windows에 포함시키려는 모든 개발자는 Microsoft 하드웨어 개발 팀이 명시한 절차를 따라야 합니다. 자세한 내용은 Windows 하드웨어용 파트너 센터를 참조하세요.