X.509 v3证书与CRL互联网标准规范

国密证书

X509

需积分: 50 158 浏览量更新于2024-07-17 1 收藏 275KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

X.509证书规范是互联网公钥基础设施（Public Key Infrastructure, PKI）家族标准的重要组成部分，它针对互联网环境下的证书和证书撤销列表（Certificate Revocation List, CRL）提供了格式和语义规范。该标准由Network Working Group D. Cooper等多位专家共同制定，于2008年5月由NIST发布，旨在为互联网社区定义一套统一的协议，用于处理认证路径并支持安全通信。在X.509 v3证书部分，该规范详细描述了证书的结构，包括其组成元素、公钥信息以及数字签名，确保了数据的完整性和身份验证。特别强调了互联网名称形式的格式和语义，这是与传统X.509 v2证书的一个关键区别，以便适应互联网特定的需求。标准还定义了通用的证书扩展，这些扩展提供了额外的功能和服务，如扩展属性、基本约束、权限信息等。此外，该规范特别关注互联网特有的两个扩展，这可能涉及到特定的应用场景或安全性增强措施。这些扩展可能是为了更好地支持在线服务的身份验证、访问控制、信任链管理等，使得证书在互联网环境中更为灵活且具有更强的安全保障。对于CRL，X.509 v3 CRL Profile同样提供了标准化的格式和处理方法，用于通知接收者哪些证书已被撤销，以防止使用已失效或被废除的证书进行恶意活动。CRL的生成、分发和更新机制也得到了详述，确保了及时的信息传递和信任链的维护。在整个文档中，标准要求互联网社群积极参与讨论和提出改进意见，以保持标准的最新性和适应性。同时，该文档广泛发布，表明其已被广泛接受并在全球范围内作为互联网安全的基础技术之一使用。 X.509证书规范是网络安全和信任体系的核心组件，它定义了在网络通信中如何通过证书和CRL来验证参与者身份、维护数据完整性和管理信任关系，是确保互联网信息安全的重要基石。

资源详情

资源推荐

RFC 5280

PKIX Certificate and CRL Profile May 2008

The PKIX series of specifications defines a set of standard message

formats supporting the above functions. The protocols for conveying

these messages in different environments (e.g., email, file transfer,

and WWW) are described in those specifications.

4. Certificate and Certificate Extensions Profile

This section presents a profile for public key certificates that will

foster interoperability and a reusable PKI. This section is based

upon the X.509 v3 certificate format and the standard certificate

extensions defined in [

X.509]. The ISO/IEC and ITU-T documents use

the 1997 version of ASN.1; while this document uses the 1988 ASN.1

syntax, the encoded certificate and standard extensions are

equivalent. This section also defines private extensions required to

support a PKI for the Internet community.

Certificates may be used in a wide range of applications and

environments covering a broad spectrum of interoperability goals and

a broader spectrum of operational and assurance requirements. The

goal of this document is to establish a common baseline for generic

applications requiring broad interoperability and limited special

purpose requirements. In particular, the emphasis will be on

supporting the use of X.509 v3 certificates for informal Internet

electronic mail, IPsec, and WWW applications.

4.1. Basic Certificate Fields

The X.509 v3 certificate basic syntax is as follows. For signature

calculation, the data that is to be signed is encoded using the ASN.1

distinguished encoding rules (DER) [

X.690]. ASN.1 DER encoding is a

tag, length, value encoding system for each element.

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

TBSCertificate ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version MUST be v2 or v3

Cooper, et al. Standards Track [Page 16]

RFC 5280

PKIX Certificate and CRL Profile May 2008

4.1.1.1. tbsCertificate

The field contains the names of the subject and issuer, a public key

associated with the subject, a validity period, and other associated

information. The fields are described in detail in

Section 4.1.2;

the tbsCertificate usually includes extensions, which are described

Section 4.2.

4.1.1.2. signatureAlgorithm

The signatureAlgorithm field contains the identifier for the

cryptographic algorithm used by the CA to sign this certificate.

[

RFC3279], [RFC4055], and [RFC4491] list supported signature

algorithms, but other signature algorithms MAY also be supported.

An algorithm identifier is defined by the following ASN.1 structure:

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL }

The algorithm identifier is used to identify a cryptographic

algorithm. The OBJECT IDENTIFIER component identifies the algorithm

(such as DSA with SHA-1). The contents of the optional parameters

field will vary according to the algorithm identified.

This field MUST contain the same algorithm identifier as the

signature field in the sequence tbsCertificate (

Section 4.1.2.3).

4.1.1.3. signatureValue

The signatureValue field contains a digital signature computed upon

the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded

tbsCertificate is used as the input to the signature function. This

signature value is encoded as a BIT STRING and included in the

signature field. The details of this process are specified for each

of the algorithms listed in [

RFC3279], [RFC4055], and [RFC4491].

By generating this signature, a CA certifies the validity of the

information in the tbsCertificate field. In particular, the CA

certifies the binding between the public key material and the subject

of the certificate.

4.1.2. TBSCertificate

The sequence TBSCertificate contains information associated with the

subject of the certificate and the CA that issued it. Every

TBSCertificate contains the names of the subject and issuer, a public

Cooper, et al. Standards Track [Page 18]

RFC 5280

PKIX Certificate and CRL Profile May 2008

key associated with the subject, a validity period, a version number,

and a serial number; some MAY contain optional unique identifier

fields. The remainder of this section describes the syntax and

semantics of these fields. A TBSCertificate usually includes

extensions. Extensions for the Internet PKI are described in

Section

4.2.

4.1.2.1. Version

This field describes the version of the encoded certificate. When

extensions are used, as expected in this profile, version MUST be 3

(value is 2). If no extensions are present, but a UniqueIdentifier

is present, the version SHOULD be 2 (value is 1); however, the

version MAY be 3. If only basic fields are present, the version

SHOULD be 1 (the value is omitted from the certificate as the default

value); however, the version MAY be 2 or 3.

Implementations SHOULD be prepared to accept any version certificate.

At a minimum, conforming implementations MUST recognize version 3

certificates.

Generation of version 2 certificates is not expected by

implementations based on this profile.

4.1.2.2. Serial Number

The serial number MUST be a positive integer assigned by the CA to

each certificate. It MUST be unique for each certificate issued by a

given CA (i.e., the issuer name and serial number identify a unique

certificate). CAs MUST force the serialNumber to be a non-negative

integer.

Given the uniqueness requirements above, serial numbers can be

expected to contain long integers. Certificate users MUST be able to

handle serialNumber values up to 20 octets. Conforming CAs MUST NOT

use serialNumber values longer than 20 octets.

Note: Non-conforming CAs may issue certificates with serial numbers

that are negative or zero. Certificate users SHOULD be prepared to

gracefully handle such certificates.

4.1.2.3. Signature

This field contains the algorithm identifier for the algorithm used

by the CA to sign the certificate.

This field MUST contain the same algorithm identifier as the

signatureAlgorithm field in the sequence Certificate (Section

Cooper, et al. Standards Track [Page 19]

RFC 5280

PKIX Certificate and CRL Profile May 2008

4.1.1.2). The contents of the optional parameters field will vary

according to the algorithm identified. [

RFC3279], [RFC4055], and

[

RFC4491] list supported signature algorithms, but other signature

algorithms MAY also be supported.

4.1.2.4. Issuer

The issuer field identifies the entity that has signed and issued the

certificate. The issuer field MUST contain a non-empty distinguished

name (DN). The issuer field is defined as the X.501 type Name

[

X.501]. Name is defined by the following ASN.1 structures:

Name ::= CHOICE { -- only one possibility for now --

rdnSequence RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::=

SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {

type AttributeType,

value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType

DirectoryString ::= CHOICE {

teletexString TeletexString (SIZE (1..MAX)),

printableString PrintableString (SIZE (1..MAX)),

universalString UniversalString (SIZE (1..MAX)),

utf8String UTF8String (SIZE (1..MAX)),

bmpString BMPString (SIZE (1..MAX)) }

The Name describes a hierarchical name composed of attributes, such

as country name, and corresponding values, such as US. The type of

the component AttributeValue is determined by the AttributeType; in

general it will be a DirectoryString.

The DirectoryString type is defined as a choice of PrintableString,

TeletexString, BMPString, UTF8String, and UniversalString. CAs

conforming to this profile MUST use either the PrintableString or

UTF8String encoding of DirectoryString, with two exceptions. When

CAs have previously issued certificates with issuer fields with

attributes encoded using TeletexString, BMPString, or

UniversalString, then the CA MAY continue to use these encodings of

the DirectoryString to preserve backward compatibility. Also, new

Cooper, et al. Standards Track [Page 20]

剩余150页未读，继续阅读

魔琴师

粉丝: 14
资源: 31

X.509 v3证书与CRL互联网标准规范

X509 RFC5280规范

c语言写成的取x.509证书公钥

ASN1文件查看（X509证书）

x509证书，x509证书，x509证书

x509证书中issuer规范

X509证书的各种操作

x509证书结构解析源码

x.509 证书说明书

read509.tar.gz_X509格式_read509_x509 解析_解析证书_证书

X.509数字证书

互联网X.509公钥基础设施数字证书规范

深入理解X.509证书结构与ASN.1编码

X.506证书 509 588证书 很全 有效期10年

x509_util.zip_android_cert_ndk android_x509_x509_util

X.509证书格式：网络安全中的身份验证基石

X.509数字证书格式详解

SAMLv2.0 X.509认证部署规范

X.509数字证书标准详解与应用

最新资源

X.506证书 509 588证书很全有效期10年