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

1星需积分: 45 163 浏览量更新于2024-07-19 收藏 159KB PDF 举报

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

领优惠券(最高得80元）

“互联网X.509公开密钥基础设施证书和CRL（证书撤销列表）配置文件” 本文档详细阐述了用于互联网的X.509v3数字证书和X.509v2 CRL（证书撤销列表）的标准规范。X.509是一种国际标准，用于在分布式计算环境中验证网络实体的身份，特别是在网络安全通信中，如HTTPS、电子邮件和SSL/TLS协议。首先，我们要理解数字证书的基本原理。它是一个电子文档，包含了一个公钥以及与该公钥相关联的个人信息，如组织名称、地理位置和有效期等。这个公钥可以用来加密数据，只有持有对应私钥的一方才能解密，从而确保数据的安全传输。数字证书由可信的第三方机构，即证书颁发机构（CA）进行签名，以证明证书持有者的身份。 X.509v3证书扩展了X.509v2版本，增加了更多的灵活性和功能。例如，证书可以包含一套扩展，用于定义额外的属性，如证书的用途（如服务器身份验证或电子邮件保护）、证书策略、密钥用法（如签名或加密）等。这些扩展使得证书能够适应各种不同的应用场景。在互联网环境中，X.509v3证书特别关注了Internet名的形式，如IP地址和域名。证书中的Subject字段通常包含这些信息，以标识证书所代表的实体。此外，文档还描述了如何处理这些名形式的格式和语义，确保正确解析和验证。此外，文档定义了一个新的互联网特定扩展，这可能涉及到特定的行业标准或技术要求。这样的扩展可以增强证书的适用性和互操作性，比如实现更严格的隐私保护或适应新的安全需求。证书撤销列表（CRL）是另一个关键概念，它是一个由证书颁发机构发布的列表，列出已被撤销的证书。当证书因丢失、被盗或不再信任时，会被添加到CRL中。客户端在验证证书有效性时会检查CRL，以确保证书没有被撤销。总结来说，X.509v3数字证书和CRL是互联网安全的基础组件，它们确保了网络通信的安全和可信度。通过标准化的证书格式和扩展，以及证书撤销机制，用户可以信任他们正在与正确且安全的实体进行交互。这个文档提供了一个全面的框架，指导了如何在互联网上有效和安全地使用这些证书。

资源详情

资源推荐

RFC 2459 Internet X.509 Public Key Infrastructure January 1999

Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {

notBefore Time,

notAfter Time }

Time ::= CHOICE {

utcTime UTCTime,

generalTime GeneralizedTime }

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }

The following items describe the X.509 v3 certificate for use in the

Internet.

4.1.1 Certificate Fields

The Certificate is a SEQUENCE of three required fields. The fields

are described in detail in the following subsections.

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 may also include 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.

Section 7.2 lists the supported signature algorithms.

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

Housley, et. al. Standards Track [Page 16]

RFC 2459 Internet X.509 Public Key Infrastructure January 1999

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. Section 7.2

lists the supported algorithms for this specification.

This field MUST contain the same algorithm identifier as the

signature field in the sequence tbsCertificate (see sec. 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 then ASN.1 encoded as a BIT STRING and included in

the Certificate’s signature field. The details of this process are

specified for each of the supported algorithms in Section 7.2.

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 who issued it. Every

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

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 may also include

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, use X.509 version 3

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

is present, use version 2 (value is 1). If only basic fields are

present, use version 1 (the value is omitted from the certificate as

the default value).

Housley, et. al. Standards Track [Page 17]

RFC 2459 Internet X.509 Public Key Infrastructure January 1999

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. The

UTF8String encoding is the preferred encoding, and all certificates

issued after December 31, 2003 MUST use the UTF8String encoding of

DirectoryString (except as noted below). Until that date, conforming

CAs MUST choose from the following options when creating a

distinguished name, including their own:

(a) if the character set is sufficient, the string MAY be

represented as a PrintableString;

(b) failing (a), if the BMPString character set is sufficient the

string MAY be represented as a BMPString; and

UTF8String. If (a) or (b) is satisfied, the CA MAY still choose

to represent the string as a UTF8String.

Exceptions to the December 31, 2003 UTF8 encoding requirements are as

follows:

(a) CAs MAY issue "name rollover" certificates to support an

orderly migration to UTF8String encoding. Such certificates would

include the CA’s UTF8String encoded name as issuer and and the old

name encoding as subject, or vice-versa.

(b) As stated in section 4.1.2.6, the subject field MUST be

populated with a non-empty distinguished name matching the

contents of the issuer field in all certificates issued by the

subject CA regardless of encoding.

The TeletexString and UniversalString are included for backward

compatibility, and should not be used for certificates for new

subjects. However, these types may be used in certificates where the

name was previously established. Certificate users SHOULD be

prepared to receive certificates with these types.

Housley, et. al. Standards Track [Page 19]

RFC 2459 Internet X.509 Public Key Infrastructure January 1999

In addition, many legacy implementations support names encoded in the

ISO 8859-1 character set (Latin1String) but tag them as

TeletexString. The Latin1String includes characters used in Western

European countries which are not part of the TeletexString charcter

set. Implementations that process TeletexString SHOULD be prepared

to handle the entire ISO 8859-1 character set.[ISO 8859-1]

As noted above, distinguished names are composed of attributes. This

specification does not restrict the set of attribute types that may

appear in names. However, conforming implementations MUST be

prepared to receive certificates with issuer names containing the set

of attribute types defined below. This specification also recommends

support for additional attribute types.

Standard sets of attributes have been defined in the X.500 series of

specifications.[X.520] Implementations of this specification MUST be

prepared to receive the following standard attribute types in issuer

names: country, organization, organizational-unit, distinguished name

qualifier, state or province name, and common name (e.g., "Susan

Housley"). In addition, implementations of this specification SHOULD

be prepared to receive the following standard attribute types in

issuer names: locality, title, surname, given name, initials, and

generation qualifier (e.g., "Jr.", "3rd", or "IV"). The syntax and

associated object identifiers (OIDs) for these attribute types are

provided in the ASN.1 modules in Appendices A and B.

In addition, implementations of this specification MUST be prepared

to receive the domainComponent attribute, as defined in [RFC 2247].

The Domain (Nameserver) System (DNS) provides a hierarchical resource

labeling system. This attribute provides is a convenient mechanism

for organizations that wish to use DNs that parallel their DNS names.

This is not a replacement for the dNSName component of the

alternative name field. Implementations are not required to convert

such names into DNS names. The syntax and associated OID for this

attribute type is provided in the ASN.1 modules in Appendices A and

Certificate users MUST be prepared to process the issuer

distinguished name and subject distinguished name (see sec. 4.1.2.6)

fields to perform name chaining for certification path validation

(see section 6). Name chaining is performed by matching the issuer

distinguished name in one certificate with the subject name in a CA

certificate.

This specification requires only a subset of the name comparison

functionality specified in the X.500 series of specifications. The

requirements for conforming implementations are as follows:

Housley, et. al. Standards Track [Page 20]

剩余128页未读，继续阅读

syq168

粉丝: 0
资源: 5

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

软件证书解析

数字证书原理之详细解析

数字证书生成

数字签名和数字证书详解

openssl 生成证书 详解

pytorch cnn手写体数字识别代码详解

nfc数字协议技术详解

cmake手册详解下载

linux进入密钥生成目录,linux nginx 配置ssl访问实例详解生成证书可以通过以下步

ros navigation 源码详解

simulink实例详解pdf

visionpro工具详解pdf

ohos串口485代码详解

详解matlab的数字滤波器设计

nacos配置参数详解

canopen协议详解 pdf

fabric运行过程概念详解

yolov8代码详解

tcp/ip协议详解 目录

opencv手势表示数字o-9详解图

最新资源

openssl 生成证书详解

tcp/ip协议详解目录