"X.509标准及RFC 5280在PKI和CRL中的应用"

需积分: 5 73 浏览量更新于2023-12-21 收藏 257KB PDF 举报

X.509是一种公钥基础设施（PKI）标准，用于验证网络通信中的数字证书。RFC 5280是关于X.509证书认证的规范，它规定了证书的格式、结构和验证过程。文档中还介绍了证书吊销列表（CRL）的使用，CRL是用于废止证书的一种机制。该规范的修订版废除了旧版的3280、4325和4630规范。文档由来自NIST、Microsoft和Trinity College Dublin等机构的专家联合制定。 X.509是一种在互联网上使用的非对称密钥加密体系，由国际电信联盟（ITU-T）制定并由国际标准化组织（ISO）进行标准化。X.509定义了证书的结构和内容，包括颁发者、主体、公钥、有效期等信息，并使用数字签名进行验证。RFC 5280对X.509标准进行了详细规范，确保了证书在网络通信中的安全可靠性。 RFC 5280规范了证书的基本要素，包括版本号、序列号、签名算法、颁发者信息、主体信息、公钥信息等。它还规定了证书验证的过程，包括验证链、证书策略、CRL分发点等。此外，该规范还详细介绍了CRL的结构和使用方法，CRL是用于废止证书的一种机制，可以有效地保证证书的有效性和安全性。 RFC 5280是在早期RFC 3280、4325和4630的基础上进行修订的，这些旧版规范已经无法满足当前网络通信的安全需求。通过修订和更新，RFC 5280保持了X.509标准的先进性和实用性，为互联网上的安全通信提供了规范和指导。文档的撰写者来自NIST、Microsoft和Trinity College Dublin等机构，他们在PKI和网络安全领域有着丰富的经验和专业知识。他们通过合作和交流，制定了这一权威的证书认证规范，为网络通信的安全性和可靠性提供了重要支持和保障。综上所述，RFC 5280是关于X.509证书认证的重要规范，它规范了证书的格式、结构和验证过程，介绍了CRL的使用方法，并取代了旧版规范。该规范的制定者是来自NIST、Microsoft和Trinity College Dublin等机构的专家，他们对PKI和网络安全有着丰富的经验和专业知识。RFC 5280的发布将为互联网上的安全通信提供重要的规范和指导。

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

in 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]

剩余151页未读，继续阅读

洲游

粉丝: 0
资源: 1

"X.509标准及RFC 5280在PKI和CRL中的应用"

X.509证书与CRL的ASN.1详解

RFC2585：互联网X.509公钥机制操作协议：FTP与HTTP的证书与CRL获取

互联网X.509公钥基础设施标准(RFC2459解读)

x.509-rfc2459.zip

X509 RFC5280规范

rfc2459.zip_509_RFC2459 C_X.509_公钥基础设施

RFC与X.509相关的技术规范.zip

RFC2585_互联网X.509公用密钥机制操作协议:FTP和HTTP

A Quick View of ASN.1 Notations for X.509

X.509数字证书格式详解

最新资源