RFC 2510：X.509公钥基础设施证书管理协议详解

需积分: 10 93 浏览量更新于2024-07-29 收藏 95KB PDF 举报

RFC2510文档是关于Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols的标准化协议，由Network Working Group C. Adams和S. Farrell在1999年3月共同编撰。该标准跟踪类别文档详细描述了X.509证书的创建与管理过程，特别关注的是X.509版本3（v3）证书，这是根据[COR95, X509-AM]定义的。文档中的关键术语如"MUST"、"MAY"等，表示了不同级别的强制性和建议性要求。 X.509是一种用于数字证书的标准，它定义了公钥基础设施中身份认证和加密通信的基础结构。在RFC2510中，协议消息被明确地定义，涵盖了证书生命周期的各个环节，包括证书的签发、更新、撤销、查询以及证书链的验证。这些协议确保了互联网环境中安全通信的可信度，对于SSL/TLS（Secure Sockets Layer/Transport Layer Security）协议的实现至关重要，因为它们依赖于X.509证书来验证服务器的身份。文档强调，这个标准是互联网标准化进程的一部分，任何对协议的讨论和改进意见都受到欢迎，并且建议读者参考互联网官方协议标准（STD1）来了解当前的标准化状态和此协议的适用范围。版权方面，Internet Society拥有1999年的所有权利，并保留所有权益。通过RFC2510，网络管理员、开发者和安全专业人士可以遵循这套规范来构建和维护一个安全的、基于X.509 PKI的网络环境。理解并实施这些证书管理协议对于确保数据传输的机密性、完整性和真实性，以及防止中间人攻击具有重要意义。同时，随着技术的发展和安全需求的变化，持续关注RFC2510的更新和扩展，以适应不断演进的网络安全威胁是十分必要的。

RFC 2510 PKI Certificate Management Protocols March 1999

centralized key generation service - the actual key pair MAY have

been generated elsewhere and transported to the end entity, RA, or CA

using a (proprietary or standardized) key generation request/response

protocol (outside the scope of this specification).

There are thus three possibilities for the location of "key

generation": the end entity, an RA, or a CA.

2.2.1.4 Confirmation of successful certification

Following the creation of an initial certificate for an end entity,

additional assurance can be gained by having the end entity

explicitly confirm successful receipt of the message containing (or

indicating the creation of) the certificate. Naturally, this

confirmation message must be protected (based on the initial

authentication key or other means).

This gives two further possibilities: confirmed or not.

2.2.2 Mandatory schemes

The criteria above allow for a large number of initial registration /

certification schemes. This specification mandates that conforming CA

equipment, RA equipment, and EE equipment MUST support the second

scheme listed below. Any entity MAY additionally support other

schemes, if desired.

2.2.2.1 Centralized scheme

In terms of the classification above, this scheme is, in some ways,

the simplest possible, where:

- initiation occurs at the certifying CA;

- no on-line message authentication is required;

- "key generation" occurs at the certifying CA (see Section 2.2.1.3);

- no confirmation message is required.

In terms of message flow, this scheme means that the only message

required is sent from the CA to the end entity. The message must

contain the entire PSE for the end entity. Some out-of-band means

must be provided to allow the end entity to authenticate the message

received and decrypt any encrypted values.

Adams & Farrell Standards Track [Page 12]

RFC 2510 PKI Certificate Management Protocols March 1999

2.2.2.2 Basic authenticated scheme

In terms of the classification above, this scheme is where:

- initiation occurs at the end entity;

- message authentication is REQUIRED;

- "key generation" occurs at the end entity (see Section 2.2.1.3);

- a confirmation message is REQUIRED.

In terms of message flow, the basic authenticated scheme is as

follows:

End entity RA/CA

========== =============

out-of-band distribution of Initial Authentication

Key (IAK) and reference value (RA/CA -> EE)

Key generation

Creation of certification request

Protect request with IAK

-->>--certification request-->>--

verify request

process request

create response

--<<--certification response--<<--

handle response

create confirmation

-->>--confirmation message-->>--

verify confirmation

(Where verification of the confirmation message fails, the RA/CA MUST

revoke the newly issued certificate if it has been published or

otherwise made available.)

2.3 Proof of Possession (POP) of Private Key

In order to prevent certain attacks and to allow a CA/RA to properly

check the validity of the binding between an end entity and a key

pair, the PKI management operations specified here make it possible

for an end entity to prove that it has possession of (i.e., is able

to use) the private key corresponding to the public key for which a

certificate is requested. A given CA/RA is free to choose how to

enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in-

band messages) in its certification exchanges (i.e., this may be a

policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP

by some means because there are currently many non-PKIX operational

protocols in use (various electronic mail protocols are one example)

that do not explicitly check the binding between the end entity and

the private key. Until operational protocols that do verify the

Adams & Farrell Standards Track [Page 13]

RFC 2510 PKI Certificate Management Protocols March 1999

binding (for signature, encryption, and key agreement key pairs)

exist, and are ubiquitous, this binding can only be assumed to have

been verified by the CA/RA. Therefore, if the binding is not verified

by the CA/RA, certificates in the Internet Public-Key Infrastructure

end up being somewhat less meaningful.

POP is accomplished in different ways depending upon the type of key

for which a certificate is requested. If a key can be used for

multiple purposes (e.g., an RSA key) then any appropriate method MAY

be used (e.g., a key which may be used for signing, as well as other

purposes, SHOULD NOT be sent to the CA/RA in order to prove

possession).

This specification explicitly allows for cases where an end entity

supplies the relevant proof to an RA and the RA subsequently attests

to the CA that the required proof has been received (and validated!).

For example, an end entity wishing to have a signing key certified

could send the appropriate signature to the RA which then simply

notifies the relevant CA that the end entity has supplied the

required proof. Of course, such a situation may be disallowed by some

policies (e.g., CAs may be the only entities permitted to verify POP

during certification).

2.3.1 Signature Keys

For signature keys, the end entity can sign a value to prove

possession of the private key.

2.3.2 Encryption Keys

For encryption keys, the end entity can provide the private key to

the CA/RA, or can be required to decrypt a value in order to prove

possession of the private key (see Section 3.2.8). Decrypting a value

can be achieved either directly or indirectly.

The direct method is for the RA/CA to issue a random challenge to

which an immediate response by the EE is required.

The indirect method is to issue a certificate which is encrypted for

the end entity (and have the end entity demonstrate its ability to

decrypt this certificate in the confirmation message). This allows a

CA to issue a certificate in a form which can only be used by the

intended end entity.

This specification encourages use of the indirect method because this

requires no extra messages to be sent (i.e., the proof can be

demonstrated using the {request, response, confirmation} triple of

messages).

Adams & Farrell Standards Track [Page 14]

RFC 2510 PKI Certificate Management Protocols March 1999

2.3.3 Key Agreement Keys

For key agreement keys, the end entity and the PKI management entity

(i.e., CA or RA) must establish a shared secret key in order to prove

that the end entity has possession of the private key.

Note that this need not impose any restrictions on the keys that can

be certified by a given CA -- in particular, for Diffie-Hellman keys

the end entity may freely choose its algorithm parameters -- provided

that the CA can generate a short-term (or one-time) key pair with the

appropriate parameters when necessary.

2.4 Root CA key update

This discussion only applies to CAs that are a root CA for some end

entity.

The basis of the procedure described here is that the CA protects its

new public key using its previous private key and vice versa. Thus

when a CA updates its key pair it must generate two extra

cACertificate attribute values if certificates are made available

using an X.500 directory (for a total of four: OldWithOld;

OldWithNew; NewWithOld; and NewWithNew).

When a CA changes its key pair those entities who have acquired the

old CA public key via "out-of-band" means are most affected. It is

these end entities who will need access to the new CA public key

protected with the old CA private key. However, they will only

require this for a limited period (until they have acquired the new

CA public key via the "out-of-band" mechanism). This will typically

be easily achieved when these end entities’ certificates expire.

The data structure used to protect the new and old CA public keys is

a standard certificate (which may also contain extensions). There are

no new data structures required.

Note 1. This scheme does not make use of any of the X.509 v3

extensions as it must be able to work even for version 1

certificates. The presence of the KeyIdentifier extension would make

for efficiency improvements.

Note 2. While the scheme could be generalized to cover cases where

the CA updates its key pair more than once during the validity period

of one of its end entities’ certificates, this generalization seems

of dubious value. Not having this generalization simply means that

the validity period of a CA key pair must be greater than the

validity period of any certificate issued by that CA using that key

pair.

Adams & Farrell Standards Track [Page 15]

剩余71页未读，继续阅读

cryptoguo

粉丝: 0
资源: 1

RFC 2510：X.509公钥基础设施证书管理协议详解

RFC中文文档大全.zip_RFC中文文档_RFC开发文档_rfc 中文_rfc1155中文文档_rfc文档中文版

RFC文档RFC文档RFC文档RFC文档

rfc全部文档离线下载rfc1-rfc8505

rfc9000文档下载

ipv6 rfc相关文档

rfc 文档大全 下载

XML标准和RFC官方文档

rfc文档1一3093

rdp8.0协议 rfc文档

lacp的rfc文档

最新资源

rfc 文档大全下载