Network Working Group S. Dusse
Request for Comments: 2312 RSA Data Security
Category: Informational P. Hoffman
Internet Mail Consortium
B. Ramsdell
Worldtalk
J. Weinstein
Netscape
March 1998
Network Working Group S. Dusse
Request for Comments: 2312 RSA Data Security
Category: Informational P. Hoffman
Internet Mail Consortium
B. Ramsdell
Worldtalk
J. Weinstein
Netscape
March 1998
S/MIME Version 2 Certificate Handling
S/MIME版本2证书处理
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], provides a method to send and receive secure MIME messages. In order to validate the keys of a message sent to it, an S/MIME agent needs to certify that the key is valid. This memo describes the mechanisms S/MIME uses to create and validate keys using certificates.
[SMIME-MSG]中描述的S/MIME（安全/多用途Internet邮件扩展）提供了发送和接收安全MIME消息的方法。为了验证发送给它的消息的密钥，S/MIME代理需要验证密钥是否有效。本备忘录描述了S/MIME使用证书创建和验证密钥的机制。
This specification is compatible with PKCS #7 in that it uses the data types defined by PKCS #7. It also inherits all the varieties of architectures for certificate-based key management supported by PKCS #7. Note that the method S/MIME messages make certificate requests is defined in [SMIME-MSG].
本规范与PKCS#7兼容，因为它使用PKCS#7定义的数据类型。它还继承了PKCS#7支持的所有基于证书的密钥管理体系结构。请注意，[SMIME-MSG]中定义了S/MIME消息发出证书请求的方法。
In order to handle S/MIME certificates, an agent has to follow specifications in this memo, as well as some of the specifications listed in the following documents:
为了处理S/MIME证书，代理必须遵循本备忘录中的规范以及以下文档中列出的一些规范：
- "PKCS #1: RSA Encryption", [PKCS-1]. - "PKCS #7: Cryptographic Message Syntax", [PKCS-7] - "PKCS #10: Certification Request Syntax", [PKCS-10].
- “PKCS#1:RSA加密”，[PKCS-1]。-“PKCS#7：加密消息语法”，[PKCS-7]-“PKCS#10：认证请求语法”，[PKCS-10]。
Please note: The information in this document is historical material being published for the public record. It is not an IETF standard. The use of the word "standard" in this document indicates a standard for adopters of S/MIME version 2, not an IETF standard.
请注意：本文件中的信息是公开记录的历史资料。它不是IETF标准。本文件中使用“标准”一词表示S/MIME版本2采用者的标准，而不是IETF标准。
For the purposes of this memo, the following definitions apply.
在本备忘录中，以下定义适用。
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208.
ASN.1：抽象语法符号1，如CCITT X.208中所定义。
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209.
BER：ASN.1的基本编码规则，如CCITT X.209中所定义。
Certificate: A type that binds an entity's distinguished name to a public key with a digital signature. This type is defined in CCITT X.509 [X.509]. This type also contains the distinguished name of the certificate issuer (the signer), an issuer-specific serial number, the issuer's signature algorithm identifier, and a validity period.
证书：用数字签名将实体的可分辨名称绑定到公钥的类型。该类型在CCITT X.509[X.509]中定义。此类型还包含证书颁发者（签名者）的可分辨名称、特定于颁发者的序列号、颁发者的签名算法标识符和有效期。
Certificate Revocation List (CRL): A type that contains information about certificates whose validity an issuer has prematurely revoked. The information consists of an issuer name, the time of issue, the next scheduled time of issue, and a list of certificate serial numbers and their associated revocation times. The CRL is signed by the issuer. The type intended by this specification is the one defined in [KEYM].
证书吊销列表（CRL）：一种类型，其中包含有关颁发者已提前吊销其有效性的证书的信息。该信息包括颁发者名称、颁发时间、下一个计划颁发时间、证书序列号及其相关撤销时间的列表。CRL由发行人签署。本规范规定的类型为[KEYM]中定义的类型。
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.509.
DER：ASN.1的特殊编码规则，如CCITT X.509中所定义。
Appendix C contains important information about how S/MIME agents following this specification should act in order to have the greatest interoperability with earlier implementations of S/MIME.
附录C包含有关遵循本规范的S/MIME代理应如何操作的重要信息，以便与早期的S/MIME实现具有最大的互操作性。
Throughout this memo, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are used in capital letters. This conforms to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this document to help implementors achieve interoperability.
在本备忘录中，术语必须、不得、应当和不应当以大写字母使用。这符合[必须]中的定义。[MUSTSHOULD]定义这些关键词的用法，以帮助尽可能清楚地表达标准跟踪文件的意图。本文档中使用了相同的关键词来帮助实现者实现互操作性。
The PKCS #7 message format allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. Most of the PKCS #7 format for S/MIME messages is defined in [SMIME-MSG].
PKCS#7消息格式允许在内容和算法支持方面提供多种选择。本节提出了一些支持需求和建议，以实现所有S/MIME实现之间的基本互操作性。大多数S/MIME消息的PKCS#7格式在[SMIME-MSG]中定义。
Receiving agents MUST support for the Certificate Revocation List (CRL) format defined in [KEYM]. If sending agents include CRLs in outgoing messages, the CRL format defined in [KEYM] MUST be used.
接收代理必须支持[KEYM]中定义的证书吊销列表（CRL）格式。如果发送代理在传出消息中包含CRL，则必须使用[KEYM]中定义的CRL格式。
All agents MUST validate CRLs and check certificates against CRLs, if available, in accordance with [KEYM]. All agents SHOULD check the nextUpdate field in the CRL against the current time. If the current time is later than the nextUpdate time, the action that the agent takes is a local decision. For instance, it could warn a human user, it could retrieve a new CRL if able, and so on.
所有代理必须根据[KEYM]验证CRL，并根据CRL检查证书（如果可用）。所有代理都应根据当前时间检查CRL中的nextUpdate字段。如果当前时间晚于nextUpdate时间，则代理采取的操作是本地决定。例如，它可以警告人类用户，如果可以，它可以检索新的CRL，等等。
Receiving agents MUST recognize CRLs in received S/MIME messages.
接收代理必须识别接收到的S/MIME消息中的CRL。
Clients MUST use revocation information included as a CRL in an S/MIME message when verifying the signature and certificate path validity in that message. Clients SHOULD store CRLs received in messages for use in processing later messages.
在验证S/MIME消息中的签名和证书路径有效性时，客户端必须使用S/MIME消息中作为CRL包含的吊销信息。客户端应存储在消息中接收的CRL，以便在以后处理消息时使用。
Clients MUST handle multiple valid Certificate Authority (CA) certificates containing the same subject name and the same public keys but with overlapping validity intervals.
客户端必须处理多个有效的证书颁发机构（CA）证书，这些证书包含相同的使用者名称和相同的公钥，但有效期间隔重叠。
Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See [KEYM] for details about the profile for certificate formats. End entity certificates MUST include an Internet mail address, as described in section 3.1.
接收代理必须支持X.509 v1和X.509 v3证书。有关证书格式配置文件的详细信息，请参阅[KEYM]。终端实体证书必须包括Internet邮件地址，如第3.1节所述。
The PKCS #7 message format supports a choice of certificate two formats for public key content types: X.509 and PKCS #6 Extended Certificates. The PKCS #6 format is not in widespread use. In addition, proposed revisions of X.509 certificates address much of the same functionality and flexibility as was intended in the PKCS #6. Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificates.
PKCS#7消息格式支持对公钥内容类型选择两种证书格式：X.509和PKCS#6扩展证书。PKCS#6格式没有得到广泛使用。此外，X.509证书的拟议修订版解决了与PKCS#6中预期相同的功能和灵活性。因此，发送和接收代理不得使用PKCS#6扩展证书。
Receiving agents MUST be able to handle an arbitrary number of certificates of arbitrary relationship to the message sender and to each other in arbitrary order. In many cases, the certificates included in a signed message may represent a chain of certification from the sender to a particular root. There may be, however, situations where the certificates in a signed message may be unrelated and included for convenience.
接收代理必须能够处理任意数量的证书，这些证书与消息发送方以及彼此之间的关系是任意的。在许多情况下，签名消息中包含的证书可能表示从发送方到特定根的证书链。然而，可能存在这样的情况，即签名消息中的证书可能是无关的，并且为了方便而包括在内。
Sending agents SHOULD include any certificates for the user's public key(s) and associated issuer certificates. This increases the likelihood that the intended recipient can establish trust in the originator's public key(s). This is especially important when sending a message to recipients that may not have access to the sender's public key through any other means or when sending a signed message to a new recipient. The inclusion of certificates in outgoing messages can be omitted if S/MIME objects are sent within a group of correspondents that has established access to each other's certificates by some other means such as a shared directory or manual certificate distribution. Receiving S/MIME agents SHOULD be able to handle messages without certificates using a database or directory lookup scheme.
发送代理应包括用户公钥和相关颁发者证书的任何证书。这增加了预期接收者对发端人公钥建立信任的可能性。当向可能无法通过任何其他方式访问发件人公钥的收件人发送邮件或向新收件人发送签名邮件时，这一点尤为重要。如果S/MIME对象是在通过共享目录或手动证书分发等其他方式建立了对彼此证书的访问权限的通信者组中发送的，则可以省略在传出消息中包含证书。接收S/MIME代理应该能够使用数据库或目录查找方案处理没有证书的消息。
A sending agent SHOULD include at least one chain of certificates up to, but not including, a Certificate Authority (CA) that it believes that the recipient may trust as authoritative. A receiving agent SHOULD be able to handle an arbitrarily large number of certificates and chains.
发送代理应包括至少一个证书链，该证书链最多包括但不包括它认为接收方可以信任为权威的证书颁发机构（CA）。接收代理应该能够处理任意数量的证书和链。
Clients MAY send CA certificates, that is, certificates that are self-signed and can be considered the "root" of other chains. Note that receiving agents SHOULD NOT simply trust any self-signed certificates as valid CAs, but SHOULD use some other mechanism to determine if this is a CA that should be trusted.
客户端可以发送CA证书，即自签名的证书，可以被视为其他链的“根”。请注意，接收代理不应该简单地将任何自签名证书作为有效CA来信任，而应该使用其他机制来确定这是否是一个应该信任的CA。
Receiving agents MUST support chaining based on the distinguished name fields. Other methods of building certificate chains may be supported but are not currently recommended.
接收代理必须支持基于可分辨名称字段的链接。可能支持构建证书链的其他方法，但目前不推荐使用。
The format of an X.509 certificate includes fields for the subject name and issuer name. The subject name identifies the owner of a particular public key/private key pair while the issuer name is meant to identify the entity that "certified" the subject (that is, who signed the subject's certificate). The subject name and issuer name are defined by X.509 as Distinguished Names.
X.509证书的格式包括主题名称和颁发者名称字段。主体名称标识特定公钥/私钥对的所有者，而颁发者名称旨在标识“认证”主体的实体（即签署主体证书的实体）。主题名称和发行人名称由X.509定义为可分辨名称。
Distinguished Names are defined by a CCITT standard X.501 [X.501]. A Distinguished Name is broken into one or more Relative Distinguished Names. Each Relative Distinguished Name is comprised of one or more Attribute-Value Assertions. Each Attribute-Value Assertion consists of a Attribute Identifier and its corresponding value information, such as CountryName=US. Distinguished Names were intended to identify entities in the X.500 directory tree [X.500]. Each Relative Distinguished Name can be thought of as a node in the tree which is described by some collection of Attribute-Value Assertions. The entire Distinguished Name is some collection of nodes in the tree that traverse a path from the root of the tree to some end node which represents a particular entity.
可分辨名称由CCITT标准X.501[X.501]定义。可分辨名称分为一个或多个相对可分辨名称。每个相对可分辨名称由一个或多个属性值断言组成。每个属性值断言都包含一个属性标识符及其相应的值信息，例如CountryName=US。可分辨名称用于识别X.500目录树[X.500]中的实体。每个相对的可分辨名称都可以看作是树中的一个节点，由一些属性值断言集合描述。整个可分辨名称是树中的一些节点集合，这些节点遍历从树的根到表示特定实体的某个结束节点的路径。
The goal of the directory was to provide an infrastructure to uniquely name every communications entity everywhere. However, adoption of a global X.500 directory infrastructure has been slower than expected. Consequently, there is no requirement for X.500 directory service provision in the S/MIME environment, although such provision would almost undoubtedly be of great value in facilitating key management for S/MIME.
该目录的目标是提供一个基础设施，以便在任何地方对每个通信实体进行唯一命名。然而，采用全球X.500目录基础设施的速度比预期慢。因此，在S/MIME环境中不需要提供X.500目录服务，尽管这样的服务在促进S/MIME的密钥管理方面几乎毫无疑问是非常有价值的。
The use of Distinguished Names in accordance with the X.500 directory is not very widespread. By contrast, Internet mail addresses, as described in RFC 822 [RFC-822], are used almost exclusively in the Internet environment to identify originators and recipients of messages. However, Internet mail addresses bear no resemblance to X.500 Distinguished Names (except, perhaps, that they are both hierarchical in nature). Some method is needed to map Internet mail addresses to entities that hold public keys. Some people have
按照X.500目录使用可分辨名称的情况并不十分普遍。相比之下，如RFC 822[RFC-822]所述，互联网邮件地址几乎完全用于互联网环境中，以识别消息的发起者和接收者。但是，Internet邮件地址与X.500可分辨名称没有任何相似之处（也许除了它们在本质上都是分层的）。需要某种方法将Internet邮件地址映射到持有公钥的实体。有些人有
suggested that the X.509 certificate format should be abandoned in favor of other binding mechanisms. Instead, S/MIME keeps the X.509 certificate and Distinguished Name mechanisms while tailoring the content of the naming information to suit the Internet mail environment.
建议放弃X.509证书格式，转而使用其他绑定机制。相反，S/MIME保留X.509证书和可分辨名称机制，同时根据Internet邮件环境调整命名信息的内容。
End-entity certificates MUST contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of that specification.
终端实体证书必须包含[RFC-822]中所述的Internet邮件地址。地址必须是该规范第6.1节中定义的“地址规范”。
Receiving agents MUST recognize email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field.
接收代理必须识别subjectAltName字段中的电子邮件地址。接收代理必须识别可分辨名称字段中的电子邮件地址。
Sending agents SHOULD make the address in the From header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MUST check that the address in the From header of a mail message matches an Internet mail address in the signer's certificate. A receiving agent MUST provide some explicit alternate processing of the message if this comparison fails, which may be to reject the message.
发送代理应使邮件消息的发件人标头中的地址与签名者证书中的Internet邮件地址匹配。接收代理必须检查邮件消息的发件人标头中的地址是否与签名者证书中的Internet邮件地址匹配。如果此比较失败，则接收代理必须提供一些明确的消息替代处理，这可能是拒绝消息。
Receiving agents MUST support parsing of zero, one, or more instances of each of the following set of name attributes within the Distinguished Names in certificates.
接收代理必须支持在证书中的可分辨名称中解析以下每一组名称属性的零个、一个或多个实例。
Sending agents MUST include the Internet mail address during Distinguished Name creation. Guidelines for the inclusion, omission, and ordering of the remaining name attributes during the creation of a distinguished name will most likely be dictated by the policies associated with the certification service which will certify the corresponding name and public key.
在创建可分辨名称期间，发送代理必须包括Internet邮件地址。在创建可分辨名称期间，其余名称属性的包含、省略和排序指南很可能由与认证服务相关联的策略决定，该服务将认证相应的名称和公钥。
CountryName StateOrProvinceName Locality CommonName Title Organization OrganizationalUnit StreetAddress PostalCode PhoneNumber EmailAddress
CountryName州或省名地区CommonName头衔组织机构单位街道地址邮编电话号码电子邮件地址
All attributes other than EmailAddress are described in X.520 [X.520]. EmailAddress is an IA5String that can have multiple attribute values.
X.520[X.520]中描述了除EmailAddress之外的所有属性。EmailAddress是可以具有多个属性值的IA5String。
A receiving agent needs to provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. There are many ways to implement certificate retrieval mechanisms. X.500 directory service is an excellent example of a certificate retrieval-only mechanism that is compatible with classic X.500 Distinguished Names. The PKIX Working Group is investigating other mechanisms. Another method under consideration by the IETF is to provide certificate retrieval services as part of the existing Domain Name System (DNS). Until such mechanisms are widely used, their utility may be limited by the small number of correspondent's certificates that can be retrieved. At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message.
接收代理需要提供一些证书检索机制，以便为数字信封的收件人访问证书。有许多方法可以实现证书检索机制。X.500目录服务是与经典的X.500可分辨名称兼容的仅证书检索机制的一个极好示例。PKIX工作组正在调查其他机制。IETF正在考虑的另一种方法是作为现有域名系统（DNS）的一部分提供证书检索服务。在这些机制被广泛使用之前，它们的实用性可能会受到可检索的少量通信者证书的限制。对于初始S/MIME部署，用户代理至少可以自动生成一条消息，发送给指定的收件人，在签名的返回消息中请求该收件人的证书。
Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval. In many environments, it may be desirable to link the certificate retrieval/storage mechanisms together in some sort of certificate database. In its simplest form, a certificate database would be local to a particular user and would function in a similar way as a "address book" that stores a user's frequent correspondents. In this way, the certificate retrieval mechanism would be limited to the certificates that a user has stored (presumably from incoming messages). A comprehensive certificate retrieval/storage solution may combine two or more mechanisms to allow the greatest flexibility and utility to the user. For instance, a secure Internet mail agent may resort to checking a centralized certificate retrieval mechanism for a certificate if it can not be found in a user's local certificate storage/retrieval database.
接收和发送代理还应提供一种机制，允许用户以这种方式“存储和保护”通信员的证书，以保证其以后的检索。在许多环境中，可能需要在某种证书数据库中将证书检索/存储机制链接在一起。最简单的形式是，证书数据库是特定用户的本地数据库，其功能类似于存储用户频繁通信者的“地址簿”。这样，证书检索机制将限于用户存储的证书（可能来自传入消息）。一个全面的证书检索/存储解决方案可以结合两种或两种以上的机制，以便为用户提供最大的灵活性和实用性。例如，如果在用户的本地证书存储/检索数据库中找不到证书，安全Internet邮件代理可能会求助于检查集中式证书检索机制以获取证书。
Receiving and sending agents SHOULD provide a mechanism for the import and export of certificates, using a PKCS #7 certs-only message. This allows for import and export of full certificate chains as opposed to just a single certificate. This is described in [SMIME-MSG].
接收和发送代理应使用PKCS#7 certs only消息提供证书导入和导出机制。这允许导入和导出完整的证书链，而不仅仅是单个证书。这在[SMIME-MSG]中有描述。
A receiving agent SHOULD have access to some certificate-revocation list (CRL) retrieval mechanism in order to gain access to certificate-revocation information when validating certificate chains. A receiving or sending agent SHOULD also provide a mechanism to allow a user to store incoming certificate-revocation information for correspondents in such a way so as to guarantee its later retrieval. However, it is always better to get the latest information from the CA than to get information stored away from incoming messages.
接收代理应该可以访问某些证书吊销列表（CRL）检索机制，以便在验证证书链时访问证书吊销信息。接收或发送代理还应提供一种机制，允许用户以这种方式为通信方存储传入的证书撤销信息，以保证其以后的检索。但是，从CA获取最新信息总比从传入消息中获取存储的信息要好。
Receiving and sending agents SHOULD retrieve and utilize CRL information every time a certificate is verified as part of a certificate chain validation even if the certificate was already verified in the past. However, in many instances (such as off-line verification) access to the latest CRL information may be difficult or impossible. The use of CRL information, therefore, may be dictated by the value of the information that is protected. The value of the CRL information in a particular context is beyond the scope of this memo but may be governed by the policies associated with particular certificate hierarchies.
接收和发送代理应在每次证书作为证书链验证的一部分进行验证时检索和利用CRL信息，即使该证书在过去已经过验证。然而，在许多情况下（如离线验证），访问最新的CRL信息可能很困难或不可能。因此，CRL信息的使用可能由受保护信息的价值决定。特定上下文中CRL信息的值超出了本备忘录的范围，但可能受与特定证书层次结构相关联的策略管辖。
In creating a user agent for secure messaging, certificate, CRL, and certificate chain validation SHOULD be highly automated while still acting in the best interests of the user. Certificate, CRL, and chain validation MUST be performed when validating a correspondent's public key. This is necessary when a) verifying a signature from a correspondent and, b) creating a digital envelope with the correspondent as the intended recipient.
在创建用于安全消息传递的用户代理时，证书、CRL和证书链验证应该高度自动化，同时仍然符合用户的最佳利益。验证通讯者的公钥时，必须执行证书、CRL和链验证。当a）验证通讯员的签名和b）以通讯员作为预期收件人创建数字信封时，这是必要的。
Certificates and CRLs are made available to the chain validation procedure in two ways: a) incoming messages, and b) certificate and CRL retrieval mechanisms. Certificates and CRLs in incoming messages are not required to be in any particular order nor are they required to be in any way related to the sender or recipient of the message (although in most cases they will be related to the sender). Incoming certificates and CRLs SHOULD be cached for use in chain validation and optionally stored for later use. This temporary certificate and CRL cache SHOULD be used to augment any other certificate and CRL retrieval mechanisms for chain validation on incoming signed messages.
证书和CRL以两种方式提供给链验证过程：a）传入消息，b）证书和CRL检索机制。传入邮件中的证书和CRL不需要按任何特定顺序排列，也不需要以任何方式与邮件的发件人或收件人相关（尽管在大多数情况下，它们将与发件人相关）。传入的证书和CRL应缓存以用于链验证，并可选择存储以供以后使用。此临时证书和CRL缓存应用于增强任何其他证书和CRL检索机制，以便对传入的签名消息进行链验证。
Certificates and Certificate-Revocation Lists (CRLs) are signed by the certificate issuer. A receiving agent MUST be capable of verifying the signatures on certificates andCRLs made with md5WithRSAEncryption and sha-1WithRSAEncryption signature algorithms with key sizes from 512 bits to 2048 bits described in [SMIME-MSG]. A receiving agent SHOULD be capable of verifying the signatures on certificates and CRLs made with the md2WithRSAEncryption signature algorithm with key sizes from 512 bits to 2048 bits.
证书和证书吊销列表（CRL）由证书颁发者签名。接收代理必须能够验证证书和CRL上的签名，这些证书和CRL采用MD5WithRSAEncyption和sha-1WithRSAEncyption签名算法，密钥大小为512位到2048位，如[SMIME-MSG]所述。接收代理应该能够验证使用MD2WithRSA加密签名算法生成的证书和CRL上的签名，密钥大小从512位到2048位。
The X.509 v3 standard describes an extensible framework in which the basic certificate information can be extended and how such extensions can be used to control the process of issuing and validating certificates. The PKIX Working Group has ongoing efforts to identify and create extensions which have value in particular certification environments. As such, there is still a fair amount of profiling work to be done before there is widespread agreement on which v3 extensions will be used. Further, there are active efforts underway to issue X.509 v3 certificates for business purposes. This memo identifies the minumum required set of certificate extensions which have the greatest value in the S/MIME environment. The basicConstraints, and keyUsage extensions are defined in [X.509].
X.509 v3标准描述了一个可扩展的框架，其中可以扩展基本证书信息，以及如何使用这些扩展来控制证书的颁发和验证过程。PKIX工作组正在努力确定和创建在特定认证环境中具有价值的扩展。因此，在就使用哪种v3扩展达成广泛一致之前，仍有大量的评测工作要做。此外，正在积极努力为商业目的颁发X.509 v3证书。此备忘录确定了在S/MIME环境中具有最大价值的所需最小证书扩展集。[X.509]中定义了基本约束和键用法扩展。
Sending and receiving agents MUST correctly handle the v3 Basic Constraints Certificate Extension, the Key Usage Certificate Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when they appear in end-user certificates. Some mechanism SHOULD exist to handle the defined v3 certificate extensions when they appear in intermediate or CA certificates.
当v3基本约束证书扩展、密钥使用证书扩展、authorityKeyID、subjectKeyID和SubjectAltName出现在最终用户证书中时，发送和接收代理必须正确处理它们。当定义的v3证书扩展出现在中间证书或CA证书中时，应该存在一些机制来处理这些扩展。
Certificates issued for the S/MIME environment SHOULD NOT contain any critical extensions other than those listed here. These extensions SHOULD be marked as non-critical unless the proper handling of the extension is deemed critical to the correct interpretation of the associated certificate. Other extensions may be included, but those extensions SHOULD NOT be marked as critical.
为S/MIME环境颁发的证书不应包含此处列出的扩展以外的任何关键扩展。这些扩展应标记为非关键扩展，除非正确处理扩展对相关证书的正确解释至关重要。可以包括其他扩展，但不应将这些扩展标记为关键扩展。
The basic constraints extension serves to delimit the role and position of an issuing authority or end-user certificate plays in a chain of certificates.
基本约束扩展用于界定颁发机构或最终用户证书在证书链中的角色和位置。
For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as issuing authority certificates. End-user subscriber certificates contain an extension that constrains the certificate from being an issuing authority certificate.
例如，颁发给CA和下级CA的证书包含一个基本约束扩展，该扩展将它们标识为颁发机构证书。最终用户订阅者证书包含一个扩展，该扩展限制证书为颁发机构证书。
Certificates SHOULD contain a basicContstraints extension.
证书应包含BasicCountStraints扩展。
The key usage extension serves to limit the technical purposes for which a public key listed in a valid certificate may be used. Issuing authority certificates may contain a key usage extension that restricts the key to signing certificates, certificate revocation lists and other data.
密钥使用扩展用于限制有效证书中列出的公钥可用于的技术目的。颁发机构证书可能包含密钥使用扩展，该扩展将密钥限制为签名证书、证书吊销列表和其他数据。
For example, a certification authority may create subordinate issuer certificates which contain a keyUsage extension which specifies that the corresponding public key can be used to sign end user certs and sign CRLs.
例如，证书颁发机构可以创建从属颁发者证书，该证书包含密钥使用扩展，该扩展指定相应的公钥可用于签署最终用户证书和签署CRL。
An S/MIME agent or some related administrative utility or function MUST be capable of generating a certification request given a user's public key and associated name information. In most cases, the user's public key/private key pair will be generated simultaneously. However, there are cases where the keying information may be generated by an external process (such as when a key pair is generated on a cryptographic token or by a "key recovery" service).
S/MIME代理或某些相关管理实用程序或函数必须能够在给定用户公钥和相关名称信息的情况下生成认证请求。在大多数情况下，将同时生成用户的公钥/私钥对。然而，在某些情况下，键控信息可以由外部进程生成（例如，当在加密令牌上生成密钥对或通过“密钥恢复”服务生成密钥对时）。
There SHOULD NOT be multiple valid (that is, non-expired and non-revoked) certificates for the same key pair bound to different Distinguished Names. Otherwise, a security flaw exists where an attacker can substitute one valid certificate for another in such a way that can not be detected by a message recipient. If a users wishes to change their name (or create an alternate name), the user agent SHOULD generate a new key pair. If the user wishes to reuse an existing key pair with a new or alternate name, the user SHOULD first have any valid certificates for the existing public key revoked.
绑定到不同可分辨名称的同一密钥对不应有多个有效（即未过期和未吊销）证书。否则，存在一个安全漏洞，攻击者可以用一个有效证书替换另一个有效证书，从而使邮件收件人无法检测到该漏洞。如果用户希望更改其名称（或创建备用名称），则用户代理应生成新的密钥对。如果用户希望使用新名称或备用名称重用现有密钥对，则应首先吊销现有公钥的任何有效证书。
In general, it is possible for a user to request certification for the same name and different public key from the same or different certification authorities. This is acceptable both for end-entity and issuer certificates and can be useful in supporting a change of issuer keys in a smooth fashion.
一般来说，用户可以从相同或不同的认证机构申请相同名称和不同公钥的认证。这对于终端实体和颁发者证书都是可接受的，并且有助于支持以平滑方式更改颁发者密钥。
CAs that re-use their own name with distinct keys MUST include the AuthorityKeyIdentifier extension in certificates that they issue, and MUST have the SubjectKeyIdentifier extension in their own certificate. CAs SHOULD use these extensions uniformly.
使用不同密钥重复使用自己名称的CA必须在其颁发的证书中包含AuthorityKeyIdentifier扩展，并且必须在其自己的证书中包含SubjectKeyIdentifier扩展。CA应该统一使用这些扩展。
Clients SHOULD handle multiple valid CA certificates that certify different public keys but contain the same subject name (in this case, that CA's name).
客户端应该处理多个有效的CA证书，这些证书认证不同的公钥，但包含相同的使用者名称（在本例中为该CA的名称）。
When selecting an appropriate issuer's certificate to use to verify a given certificate, clients SHOULD process the AuthorityKeyIdentifier and SubjectKeyIdentifier extensions.
选择用于验证给定证书的适当颁发者证书时，客户端应处理AuthorityKeyIdentifier和SubjectKeyIdentifier扩展。
5.2 Using PKCS #10 for Certification Requests
5.2 使用PKCS#10进行认证请求
PKCS #10 is a flexible and extensible message format for representing the results of cryptographic operations on some data. The choice of naming information is largely dictated by the policies and procedures associated with the intended certification service.
PKCS#10是一种灵活且可扩展的消息格式，用于表示某些数据上加密操作的结果。命名信息的选择在很大程度上取决于与预期认证服务相关的策略和程序。
In addition to key and naming information, the PKCS #10 format supports the inclusion of optional attributes, signed by the entity requesting certification. This allows for information to be conveyed in a certification request which may be useful to the request process, but not necessarily part of the Distinguished Name being certified.
除了密钥和命名信息外，PKCS#10格式还支持包含可选属性，由请求认证的实体签名。这允许在认证请求中传递信息，该信息可能对请求过程有用，但不一定是认证的专有名称的一部分。
Receiving agents MUST support the identification of an RSA key with the rsa defined in X.509 and the rsaEncryption OID. Certification authorities MUST support sha-1WithRSAEncryption and md5WithRSAEncryption and SHOULD support MD2WithRSAEncryption for verification of signatures on certificate requests as described in [SMIME-MSG].
接收代理必须支持使用X.509中定义的RSA和RSAOID加密标识RSA密钥。证书颁发机构必须支持sha-1WithRSAEncyption和MD5WithRSAEncyption，并应支持MD2WithRSAEncyption以验证[SMIME-MSG]中所述的证书请求签名。
For the creation and submission of certification-requests, RSA keys SHOULD be identified with the rsaEncryption OID and signed with the sha-1WithRSAEncryption signature algorithm. Certification-requests MUST NOT be signed with the md2WithRSAEncryption signature algorithm.
对于创建和提交认证请求，RSA密钥应使用RSA加密OID进行标识，并使用sha-1WithRSA加密签名算法进行签名。证书请求不得使用MD2WithRSA加密签名算法签名。
Certification requests MUST include a valid Internet mail address, either as part of the certificate (as described in 3.2) or as part of the PKCS #10 attribute list. Certification authorities MUST check that the address in the "From:" header matches either of these addresses. CAs SHOULD allow the CA operator to configure processing of messages whose addresses do not match.
认证请求必须包含有效的Internet邮件地址，作为证书的一部分（如3.2所述）或PKCS#10属性列表的一部分。证书颁发机构必须检查“发件人：”标头中的地址是否与这些地址中的任何一个匹配。CA应允许CA操作员配置对地址不匹配的消息的处理。
Certification authorities SHOULD support parsing of zero or one instance of each of the following set of certification-request attributes on incoming messages. Attributes that a particular implementation does not support may generate a warning message to the requestor, or may be silently ignored. Inclusion of the following attributes during the creation and submission of a certification-request will most likely be dictated by the policies associated with the certification service which will certify the corresponding name and public key.
证书颁发机构应支持对传入消息上的以下每一组证书请求属性的零个或一个实例进行解析。特定实现不支持的属性可能会向请求者生成警告消息，或者可能会被默默忽略。在创建和提交认证请求期间包含以下属性很可能由与认证服务相关联的策略决定，认证服务将认证相应的名称和公钥。
postalAddress challengePassword unstructuredAddress
Postladdress challengePassword非结构化地址
postalAddress is described in [X.520].
[X.520]中描述了邮资。
The challenge-password attribute type specifies a password by which an entity may request certificate revocation. The interpretation of the password is intended to be specified by the issuer of the certificate; no particular interpretation is required. The challenge-password attribute type is intended for PKCS #10 certification requests.
质询密码属性类型指定实体可以请求证书吊销的密码。密码的解释由证书颁发者指定；不需要特别解释。质询密码属性类型适用于PKCS#10认证请求。
Challenge-password attribute values have ASN.1 type ChallengePassword:
质询密码属性值具有ASN.1类型的质询密码：
ChallengePassword ::= CHOICE {
PrintableString, T61String }
ChallengePassword ::= CHOICE {
PrintableString, T61String }
A challenge-password attribute must have a single attribute value.
质询密码属性必须具有单个属性值。
It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL STRING), ChallengePassword will become a CHOICE type:
预计如果UCS成为ASN.1类型（例如，通用字符串），ChallengePassword将成为选择类型：
ChallengePassword ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
ChallengePassword ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
The unstructured-address attribute type specifies the address or addresses of the subject of a certificate as an unstructured ASCII or T.61 string. The interpretation of the addresses is intended to be specified by the issuer of the certificate; no particular interpretation is required. A likely interpretation is as an alternative to the X.520 postalAddress attribute type. The unstructured-address attribute type is intended for PKCS #10
非结构化地址属性类型将证书主题的地址指定为非结构化ASCII或T.61字符串。地址的解释由证书颁发者指定；不需要特别解释。一种可能的解释是作为X.520 PostLaddress属性类型的替代。非结构化地址属性类型适用于PKCS#10
certification requests.
认证请求。
Unstructured-address attribute values have ASN.1 type UnstructuredAddress:
非结构化地址属性值具有ASN.1类型的非结构化地址：
UnstructuredAddress ::= CHOICE {
PrintableString, T61String }
UnstructuredAddress ::= CHOICE {
PrintableString, T61String }
An unstructured-address attribute can have multiple attribute values.
非结构化地址属性可以有多个属性值。
Note: T.61's newline character (hexadecimal code 0d) is recommended as a line separator in multi-line addresses.
注意：建议在多行地址中使用T.61的换行符（十六进制代码0d）作为行分隔符。
It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL STRING), UnstructuredAddress will become a CHOICE type:
如果UCS成为ASN.1类型（例如，通用字符串），则非结构化地址将成为一种选择类型：
UnstructuredAddress ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
UnstructuredAddress ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
Certification authorities SHOULD use the sha-1WithRSAEncryption signature algorithms when signing certificates.
证书颁发机构在签署证书时应使用sha-1WITHRSA加密签名算法。
[PKCS-7] supports a degenerate case of the SignedData content type where there are no signers on the content (and hence, the content value is "irrelevant"). This degenerate case is used to convey certificate and CRL information. Certification authorities MUST use this format for returning certificate information resulting from the successful fulfillment of a certification request. At a minimum, the fulfilled certificate response MUST include the actual subject certificate (corresponding to the information in the certification request). The response SHOULD include other certificates which link the issuer to higher level certification authorities and corresponding certificate-revocation lists. Unrelated certificates and revocation information is also acceptable.
[PKCS-7]支持SignedData内容类型的退化情况，其中内容上没有签名者（因此，内容值是“无关的”）。这种退化情况用于传递证书和CRL信息。认证机构必须使用此格式返回成功完成认证请求后产生的证书信息。至少，完成的证书响应必须包括实际的主体证书（对应于认证请求中的信息）。响应应包括将颁发者链接到更高级别的认证机构的其他证书以及相应的证书撤销列表。也可以接受不相关的证书和撤销信息。
Receiving agents MUST parse this degenerate PKCS #7 message type and handle the certificates and CRLs according to the requirements and recommendations in Section 4.
接收代理必须解析此退化PKCS#7消息类型，并根据第4节中的要求和建议处理证书和CRL。
All of the security issues faced by any cryptographic application must be faced by a S/MIME agent. Among these issues are protecting the user's private key, preventing various attacks, and helping the user avoid mistakes such as inadvertently encrypting a message for the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant concerns are listed here.
任何加密应用程序所面临的所有安全问题都必须由S/MIME代理来解决。这些问题包括保护用户的私钥、防止各种攻击以及帮助用户避免错误，例如无意中为错误的收件人加密消息。整个安全注意事项列表超出了本文档的范围，但此处列出了一些重要的注意事项。
When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures has not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticable steps to inform the end user about it.
在处理证书时，有许多情况下处理可能会失败。由于处理可能由用户代理、安全网关或其他程序完成，因此没有单一的方法来处理此类故障。然而，仅仅因为没有列出处理故障的方法，读者就不应该认为它们不重要。反之亦然：如果证书不可证明有效且与消息关联，则处理软件应立即采取可注意的步骤通知最终用户。
Some of the many places where signature and certificate checking might fail include:
签名和证书检查可能失败的许多地方包括：
- no Internet mail addresses in a certificate match the sender of a message - no certificate chain leads to a trusted CA - no ability to check the CRL for a certificate - an invalid CRL was received - the CRL being checked is expired - the certificate is expired - the certificate has been revoked
- 证书中没有与消息发件人匹配的Internet邮件地址-没有证书链导致受信任的CA-无法检查证书的CRL-收到无效的CRL-正在检查的CRL已过期-证书已过期-证书已吊销
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails.
当然，在其他情况下，证书可能是无效的，处理软件有责任彻底检查所有证书，并决定如果检查失败怎么办。
A. Object Identifiers and Syntax
A.对象标识符和语法
Sections A.1 through A.4 are adopted from [SMIME-MSG].
第A.1至A.4节采用[SMIME-MSG]。
emailAddress OBJECT IDENTIFIER ::=
emailAddress OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}
CountryName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 6}
CountryName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 6}
StateOrProvinceName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 8}
StateOrProvinceName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 8}
locality OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 7}
locality OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 7}
CommonName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 3}
CommonName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 3}
Title OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 12}
Title OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 12}
Organization OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 10}
Organization OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 10}
OrganizationalUnit OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 11}
OrganizationalUnit OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 11}
StreetAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 9}
StreetAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 9}
Postal Code OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 17}
Postal Code OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 17}
Phone Number OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 20}
Phone Number OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 20}
postalAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 16}
postalAddress OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 16}
challengePassword OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 7}
challengePassword OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 7}
unstructuredAddress OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 8}
unstructuredAddress OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 8}
basicConstraints OBJECT IDENTIFIER ::=
basicConstraints OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 19 }
{joint-iso-ccitt(2) ds(5) 29 19 }
The ASN.1 definition of basicConstraints certificate extension is:
ASN.1基本约束证书扩展的定义为：
basicConstraints basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax
IDENTIFIED BY { id-ce 19 } }
basicConstraints basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax
IDENTIFIED BY { id-ce 19 } }
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
keyUsage OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 15 }
keyUsage OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 15 }
The ASN.1 definition of keyUsage certificate extension is:
ASN.1密钥使用证书扩展的定义是：
keyUsage EXTENSION ::= {
SYNTAX KeyUsage
IDENTIFIED BY { id-ce 15 }}
keyUsage EXTENSION ::= {
SYNTAX KeyUsage
IDENTIFIED BY { id-ce 15 }}
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6)}
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6)}
B. References
B.参考资料
[KEYM] PKIX Part 1. At the time of this writing, PKIX is a Work in Progress, but it is expected that there will be standards-track RFCs at some point in the future.
[KEYM]PKIX第1部分。在撰写本文时，PKIX是一项正在进行的工作，但预计在将来的某个时候会有标准跟踪RFC。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 1l4, RFC 2119, March 1997.
[MUSTSHOULD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 1l4，RFC 2119，1997年3月。
[PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[PKCS-1]Kaliski，B.，“PKCS#1:RSA加密版本1.5”，RFC 2313，1998年3月。
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[PKCS-7]Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 2315，1998年3月。
[PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.
[PKCS-10]Kaliski，B.，“PKCS#10：认证请求语法版本1.5”，RFC 2314，1998年3月。
[RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[SMIME-MSG] Dusse, S., Hoffman, P., Ramsdell, R., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[SMIME-MSG]Dusse，S.，Hoffman，P.，Ramsdell，R.，Lundblade，L.，和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
Information technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
Information technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
[X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
Information technology - Open Systems Interconnection - The
Directory: Models
[X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
Information technology - Open Systems Interconnection - The
Directory: Models
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
Information technology - Open Systems Interconnection - The
Directory: Authentication framework
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
Information technology - Open Systems Interconnection - The
Directory: Authentication framework
[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, Information technology - Open Systems Interconnection - The Directory: Selected attribute types.
[X.520]ITU-T建议X.520（1997）| ISO/IEC 9594-6:1997，信息技术-开放系统互连-目录：选定属性类型。
C. Compatibility with Prior Practice in S/MIME
C.与S/MIME先前实践的兼容性
S/MIME was originally developed by RSA Data Security, Inc. Many developers implemented S/MIME agents before this document was published. All S/MIME receiving agents SHOULD make every attempt to interoperate with these earlier implementations of S/MIME.
S/MIME最初由RSA Data Security，Inc.开发。在本文档发布之前，许多开发人员都实现了S/MIME代理。所有S/MIME接收代理都应该尽一切努力与这些早期的S/MIME实现进行互操作。
D. Acknowledgements
D.致谢
Significant contributions to the content of this memo were made by many people, including David Solo, Anil Gangolli, Jeff Thompson, and Lisa Repka.
许多人对这份备忘录的内容做出了重大贡献，包括大卫·索洛、阿尼尔·甘奥利、杰夫·汤普森和丽莎·雷普卡。
E. Authors' Addresses
E.作者地址
Steve Dusse RSA Data Security, Inc. 100 Marine Parkway, #500 Redwood City, CA 94065 USA
Steve Dusse RSA Data Security，Inc.美国加利福尼亚州红木市500号海洋公园路100号，邮编：94065
Phone: (415) 595-8782 EMail: spock@rsa.com
电话：（415）595-8782电子邮件：spock@rsa.com
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060
保罗霍夫曼互联网邮件联盟127塞格雷广场圣克鲁斯，加利福尼亚州95060
Phone: (408) 426-9827 EMail: phoffman@imc.org
电话：（408）426-9827电子邮件：phoffman@imc.org
Blake Ramsdell Worldtalk 13122 NE 20th St., Suite C Bellevue, WA 98005
布雷克·拉姆斯代尔世界谈话13122 NE 20 St.，C套房Bellevue，WA 98005
Phone: (425) 882-8861 EMail: blaker@deming.com
电话：（425）882-8861电子邮件：blaker@deming.com
Jeff Weinstein Netscape Communications Corporation 501 East Middlefield Road Mountain View, CA 94043
Jeff Weinstein Netscape Communications Corporation加利福尼亚州山景城东米德尔菲尔德路501号，邮编94043
Phone: (415) 254-1900 EMail: jsw@netscape.com
电话：（415）254-1900电子邮件：jsw@netscape.com
F. Full Copyright Statement
F.完整的版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。