X.509

X.509
X.509
정보기술 - 오픈시스템 상호접속 - 디렉토리: 공개키 및 속성 증명서 프레임워크
상황유효(권장)
초판1.0(88년 11월 25일), 33년 전(1988년 11월 25일)
최신 버전9.1
2021년 10월 14일, 9개월 전(2021-10-14)
조직ITU-T
위원회.ITU-T 연구 그룹 17
시리즈X
기본 규격ASN.1
관련 기준ISO/IEC 9594-8:2020, X.500
도메인암호화
웹 사이트www.itu.int/rec/T-REC-X.509

암호학에서 X.509는 공개키 [1]증명서의 형식을 정의하는 International Telecommunication Union(ITU; 국제전기통신연합) 표준입니다.X.509 인증서는 웹 검색을 위한 보안 프로토콜인 [2]HTTPS의 기반인 TLS/SSL을 비롯한 많은 인터넷 프로토콜에서 사용됩니다.또한 전자 서명과 같은 오프라인 응용 프로그램에서도 사용됩니다.

X.509 증명서는 디지털 서명을 사용하여 ID를 공개 키에 바인드합니다.증명서에는 아이덴티티(호스트명, 조직 또는 개인)와 공개키(RSA, DSA, ECDSA, ed25519 등)가 포함되어 인증국에 의해 서명되거나 자기서명이 됩니다.인증서가 신뢰할 수 있는 인증 기관에 의해 서명되거나 다른 방법으로 검증될 때, 해당 인증서를 보유한 사용자는 다른 당사자와 보안 통신을 설정하거나 해당 개인 키로 디지털 서명된 문서를 검증하기 위해 해당 인증서를 포함하는 공용 키를 사용할 수 있습니다.

X.509에서는 증명서 취소 리스트도 정의되어 있습니다.증명서 취소 리스트는 서명국에 의해 무효로 간주된 증명서에 관한 정보를 배포하는 수단이며 증명서 경로 검증 알고리즘도 정의되어 있습니다.증명서는 중간 CA 증명서에 의해 서명되며 증명서는 다른 증명서에 의해 서명됩니다.최종적으로 신뢰 앵커에 도달합니다.

X.509는 ITU-T Study Group 17의 International Telecommunications Union의 "Standardization Sector"(ITU-T)에 의해 정의되며, 또 다른 ITU-T 표준인 ASN.1에 기초하고 있습니다.

이력 및 사용방법

X.509는 1988년 7월 3일에 처음 발행되었으며 X.500 규격과 함께 시작되었습니다.이 서비스의 첫 번째 과제는 사용자에게 정보 리소스에 대한 안전한 액세스를 제공하고 암호화 중간자 공격을 피하는 것이었습니다.증명서 발급을 위한 엄격한 계층형 CA(인증국)를 전제로 하고 있습니다.이는 PGP와 같은 신뢰 모델의 웹과는 대조됩니다.이 모델에서는 (특수한 CA뿐만 아니라) 누구나 서명할 수 있기 때문에 다른 사람의 키 증명서의 유효성을 증명할 수 있습니다.

X.509 버전3에는 브리지나 [2]메쉬 등의 다른 토폴로지를 지원하는 유연성이 포함되어 있습니다.피어투피어 OpenPGP와 같은 신뢰 [citation needed]웹에서 사용할 수 있지만 2004년에는 거의 사용되지 않았습니다.X.500 시스템은 국가 정체성 정보 공유 조약 이행 목적으로 주권 국가에[which?] 의해서만 구현되었으며, IETF의 공개 키 인프라(X.509) 작업 그룹은 보다 유연한 인터넷 구성에 표준을 적용하였다.실제로 X.509 증명서라는 용어는 보통 IETF의 PKIX 증명서와 X.509 v3 증명서 표준의 CRL 프로파일을 나타냅니다. RFC5280, 일반적으로 PKIX for Public Key Infrastructure(X.509)[3]라고 불립니다.

Public Key Infrastructure(PKI; 공개키 인프라스트럭처)와 X.509 증명서의 초기 문제는 잘 알려진 "어떤 디렉토리" 문제였습니다.문제는 글로벌 X.500 디렉토리가 실현되지 않았기 때문에 클라이언트는 누락된 중간 증명서를 어디서 가져올지 모른다는 것입니다.이 문제는 요청에 모든 중간 인증서를 포함시킴으로써 완화되었습니다.예를 들어, 초기 웹 서버는 웹 서버의 인증서만 클라이언트에 보냈습니다.중간 CA 증명서가 없거나 증명서를 찾을 수 있는 위치가 없는 클라이언트는 CA에서 서버 증명서까지의 유효한 경로를 구축하지 못했습니다.이 문제를 해결하기 위해 웹 서버는 모든 중간 인증서를 웹 서버의 [4]인증서와 함께 보냅니다.

PKIX는 IETF 또는 인터넷의 PKI 표준을 참조하지만 다른 정책을 사용하는 다른 PKI도 많이 있습니다.예를 들어 미국 정부는 자체 정책을 가진 자체 PKI를 가지고 있고 CA/Browser Forum은 자체 정책을 가진 자체 PKI를 가지고 있습니다.미국 정부의 PKI는 2500페이지가 넘는 방대한 책이다.조직의 PKI가 IETF 또는 CA/Browser Forum과 너무 많이 다른 경우 조직은 웹 브라우저, cURL, Wget 등의 일반적인 도구와의 상호 운용성을 잃을 위험이 있습니다.예를 들어 PKI가 월요일에만 증명서를 발급하는 정책을 가지고 있는 경우 cURL이나 Wget 등의 일반적인 도구는 정책을 적용하지 않고 화요일에 [4]증명서를 발급할 수 있습니다.

증명서

X.509 증명서는 디지털 서명을 사용하여 아이덴티티를 공개 키에 바인드합니다.X.509 시스템에서는 2종류의 증명서가 있습니다.첫 번째는 CA 증명서입니다.두 번째는 엔드 엔티티 증명서입니다.CA 증명서는 다른 증명서를 발행할 수 있습니다.최상위 자기서명 CA 증명서는 루트 CA 증명서라고도 불립니다.다른 CA 증명서는 중간 CA 증명서 또는 하위 CA 증명서라고 불립니다.엔드 엔티티 증명서는 사용자(개인, 조직 또는 기업 등)를 식별합니다.엔드 엔티티 증명서는 다른 증명서를 발행할 수 없습니다.엔드 엔티티 증명서는 그 아래에 다른 증명서를 발행할 수 없기 때문에 리프 증명서라고 불리기도 합니다.

서명된 증명서를 필요로 하는 조직은 Certificate Signing Request(CSR; 증명서 서명요구), Simple Certificate Enrollment Protocol(SCEP) 또는 Certificate Management Protocol(CMP) 등의 프로토콜을 사용하여 CA에 증명서를 요구합니다.조직은 먼저 키 쌍을 생성하여 개인 키를 비밀로 유지하고 이를 사용하여 CSR에 서명합니다.CSR에는 CSR의 서명 확인에 사용되는 신청자 및 신청자의 공개키와 개인, 조직 또는 기업 고유의 식별명(DN)이 포함됩니다.CSR에는 인증국에 필요한 다른 자격 정보 또는 ID 증명서가 첨부될 수 있습니다.

CSR는 Registration Authority(RA; 등록국)를 사용하여 검증되며 인증국은 특정 인정자 이름에 공개키를 바인드하는 증명서를 발급합니다.일반적으로 역할 등록 기관과 인증 기관은 사기 위험을 줄이기 위해 별도의 업무 단위입니다.

조직의 신뢰할 수 있는 루트 인증서를 모든 직원에게 배포하여 회사 PKI [citation needed]시스템을 사용할 수 있습니다.Internet Explorer, Firefox, Opera, Safari, Chrome 등의 브라우저에는 미리 정해진 루트 증명서 세트가 미리 설치되어 있기 때문에 주요 인증 기관의 SSL 증명서는 즉시 작동합니다.실제로 브라우저 개발자는 브라우저 사용자의 [citation needed]신뢰할 수 있는 서드파티 CA를 결정합니다.예를 들어 Firefox는 포함된 CA [5]목록을 포함하는 CSV 및/또는 HTML 파일을 제공합니다.

X.509 및 RFC 5280에는 Certificate Revocation List(CRL; 증명서 취소 리스트) 실장의 표준도 포함되어 있습니다.IETF가 승인한 증명서의 유효성을 체크하는 또 다른 방법은 Online Certificate Status Protocol(OCSP)입니다.파이어폭스 3.0은 디폴트로 OCSP 체크를 유효하게 하고,[6] 적어도 Vista 이후의 Windows 버전도 유효하게 했습니다.

증명서 구조

표준에서 예측되는 구조는 공식 언어인 Abstract Syntax Notation One(ASN.1)로 표현됩니다.

X.509 v3 디지털 증명서의 구조는 다음과 같습니다.

  • 인증서.
    • 버전 번호
    • 일련 번호
    • 시그니처 알고리즘 ID
    • 발행자명
    • 유효기간
      • 이전 버전 아님
      • 다음 시간 이후 아님
    • 주체명
    • 제목 공개 키 정보
      • 공개 키 알고리즘
      • 제목 공개 키
    • Issuer Unique Identifier(옵션)
    • 서브젝트 고유 식별자(옵션)
    • 내선번호(옵션)
      • ...
  • 증명서 서명 알고리즘
  • 증명서 서명

각 내선번호에는 Object Identifier(OID; 객체 식별자)로 표현되는 고유한 ID가 있으며, 값 세트이며, 크리티컬 또는 중요하지 않은 표시도 포함됩니다.증명서를 사용하는 시스템에서는 인식할 수 없는 중요한 확장 또는 처리할 수 없는 정보가 포함된 중요한 확장이 발견되면 증명서를 거부해야 합니다.중요하지 않은 내선번호는 인식되지 않으면 무시될 수 있지만 [7]인식된 경우 처리되어야 합니다.

버전 1의 구조는 RFC 1422에 기재되어 있습니다.

ITU-T는 버전 2에서 발행자 및 대상 고유 식별자를 도입하여 발행자 또는 대상 이름을 일정 시간 후에 재사용할 수 있도록 했습니다.재사용의 예로는 CA가 파산하여 CA의 이름이 국가의 공개 목록에서 삭제되는 경우를 들 수 있습니다.시간이 지나면 같은 이름의 다른 CA가 첫 번째 CA와 관련이 없는 경우에도 자신을 등록할 수 있습니다.다만, IETF 에서는, 발행자와 서브젝트명을 재사용하지 않는 것을 추천합니다.따라서 버전 2는 인터넷에 [citation needed]널리 배치되어 있지 않습니다.

확장 기능은 버전 3에서 도입되었습니다.CA는 확장을 사용하여 특정 목적(예를 들어 디지털 객체에 서명하는 경우에만)에 대해서만 인증서를 발급할 수 있습니다.

모든 버전에서 시리얼 번호는 특정 CA에 의해 발행된 증명서별로 고유해야 합니다(RFC 5280 참조).

증명서의 특정 사용을 통지하는 확장자

RFC5280(및 그 이전 버전)에서는 증명서 사용방법을 나타내는 증명서 확장이 다수 정의되어 있습니다.대부분은 호에서 온 호입니다.joint-iso-ccitt(2) ds(5) id-ce(29)OID. 섹션 4.2.1에 정의되어 있는 가장 일반적인 것은 다음과 같습니다.

  • 기본 제약,{ id-ce 19 }는 증명서가 CA 증명서인지, 다른 증명서를 증명 또는 발급할 수 있는지를 나타내기 위해 사용됩니다.[8]제약조건은 중대하다고 표시할 수 있습니다.제약조건이 critical로 표시되어 있는 경우 에이전트가 해당 제약조건을 이해하지 못하면 에이전트가 증명서 처리에 실패해야 합니다.에이전트는 이해하지 못하는 중요하지 않은 제약 조건을 계속 처리할 수 있습니다.
  • 키 사용법,{ id-ce 15 }는 증명서에 포함된 공개키를 사용하여 실행할 수 있는 암호화 조작을 지정하는 비트맵을 제공합니다.[9]예를 들어 암호화에는 사용하지 않고 시그니처에는 사용할 필요가 있음을 나타내는 경우가 있습니다.
  • 확장 키 사용,{ id-ce 37 }는 보통 리프 증명서 상에서 증명서에 포함된 공개 키의 목적을 나타내기 위해 사용됩니다.[10]여기에는 OID 목록이 포함되어 있으며 각각 사용 가능한 것을 나타냅니다.예를들면,{ id-pkix 3 1 }TLS 또는 SSL 접속의 서버측에서 키를 사용할 수 있는 것을 나타냅니다.{ id-pkix 3 4 }키를 사용하여 전자 메일을 보호할 수 있음을 나타냅니다.

일반적으로 RFC 5280을 사용할 때 증명서에 사용을 제한하는 확장자가 여러 개 있는 경우 특정 용도에 맞게 모든 제한을 충족해야 합니다.RFC는 keyUsage와 extendedKeyUsage를 모두 포함하는 증명서의 구체적인 예를 제시합니다.이 경우 양쪽 확장자가 모두 처리되어야 하며 증명서를 사용할 수 있는 것은 증명서 사용방법에 일관성이 있는 경우뿐입니다.예를 들어 NSS는 두 확장자를 모두 사용하여 증명서 [11]사용을 지정합니다.

확장 검증 증명서

CA/Browser Forum의 PKI에 따라 운영되는 인증 기관은 다양한 검증 수준의 인증서를 발급합니다.검증에 따라 증명서가 의도하는 바를 나타내는 다양한 수준의 보증이 제공됩니다.예를 들어 웹 서버는 DV(Domain Validation)라는 전자 메일을 사용하여 최저 수준의 보증으로 검증할 수 있습니다.또는 확장 검증(EV)이라고 하는 보다 상세한 방법을 사용하여 웹 서버를 보다 높은 수준의 보증으로 검증할 수도 있습니다.

실제로 DV 증명서는 다음과 같은 도메인에 대해 발급된 증명서를 의미합니다.example.com보낸 이메일에 답장을 보낸 후webmaster@example.comEV 증명서는 다음과 같은 도메인에 대해 발급된 증명서를 의미합니다.example.com도메인 소유자는 Example, LLC와 같은 회사이며 소유자는 정관에 의해 확인되었습니다.

확장 검증에서는 보안 제어가 추가되지 않으므로 EV 증명서를 사용한 보안 채널 설정은 DV와 같은 다른 수준의 검증을 사용하는 채널 설정보다 "강하지 않습니다".

확장 검증은 X.509 v3 확장을 사용하여 증명서에 표시됩니다.각 CA는 확장 검증에 다른 Object Identifier(OID)를 사용합니다.확장 검증을 나타내는 단일 OID가 없기 때문에 사용자 에이전트 프로그래밍이 복잡해집니다.각 사용자 에이전트에는 확장 검증을 나타내는 OID 목록이 있어야 합니다.

CA/Browser Forum의 PKI는 확장 검증을 인식하고 많은 브라우저가 사용자에게 시각적 피드백을 제공하여 사이트가 EV 인증서를 제공함을 나타냅니다.인터넷의 PKI(PKIX)와 같은 다른 PKI는 확장 검증에 특별히 중점을 두지 않습니다.cURL이나 Wget 등 PKIX 정책을 사용하는 툴은 EV 증명서를 다른 증명서와 동일하게 취급합니다.

보안 전문가인 Peter Gutmann은 CA가 Race to Bottom의 수익 감소 후 수익 수준을 회복하기 위해 EV 인증서를 만들었다고 말합니다.하위권으로의 경쟁 동안 CA는 소비자가 인증서를 구매하도록 유인하기 위해 가격을 인하합니다.그 결과 수익이 감소했고 CA는 인증서에 [4]대한 보증이 거의 없을 정도로 그들이 수행하던 검증 수준을 떨어뜨렸습니다.

증명서 파일 이름 확장자

X.509 증명서에는 일반적으로 사용되는 파일 이름 확장자가 몇 가지 있습니다.안타깝게도 이러한 확장자 중 일부는 개인 키와 같은 다른 데이터에도 사용됩니다.

  • .pem– (프라이버시 강화 전자 메일) Base64로 인코딩된 DER 증명서(사이에 동봉-----BEGIN CERTIFICATE-----그리고.-----END CERTIFICATE-----
  • .cer,.crt,.der– 보통 바이너리 DER 형식이지만 Base64로 인코딩된 증명서도 일반적입니다( 참조)..pem위)
  • .p7b,.p7c– 데이터 없이 증명서 또는 CRL만 있는 PKCS#7 서명 데이터 구조
  • .p12– PKCS#12, 증명서(공개) 및 개인키(패스워드 보호)를 포함할 수 있습니다.
  • .pfx– PKCS#12의 이전 버전인 PFX(통상은 PKCS#12 형식의 데이터(IIS에서 생성된 PFX 파일 등)

PKCS#7은 데이터의 서명 또는 암호화(공식적으로는 「엔벨로핑」이라고 불립니다)의 표준입니다.서명된 데이터를 확인하는 데 인증서가 필요하므로 서명된 데이터 구조에 인증서를 포함할 수 있습니다.a.P7Cfile은 [citation needed]서명할 데이터가 없는 퇴화된 SignedData 구조입니다.

PKCS#12는 Personal Information Exchange(PFX; 개인 정보 교환) 규격에서 발전하여 퍼블릭 및 프라이빗 객체를 단일 [citation needed]파일로 교환하기 위해 사용됩니다.

인증서 체인 및 교차 인증서

증명서 체인(RFC 5280 섹션 3.2에 정의되어 있는 동등한 개념의 "증명 경로" 참조)은 증명서 목록(통상은 엔드 엔티티 증명서로 시작) 뒤에 1개 이상의 CA 증명서(통상은 자기 서명 증명서)가 이어지는 것으로, 다음과 같은 속성을 가집니다.

  1. 각 증명서의 발행자(마지막 증명서 제외)가 목록의 다음 증명서의 제목과 일치합니다.
  2. 각 증명서(마지막 증명서 제외)는 체인 내의 다음 증명서에 대응하는 비밀키에 의해 서명됩니다(즉, 다음 증명서에 포함된 공개키를 사용하여 증명서의 서명을 확인할 수 있습니다).
  3. 목록의 마지막 증명서는 신뢰 앵커입니다.신뢰할 수 있는 절차에 의해 전달되었기 때문에 신뢰하는 증명서입니다.

증명서 체인은 타깃 증명서(체인 내의 첫 번째 증명서)에 포함되어 있는 공개키(PK)와 그 안에 포함되어 있는 기타 데이터가 실질적으로 서브젝트에 속해 있는지 확인하기 위해 사용됩니다.이를 확인하기 위해 다음 증명서에 포함된 PK를 사용하여 대상 증명서의 서명을 확인합니다.다음 증명서는 체인 내의 마지막 증명서에 도달할 때까지 그 서명을 검증합니다.마지막 증명서는 신뢰 앵커이므로 정상적으로 도달하면 대상 증명서를 신뢰할 수 있음을 증명합니다.

전항의 설명은 RFC 5280 섹션6에서 정의한 증명서 경로 검증 프로세스에 대한 간략한 설명입니다.증명서 유효일 확인, CRL 검색 등 추가 체크가 포함됩니다.

예 1: 2개의 PKI 간의 크로스 증명서
예 2: CA 증명서 갱신

증명서 체인의 구축과 검증 방법을 조사할 때는 구체적인 증명서가 매우 다른 증명서 체인의 일부가 될 수 있다는 점에 주의해 주십시오(모두 유효합니다).이는 동일한 제목과 공개 키에 대해 여러 CA 증명서를 생성할 수 있지만 (다른 CA 또는 같은 CA의 다른 개인 키로) 서명할 수 있기 때문입니다.따라서 단일 X.509 증명서에는 발행자와 CA 시그니처가1개밖에 없지만 여러 증명서에 유효하게 링크하여 완전히 다른 증명서 체인을 구축할 수 있습니다.이것은, PKI 와 [12]다른 애플리케이션간의 크로스 인증에 불가결합니다.다음의 예를 참조해 주세요.

예

다음 그림에서:

  • 각 상자는 증명서를 나타냅니다.서브젝트는 굵은 글씨로 표시됩니다.
  • A → B는 "A가 B에 의해 서명되었다" (또는 더 정확히는 "A가 B에 포함된 공개 키에 해당하는 비밀 키로 서명되었다")를 의미한다.
  • 동일한 색상의 인증서(흰색/투명하지 않음)에 동일한 공용 키가 포함되어 있습니다.

예 1: 2개의 PKI 간의 루트 인증국(CA) 수준의 크로스 인증

PKI 2에 존재하는 사용자 증명서(「User 2」등)가 PKI 1로부터 신뢰되고 있는 것을 관리하기 위해서, CA1은 CA2의 [13]공개 키를 포함한 증명서(cert2.1)를 생성합니다.이제 "cert2"와 "cert2.1"(녹색) 모두 제목과 공개 키가 동일하므로, cert2.2 → cert2"와 "cert2.2 → cert2.1 → cert1"의 두 가지 유효한 체인이 있습니다.

마찬가지로 CA2는 CA1의 공개키를 포함한 증명서(cert1.1)를 생성하여 PKI 1에 존재하는 사용자 증명서(「User 1」등)를 PKI 2로부터 신뢰받을 수 있습니다.

예 2: CA 증명서 갱신

Understanding Certification Path Construction (PDF). PKI Forum. September 2002. To allow for graceful transition from the old signing key pair to the new signing key pair, the CA should issue a certificate that contains the old public key signed by the new private signing key and a certificate that contains the new public key signed by the old private signing key. Both of these certificates are self-issued, but neither is self-signed. Note that these are in addition to the two self-signed certificates (one old, one new).

cert1과 cert3은 모두 동일한 공용 키(구 키)를 포함하므로 cert5에는 "cert5 → cert1"과 "cert5 → cert3 → cert2"의 두 가지 유효한 인증서 체인이 있으며 cert6도 이와 유사합니다.이를 통해 오래된 사용자 [14]증명서(cert5 등)와 새로운 증명서(cert6 등)를 새로운 CA 키로의 이행 중에 새로운 루트 CA 증명서 또는 오래된 루트 CA 증명서를 신뢰 앵커로 가진 당사자에 의해 무관하게 신뢰할 수 있습니다.

샘플 X.509 증명서

이것은, wikipedia.org 와 그 외의 Wikipedia 의 Web 사이트에서 사용된, 디코딩 된 X.509 증명서의 예입니다.Issuer 필드에 기재된 바와 같이 GlobalSign에 의해 발행되었습니다.[ Subject ]필드는 조직으로서의 Wikipedia를 나타내고 DNS의 [Subject Alternative Name(SAN)]필드는 Wikipedia를 사용할 수 있는 호스트 이름을 나타냅니다.[ Subject Public Key Info ]필드에는 ECDSA 공개 키가 포함되어 있으며, 하단에 있는 시그니처는 GlobalSign의 RSA 개인 키에 의해 생성됩니다.

엔드 엔티티 증명서

증명서:데이터: 버전 3 (0x2) 일련 번호: 03:04:54:08:f9:ff:10:92:e1:69:fe:49:8f:78:d3:6d:47 시그니처 알고리즘:sha256WithRSAEncryption Issuer:C =US, O=Encrypt R,제목 : CN = *.wikipedia.org 제목 : 공용 키 정보 : id-ec 공용 키 알고리즘 : (256비트) pub : 04:a5:9a:47:b2:d3:fc:df:de:f6:cb:62:0a:d:d3:c1:d:38:dedd:ab:91:3f:0e:83:97:1b:4f:a2:99:f3:f8:30:73:ef:da:91:25:18:7a:d6:da:bf:e5:e9:72:a3:41:31:7a ASN1 OID:256:256:256V 니스타:256P:256:256:256V의 곡선TLS 웹 서버 인증, TLS 웹 클라이언트 인증 X509v3 기본 제약사항: 중요 CA:FALSE X509v3 서브젝트 키 식별자: 08:0E:29:26:07:E9:B4:5B:63:2D:86:5D:F6:E2:5A:8C:CD:6A:D0:A7 X509v3 인증국 키 식별자:keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C:C:6 액세스 인증국 정보NS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikimedia.org, DNS:*.m.wikinews.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wiktionary.org, DNS:*.m.wiktionary.org, DNS:*.m.wiktionary.org, DNS:*.m.wiktionary.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikisource.org, DNS:*.wikisource.org, DNS:*.wikisource.org, DNS:*.wiktionary.org, DNS:*.wiktionary.org, DNS:wikivoyage.org, DNS:*.wiktionary.org, DNS:mediawiki.org, DNS:mediawiki.org, DNS:*.w.wiki, DNS:wikibooks.org, DNS:wikimedia.org, DNS:wikinews.org, DNS:wikinews.org, DNS:wikipedia.org, DNS:wikisource.org, DNS:wikisource.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wiktionary.org, DNS:wiktionary.org, DNS:wmfusercontent.org X509v3 증명서 정책:정책: 2.23.140.1.2.1 정책: 1.3.6.1.4.44947.1.1.1 CPS: http://cps.letsencrypt.org CT 사전 증명서 SCT: 서명된 증명서 타임스탬프:버전 : v1 (0x0) 로그 ID : F6:5C:94:2F:D1:77:30:22:14:54:18:08:30:94:56:8E:E:E3:4D:13:19:33:BF:DF:0C:2F:20:0B:CC:4E:F1:64:E3 타임스탬프:7월 15일 09:01:49.274 2021 GMT 확장:none 시그니처: ecdsa-with-SHA256 30:46:02:00:88:0F:F3:F1:BC:A3:AD:B8:7B:FD : C2 : A6 : 6A : 4B : 7C : 1F : 35 : 18 : 7B : 3F : 18 : F6 : 43 : 29 : 46 :F6:C2:DD:15:63:C1:5D:02:21:00:CF:E0:1F:3D:E7:4A:37:C6: CD:E5:BC:CD:99:FE:9C:F1:F7:EA:04:2D:97:DA:C2:74:A6:30:37:57:F0:32:82:73 서명된 증명서 타임스탬프:버전: v1 (0x0) 로그 ID: 6F:53:76:AC:31:F0:31:19:D8:99:00:A4:51:15:FF:77:15:1C:11:D9:02:C1:00:29:06:8D:B2:08:9A:37:D9:13 타임스탬프:7월 15일 09:01:50.105 2021 GMT 확장:없음 시그니처:ecdsa-with-SHA256 30:44:02:20:37:BC:8F:6A:BA:FA:AC:0B:3B:4C:3F:C8: C2:AB:EA:3B:60:DE:A8:AB:44:72:E5:43:6A:E0:0A:24:32:49:7F:30:02:20:11:AF:F7:67:43:81:07:C7:FB:B6:89:55:0B:74:58:61:76:FB:62:FF:F4:C9:D0:C6:A7:43:63:98:4C:F5:4C:7E 시그니처 알고리즘:sha256WithRSAEncryption 8e:f4:d1:85:9c:96:e8:63:d0:38:fd:7a:cc:d5:ad:b2:06:b4:4:cf3:5:58:58:c:58:c:28:c:28:c:c:28:c:28:28:cb3:0b:2e:28:dc:5b:46:77:32:a7:d9:b1:e6:de9:9a:2b:5d:03:f2:e07:12:03:d9:03:d:a8:ef:60:32:c:53:c:c:c:5:c:c:5:c:5:c:5:cd1:76:93:f5:40:e2:15:18:be:e0:cb:5f:cd:d0:4f:fa:76:68:ba:94:c4:1d:1a:0e:3d:3b:ef:ed:1e:29:38:22:8bb:96:754:55e:55b:7:7:7:b

이 엔드 엔티티 증명서를 검증하려면 발행자 및 기관 키 ID와 일치하는 중간 증명서가 필요합니다.

발행자 C=BE, O=GlobalSign nv-sa, CN=GlobalSign 조직 검증 CA - SHA256 - G2
권한 키 식별자 14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

TLS 접속에서는 적절히 설정된 서버가 핸드쉐이크의 일부로 중간 서버를 제공합니다.단, 엔드 엔티티 증명서에서 "CA Issuers" URL을 취득하여 중간 증명서를 취득할 수도 있습니다.

중간 증명서

인증국에 속하는 중간 증명서의 예를 다음에 나타냅니다.이 증명서는 위의 엔드 엔티티 증명서에 서명하고 다음 루트 증명서에 의해 서명되었습니다.이 중간증명서의 제목 필드는 서명된 엔드엔티티 증명서의 발급자 필드와 일치합니다.또한 중간 키 ID 필드는 엔드 엔티티 증명서의 "authority key identifier" 필드와 일치합니다. 

증명서:데이터: 버전 3 (0x2) 일련 번호: 04:00:00:00:00:01:44:4e:f0:42:47 시그니처 알고리즘:sha256WithRSAEncryption 발행자:C=BE, O=Global Sign nv-sa, OU=Root CA, CN=글로벌 서명 전 루트 CA 유효하지 않음2014년 2월 20일 10:00 GMT 미사용 : 2024년 2월 20일 10:00 GMT 제목 :C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Subject 공개키 정보: 공개키 알고리즘: (2048 비트) 계수: 00:c7:0e:3f:23:93cc:f지수: 65537 (0x10001) X509v3 확장: X509v3 키 사용방법: 중요한 증명서 서명, CRL 서명 X509v3 기본 제약사항: 중요한 CA:TRUE, pathlen:0 X509v3 제목 키 식별자: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C X509v3 증명서 정책:정책: X509v3 모든 정책 CPS: https://www.globalsign.com/repository/ X509v3 CRL 배포 포인트:풀네임 : URI : http://crl.globalsign.net/root.crl 인증국 정보 액세스 : OCSP - URI : http://ocsp.globalsign.com/rootr1 X509v3 인증국 키 ID : keyid : 60 : 7B : 66 : 1A : 45 : 0D : 97 : CA : 89 : 50 : 2F : 7D : 04 : CD : 34 : A F : F : 4 : F : F : F : F : F : F : F : F : F : F : 4 : F : F : F : F : F : F : F : F : F : F : F : F 。RSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:86:71:74:b6:46:49:c8:...

루트 증명서

인증국을 나타내는 자기서명 루트 증명서의 예를 다음에 나타냅니다.발행자 필드와 제목 필드는 동일하며 자체 공개 키로 서명을 검증할 수 있습니다.트러스트 체인 검증은 여기서 종료해야 합니다.검증 프로그램의 신뢰 스토어에 이 루트 증명서가 있는 경우, 엔드 엔티티 증명서는 TLS 접속에서 사용하는 것으로 신뢰할 수 있는 것으로 간주할 수 있습니다.그렇지 않으면 엔드 엔티티 증명서는 신뢰할 수 없는 것으로 간주됩니다. 

증명서:[15]데이터: 버전 3 (0x2) 일련 번호: 04:00:00:00:00:01:15:4b:5a:c3:94 시그니처 알고리즘:sha1WithRSAEncryption 발행자:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=글로벌 루트 CA가 아님1998년 9월 1일 12:00:00 GMT 이후 없음 : 2028년 1월 28일 12:00:00 GMT 제목 :C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA 제목 공개 키 정보: 공개 키 알고리즘: rsaEncryption 공개 키: (2048 비트) 계수: 00:da:0e:8dce:a:3f:4f지수: 65537 (0x10001) X509v3 확장: X509v3 키 사용방법: 중요한 증명서 서명, CRL 서명 X509v3 기본 제약사항: 중요한 CA:True X509v3 서브젝트 키 식별자: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B 시그니처 알고리즘:sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:b5:...

보안.

Bruce Schneier, Peter Gutmann 및 기타 보안 전문가들의 [16][17][18]PKI 문제에 대한 많은 출판물이 있습니다.

아키텍처의 약점

  • 무효 증명서 블록 리스트 사용(CRL 및 OCSP 사용),
    • CRL을 사용할 수 있을 때만 클라이언트가 증명서를 신뢰하면 PKI를 매력적으로 만드는 오프라인 기능이 손실됩니다.따라서 대부분의 클라이언트는 CRL을 사용할 수 없는 경우 증명서를 신뢰하지만 이 경우 통신 채널을 제어하는 공격자는 CRL을 비활성화할 수 있습니다.구글의 Adam Langley는 소프트 페일 CRL 체크는 사고가 [19]났을 때를 제외하고는 효과가 있는 안전벨트와 같다고 말했다.
  • CRL은 큰 크기와 복잡한 분포 패턴으로 인해 매우 낮은 선택입니다.
  • 애매한 OCSP 의미론 및 이력 취소 상태 없음
  • 루트 증명서의 취소는 처리되지 않았습니다.
  • 집약 문제:아이덴티티 클레임(식별자에 의한 인증), 애트리뷰트 클레임(검증된 애트리뷰트 백 송신) 및 정책 클레임은 단일 컨테이너로 결합됩니다.이로 인해 프라이버시,[clarification needed] 정책 매핑 및 유지보수 문제가 발생합니다.
  • 위임 문제: CA는 제한된 네임스페이스 또는 속성 세트 이외의 증명서 발급을 기술적으로 제한할 수 없습니다.X.509의 이 기능은 사용되지 않습니다.따라서 인터넷상에 다수의 CA가 존재하며 CA와 CA의 정책을 분류하는 것은 극복할 수 없는 작업입니다.조직 내 권한 위임은 일반적인 비즈니스 [20]관행처럼 전혀 처리할 수 없습니다.
  • 페더레이션 문제:하위 CA, 브리지 CA 및 크로스 서명의 결과인 증명서 체인은 검증이 복잡하고 처리 시간이 많이 소요됩니다.경로 유효성 검사 의미가 모호할 수 있습니다.타사 신뢰할 수 있는 파티가 있는 계층이 유일한 모델입니다.이는 양국간 신뢰관계가 이미 형성되어 있는 상황에서 불편하다.
  • 호스트명의 Extended Validation(EV; 확장 검증) 증명서를 발행해도, 같은 호스트명에 유효한 낮은 검증 증명서의 발행은 방해되지 않습니다.즉, EV의 검증 레벨이 높을수록 man-in-the-middle 공격으로부터 [21]보호되지 않습니다.

인증 기관과의 문제

  • 증명서를 구입하는 개인 또는 조직은 가장 저렴한 인증 기관을 이용하는 경우가 많습니다.이에 대응하여 CA는 가격을 인하하고 바닥으로의 경주라고 알려진 더 비싼 검증 검사를 없앴습니다.Race to the Bottom은 확장 검증(EV) 인증서를 통해 부분적으로 해결되지만 보안 전문가가 보기에 신뢰의 가치는 떨어지고 있습니다.[22]Peter Gutmann에 따르면 EV 인증서는 추가적인 보안 제어를 추가하지 않습니다.오히려 EV 인증서는 CA가 처음부터 [4]제공했어야 할 서비스에 대해 더 많은 요금을 부과할 수 있도록 함으로써 CA의 수익을 최하위 레이스 이전 수준으로 되돌리기만 할 뿐입니다.
  • 인증당국은 인증실천서(CPS)에서 사용자와 의존 당사자에 대한 거의 모든 보증을 거부하려고 합니다.예를 들어, Apple Inc.는 CPS에서 "해당 법률에 의해 허용된 범위 내에서 가입자 계약은 상품성 또는 특정 [23]목적에 대한 적합성에 대한 보증을 포함하여 Apple로부터의 보증을 거부합니다."라고 명시하고 있습니다.
  • Peter Gutmann에 따르면, "사용자는 정의되지 않은 인증 요청 프로토콜을 사용하여 존재하지 않는 디렉토리의 불분명한 위치에 게시된 인증서를 얻습니다. 실제 [18]해지할 방법은 없습니다."
  • 모든 사업과 마찬가지로 CA는 자신이 운영하는 법적 관할구역에 속하며 고객과 사용자의 이익을 침해하도록 법적으로 강제될 수 있습니다.정보기관들은 또 디지노타 등 CA의 외부 타협을 통해 발급된 허위 증명서를 이용해 중간자 공격을 [citation needed]감행하고 있다.또 다른 예는 2018년 1월 1일부터 시행되는 새로운 네덜란드 법이 네덜란드 정보 및 보안 서비스에 새로운[24] 권한을 부여하기 때문에 네덜란드 정부의 CA의 철회 요청이다.

구현 문제

설계상의 결함, 버그, 규격의 해석의 차이, 규격의 상호 운용성의 결여로 인해 구현이 어려워지고 있습니다.다음과 같은 문제가 있습니다.[citation needed]

  • 많은 구현이 실효 체크를 해제합니다.
    • 장애물로 간주되어 정책이 시행되지 않음
    • 코드 서명을 포함한 모든 브라우저에서 기본적으로 설정되어 있는 경우 인프라스트럭처가 크래시됩니다[citation needed].
  • DN은 복잡하고 거의 이해되지 않는다(표준화 부족, 국제화 문제)
  • rfc822Name에는 2개의 표기가 있습니다.
  • 이름 및 정책 제약 조건은 거의 지원되지 않습니다.
  • 키 사용이 무시되었습니다. 목록의 첫 번째 인증서가 사용되고 있습니다.
  • 커스텀 OID의 적용이 어렵다
  • 클라이언트의[citation needed] 크래시를 일으키기 때문에, Atribut을 크리티컬하게 하지 말아 주세요.
  • 속성의 길이가 지정되지 않으면 제품별 제한이 발생합니다.
  • X.509에서 구현 오류가 발생하여 Null로 종단된[25] 문자열을 사용하거나 증명서의 코드 주입 공격을 사용하여 주체 이름을 조작할 수 있습니다.
  • 공격자는 개체 식별자의 잘못된 0x80 패딩 하위 식별자, 잘못된 구현 또는 클라이언트 브라우저의 정수 오버플로우를 사용하여[26] 알 수 없는 속성을 CSR에 포함할 수 있습니다. CA는 이를 "CN"(OID=2.5.4.3)으로 잘못 해석합니다.댄 카민스키, 제26회 카오스 커뮤니케이션 콩그레스 'PKI의 [27]검은 작전'

암호화의 약점

디지털 서명 시스템은 안전한 암호화 해시 함수에 의존합니다.공개 키 인프라스트럭처에서 더 이상 안전하지 않은 해시 함수를 사용할 수 있는 경우 공격자는 해시 함수의 약점을 이용하여 인증서를 위조할 수 있습니다.구체적으로는 공격자가 해시 충돌을 생성할 수 있는 경우 CA에 무해한 내용으로 증명서에 서명하도록 설득할 수 있습니다.이 경우 이러한 내용의 해시는 공격자가 선택한 값에 의해 작성된 다른 악의적인 증명서 콘텐츠의 해시 세트와 동일합니다.공격자는 CA가 제공한 시그니처를 악의적인 증명서 내용에 추가함으로써 CA에 의해 서명된 것으로 보이는 악의적인 증명서를 작성할 수 있습니다.악의적인 증명서의 내용은 공격자에 의해서만 선택되기 때문에, 무해한 증명서와 다른 유효일 또는 호스트명을 가질 수 있습니다.악의적인 인증서에는 "CA: true" 필드가 포함되어 신뢰할 수 있는 인증서를 추가로 발급할 수도 있습니다.

  • MD2 기반 증명서는 오랫동안 사용되어 프리이미지 공격에 취약했습니다.루트 증명서에는 이미 자기 서명이 있기 때문에 공격자는 이 서명을 사용하여 중간 증명서에 사용할 수 있습니다.
  • 2005년 Arjen Lenstra와 Benne de Weger는 MD5 해시함수에 [28]대한 충돌 공격을 사용하여 동일한 시그니처를 포함하고 공용 키만 다른2개의 X.509 증명서를 구축하는 방법을 시연했습니다.
  • 2008년, 알렉산더 소티로프와 마크 스티븐스는 카오스 커뮤니케이션 콩그레스에서 Rapid라는 사실을 이용하여 모든 일반적인 브라우저에 의해 받아들여지는 악성 인증 기관을 만들 수 있는 실용적인 공격을 제시했습니다.SSL은 MD5에 [29]근거한 X.509 증명서를 발행하고 있었습니다.
  • 2009년 4월 Eurocrypt [30]Conference에서 Macquarie University의 호주 연구진은 "Automatic Differential Path Searching for SHA-1"[31]을 발표했다.연구원들은 충돌 가능성을 [32]몇 배 정도 높이는 방법을 추론할 수 있었다.
  • 2017년 2월, 마크 스티븐스가 이끄는 연구팀이 SHA-1 충돌을 일으켜 SHA-1의 [33]약점을 입증했다.

암호화 취약점 완화

해시 충돌을 이용하여 X.509 서명을 위조하려면 공격자가 인증 기관이 서명할 데이터를 예측할 수 있어야 합니다.이는 CA가 서명하는 증명서(일반적으로 시리얼 번호)에 랜덤컴포넌트를 생성함으로써 다소 완화될 수 있습니다.CA/Browser Forum은 2011년부터 [34]Baseline Requirements Section 7.1에서 일련 번호 엔트로피를 요구했습니다.

2016년 1월 1일 기준 요건에서는 SHA-1을 사용한 인증서의 발급을 금지하고 있습니다.2017년 초 현재 Chrome 및[36] Firefox는 SHA-1을 사용하는 인증서를 거부합니다[35].2017년 5월 현재 Edge와[38] Safari 모두[37] SHA-1 인증서를 거부하고 있습니다.브라우저 이외의 X.509 검증자는 아직 SHA-1 [39]증명서를 거부하지 않습니다.

X.509의 PKI 규격

  • PKCS7(암호화 메시지 구문 표준 - [40]PKI용 서명된 메시지 및/또는 암호화된 메시지의 ID 증명 기능이 있는 공개 키)
  • TLS(Transport Layer Security) 및 이전 SSL - 인터넷 보안 [41]통신을 위한 암호화 프로토콜입니다.
  • OCSP([42]Online Certificate Status Protocol)/Certificate Revocation List(CRL)[43] - 증명서 취소 상태를 확인합니다.
  • PKCS12(Personal Information Exchange Syntax Standard) - 적절한 공개 키 증명서와[44] 함께 개인 키를 저장하기 위해 사용됩니다.
  • 인증 경로 구축 - 애플리케이션 내에서 X.509 공개 키 인증 경로를 구축하기 위한 가이드라인과 권장사항(CA 증명서를 사용한 엔드 엔티티 증명서 검증)

PKIX 작업 그룹

1995년, 미국 국립표준기술연구소와[45] 함께 인터넷 엔지니어링 태스크포스(Internet Engineering Task Force)가 공개키 인프라스트럭처(X.509) 작업 그룹을 구성했습니다.2014년 [46]6월에 체결된 작업 그룹은 일반적으로 "PKIX"라고 불립니다.또, X.509 의 실제의 사용 및 도입에 관한 RFC 및 그 외의 표준 문서를 작성했습니다.특히 인터넷 프로토콜에서 X.509를 사용하는 방법을 정의하는 RFC 3280과 후속 RFC 5280을 작성했습니다.

X.509 인증서를 사용하는 주요 프로토콜 및 표준

TLS/SSL 및 HTTPS는 WiFi 인증에 S/MIME(Secure Multipurpose Internet Mail Extensions) 및 EAP-TLS 방식과 마찬가지로 X.509의 RFC 5280 프로파일을 사용합니다.SMTP, POP, IMAP, LDAP, XMPP 등 TLS를 사용하는 프로토콜은 기본적으로 X.509를 사용합니다.

IPSec은 피어 인증에 RFC 4945 프로파일을 사용할 수 있습니다.

OpenCable 보안 사양에서는 케이블업계에서 사용하기 위한 X.509의 독자적인 프로파일을 정의하고 있습니다.

스마트 카드 및 TPM과 같은 장치에는 종종 자신 또는 소유자를 식별하는 인증서가 포함되어 있습니다.이러한 증명서는 X.509 형식입니다.

WS-Security 표준에서는 TLS 또는 자체 증명서 [15]프로파일을 통한 인증을 정의하고 있습니다.두 방법 모두 X.509를 사용합니다.

Microsoft Authenticode 코드 서명 시스템은 X.509를 사용하여 컴퓨터 프로그램 작성자를 식별합니다.

OPC UA 산업 자동화 통신 표준은 X.509를 사용합니다.

SSH는 일반적으로 최초 사용 시 신뢰 보안 모델을 사용하므로 인증서가 필요하지 않습니다.단, 일반적인 OpenSSH 구현에서는 X.509 이외의 증명서 형식에 [47]기초한 CA 서명 ID 모델이 지원됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "X.509: Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks". ITU. Retrieved 6 November 2019.
  2. ^ a b RFC 4158
  3. ^ "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". May 2008. Retrieved 29 May 2020. Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications.
  4. ^ a b c d Gutmann, Peter (April 2014). "Engineering Security" (PDF).
  5. ^ "CA:IncludedCAs". Mozilla Wiki. Retrieved 17 January 2017.
  6. ^ "Bug 110161 - (ocspdefault) enable OCSP by default". Mozilla. Retrieved 17 March 2016.
  7. ^ "RFC 5280 section 4.2". Tools. IETF. May 2008. Retrieved 12 February 2013.
  8. ^ "RFC 5280, Section 'Basic Constraints'".
  9. ^ "'RFC 5280, Section 'Key Usage'".
  10. ^ "RFC 5280, Section 'Extended Key Usage'".
  11. ^ Nelson B Boyard (9 May 2002). "All About Certificate Extensions". Mozilla. Retrieved 10 September 2020.
  12. ^ Lloyd, Steve (September 2002). Understanding Certification Path Construction (PDF). PKI Forum.
  13. ^ "Cross-Certification Between Root CAs". Qualified Subordination Deployment Scenarios. Microsoft. August 2009.
  14. ^ Nash; Duane; Joseph; Brink (2001). "Key and Certificate Life Cycles. CA Certificate Renewal". PKI: Implementing and Managing E-Security. RSA Press - Osborne/McGraw-Hill. ISBN 0-07-213123-3.
  15. ^ a b "Web Services Security X.509 Token Profile Version 1.1.1". Oasis. Retrieved 14 March 2017.
  16. ^ Carl Ellison and Bruce Schneier. "Top 10 PKI risks" (PDF). Computer Security Journal (Volume XVI, Number 1, 2000).
  17. ^ Peter Gutmann. "PKI: it's not dead, just resting" (PDF). IEEE Computer (Volume:35, Issue: 8).
  18. ^ a b Gutmann, Peter. "Everything you Never Wanted to Know about PKI but were Forced to Find Out" (PDF). Retrieved 14 November 2011.
  19. ^ Langley, Adam (5 February 2012). "Revocation checking and Chrome's CRL". Imperial Violet. Retrieved 2 February 2017.
  20. ^ "Security Systems Business Plan Sample [2021]". OGScapital. 2014-01-27. Retrieved 2021-06-30.
  21. ^ Michael Zusman; Alexander Sotirov (July 2009). "Sub-Prime PKI: Attacking Extended Validation SSL" (PDF). Blackhat. Retrieved 10 September 2020.
  22. ^ Hunt, Troy (17 September 2018). "Extended Validation Certificates are Dead". TroyHunt.com. Retrieved 26 February 2019.
  23. ^ "Certification Authority — Certification Practice Statement" (PDF). Version 6.1. Apple, Inc. August 19, 2016.
  24. ^ van Pelt, Cris. "Logius: Dutch Government CA trust issue". Bugzilla. Retrieved 31 October 2017.
  25. ^ Moxie Marlinspike (2009). "More Tricks for Defeating SSL in Practice" (PDF). Institute For Disruptive Studies. Blackhat. Retrieved 10 September 2020.
  26. ^ ITU-T X.690 참조, 조항 8.19.2
  27. ^ Dan Kaminsky (29 December 2009). "26C3: Black Ops Of PKI". CCC Events Blog. Der Chaos Computer Club. Retrieved 29 September 2013.
  28. ^ Lenstra, Arjen; de Weger, Benne (19 May 2005). On the possibility of constructing meaningful hash collisions for public keys (PDF) (Technical report). Lucent Technologies, Bell Laboratories & Technische Universiteit Eindhoven. Archived (PDF) from the original on 14 May 2013. Retrieved 28 September 2013.
  29. ^ "MD5 considered harmful today". Eindhoven University of Technology. 16 June 2011. Retrieved 29 September 2013.
  30. ^ "Eurocrypt 2009". International Association for Cryptologic Research.
  31. ^ Cameron McDonald; Philip Hawkes; Josef Pieprzyk (2009). "SHA-1 collisions now" (PDF). Macquarie University and Qualcomm. Retrieved 10 September 2020.
  32. ^ Dennis Dwyer (2 June 2009). "SHA-1 Collision Attacks Now 252". SecureWorks Insights. Retrieved 24 February 2016.
  33. ^ Marc Stevens; Elie Bursztein; Pierre Karpman; Ange Albertini; Yarik Markov. "The first collision for full SHA-1" (PDF). CWI Amsterdam & Google Research. Retrieved 10 September 2020 – via Shattered.
  34. ^ "Baseline Requirements Documents". CA Browser Forum. Retrieved 19 March 2017.
  35. ^ Andrew Whalley (16 November 2016). "SHA-1 Certificates in Chrome". Google Online Security Blog. Retrieved 19 March 2017.
  36. ^ "The end of SHA-1 on the Public Web". Mozilla Security Blog. Retrieved 19 March 2017.
  37. ^ "Microsoft Security Advisory 4010323". Technet. Microsoft. Retrieved 16 May 2017.
  38. ^ "Safari and WebKit do not support SHA-1 certificates". Apple Support. 16 August 2018. Retrieved 10 September 2020.
  39. ^ Daniel Stenburg (10 January 2017). "Lesser HTTPS for non-browsers". Daniel Hax. Retrieved 19 March 2017.
  40. ^ B Kaliski (March 1998). "PKCS #7: Cryptographic Message Syntax Version 1.5". IETF. Retrieved 10 September 2020.
  41. ^ T Dierks (August 2008). "The Transport Layer Security (TLS) Protocol Version 1.2". IETF. Retrieved 10 September 2020.
  42. ^ Stefan Santesson; Michael Myers; Rich Ankey; Slava Galperin; Carlisle Adams (June 2013). "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP". Tools. IETF. Retrieved 10 September 2020.
  43. ^ David Cooper; Stefan Santesson; Stephen Farrell; Sharon Boeyen; Russell Housley; Tim Polk (May 2008). "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". Tools. IETF. Retrieved 10 September 2020.
  44. ^ "PKCS 12: Personal Information Exchange Syntax Standard". EMC.com. RSA Laboratories. Archived from the original on 6 July 2017. Retrieved 19 March 2017.
  45. ^ "Public-Key Infrastructure (X.509) (pkix) - Charter". IETF Datatracker. Internet Engineering Task Force. Retrieved 1 October 2013.
  46. ^ "Pkix Status Pages". IETF Tools. Retrieved 10 March 2017.
  47. ^ "How To Create an SSH CA to Validate Hosts and Clients with Ubuntu". DigitalOcean. Retrieved 19 March 2017.

외부 링크