[要約] RFC 2312は、S/MIMEバージョン2の証明書の取り扱いに関する規格です。このRFCの目的は、S/MIMEバージョン2の証明書の構造と使用方法を定義することです。
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.
Copyright（C）The Internet Society（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（Secure / Multipurpose Internet Mail Extensions）は、安全な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でサポートされている証明書ベースのキー管理のためのさまざまなアーキテクチャを継承しています。 S / MIMEメッセージが証明書要求を行う方法は、[SMIME-MSG]で定義されていることに注意してください。
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標準ではありません。このドキュメントでの「標準」という用語の使用は、IETF標準ではなく、S / MIMEバージョン2の採用者のための標準を示しています。
For the purposes of this memo, the following definitions apply.
このメモの目的のために、次の定義が適用されます。
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208.
ASN.1：CCITT X.208で定義されている抽象構文記法1。
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209.
BER：CCITT X.209で定義されているASN.1の基本的なエンコーディングルール。
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：CCITT X.509で定義されているASN.1のDistinguished Encoding Rules。
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]の定義に準拠しています。 [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フィールドを現在の時間と照合して確認する必要があります（SHOULD）。現在時刻がnextUpdate時刻より遅い場合、エージェントが実行するアクションはローカルの決定です。たとえば、人間のユーザーに警告したり、可能であれば新しいCRLを取得したりできます。
Receiving agents MUST recognize CRLs in received S/MIME messages.
受信エージェントは、受信したS / MIMEメッセージのCRLを認識しなければなりません（MUST）。
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メッセージにCRLとして含まれている失効情報を使用する必要があります。クライアントは、後のメッセージの処理で使用するために、メッセージで受信したCRLを格納する必要があります（SHOULD）。
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]を参照してください。セクション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メッセージ形式は、公開鍵コンテンツタイプの証明書の2つの形式の選択をサポートします。X.509およびPKCS＃6拡張証明書です。 PKCS＃6形式は広く使用されていません。さらに、X.509証明書の提案されたリビジョンは、PKCS＃6で意図されていたのと同じ機能と柔軟性のほとんどに対応しています。したがって、送信エージェントと受信エージェントはPKCS＃6拡張証明書を使用してはなりません（MUST NOT）。
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.
受信エージェントは、メッセージ送信者と相互に任意の順序で任意の関係の任意の数の証明書を処理できなければなりません（MUST）。多くの場合、署名付きメッセージに含まれる証明書は、送信者から特定のルートまでの一連の証明書を表す場合があります。ただし、署名されたメッセージ内の証明書が無関係であり、便宜上含まれている場合もあります。
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.
送信エージェントには、ユーザーの公開鍵の証明書と関連する発行者証明書を含める必要があります（SHOULD）。これにより、意図した受信者が発信者の公開鍵への信頼を確立できる可能性が高まります。これは、他の方法で送信者の公開鍵にアクセスできない受信者にメッセージを送信するとき、または署名されたメッセージを新しい受信者に送信するときに特に重要です。 S / MIMEオブジェクトが、共有ディレクトリや手動の証明書配布などの他の方法で相互の証明書へのアクセスを確立している通信相手のグループ内で送信される場合、送信メッセージに証明書を含めることは省略できます。受信S / MIMEエージェントは、データベースまたはディレクトリ検索スキームを使用して、証明書なしでメッセージを処理できる必要があります（SHOULD）。
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）までの証明書チェーンを少なくとも1つ含める必要があります（SHOULD）。受信エージェントは、任意の数の証明書とチェーンを処理できる必要があります（SHOULD）。
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]で定義されています。識別名は、1つ以上の相対識別名に分割されます。各相対識別名は、1つ以上の属性値アサーションで構成されています。各属性値アサーションは、属性識別子と、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 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.500ディレクトリに従って識別名を使用することはあまり普及していません。対照的に、RFC 822 [RFC-822]で説明されているインターネットメールアドレスは、メッセージの発信者と受信者を識別するためにインターネット環境でほぼ排他的に使用されます。ただし、インターネットメールアドレスは、X.500識別名とは似ていません（おそらく、両方とも階層的であることを除いて）。インターネットメールアドレスを公開キーを保持するエンティティにマップするには、いくつかの方法が必要です。一部の人々は、X.509証明書フォーマットを他のバインディングメカニズムのために放棄すべきだと提案しています。代わりに、S / MIMEはX.509証明書と識別名のメカニズムを維持しながら、インターネットメール環境に合わせて名前付け情報の内容を調整します。
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]で説明されているインターネットメールアドレスを含める必要があります。アドレスは、その仕様のセクション6.1で定義されている「addr-spec」である必要があります。
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.
送信エージェントは、メールメッセージのFromヘッダーのアドレスを、署名者の証明書のインターネットメールアドレスと一致させる必要があります（SHOULD）。受信エージェントは、メールメッセージのFromヘッダーのアドレスが署名者の証明書のインターネットメールアドレスと一致することを確認する必要があります。この比較が失敗した場合、受信エージェントはメッセージの明示的な代替処理を提供する必要があります。これは、メッセージを拒否する場合があります。
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.
受信エージェントは、証明書の識別名内の以下の名前属性の各セットの0、1、またはそれ以上のインスタンスの解析をサポートする必要があります。
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.
送信エージェントは、識別名の作成時にインターネットメールアドレスを含める必要があります。識別名の作成中の残りの名前属性の包含、省略、および順序付けに関するガイドラインは、対応する名前と公開鍵を認証する認証サービスに関連するポリシーによって決定される可能性が最も高いでしょう。
CountryName StateOrProvinceName Locality CommonName Title Organization OrganizationalUnit StreetAddress PostalCode PhoneNumber EmailAddress All attributes other than EmailAddress are described in X.520 [X.520]. EmailAddress is an IA5String that can have multiple attribute values.
CountryName StateOrProvinceName Locality CommonName Title Organization OrganizationalUnit StreetAddress PostalCode PhoneNumber EmailAddress EmailAddress以外のすべての属性は、X.520 [X.520]で説明されています。 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.
受信エージェントと送信エージェントは、ユーザーが後の取得を保証するような方法で、通信相手の証明書を「保存および保護」できるようにするメカニズムも提供する必要があります（SHOULD）。多くの環境では、証明書の取得/保管メカニズムを何らかの証明書データベースにリンクすることが望ましい場合があります。最も単純な形式では、証明書データベースは特定のユーザーに対してローカルであり、ユーザーの頻繁な通信相手を格納する「アドレス帳」と同じように機能します。このようにして、証明書取得メカニズムは、ユーザーが（おそらく着信メッセージから）保管した証明書に限定されます。包括的な証明書の取得/保存ソリューションは、2つ以上のメカニズムを組み合わせて、ユーザーに最大の柔軟性とユーティリティを提供できます。たとえば、セキュリティで保護されたインターネットメールエージェントは、ユーザーのローカル証明書の格納/取得データベースで証明書が見つからない場合、集中型の証明書取得メカニズムをチェックして証明書を探す場合があります。
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証明書のみのメッセージを使用して、証明書のインポートとエクスポートのメカニズムを提供する必要があります（SHOULD）。これにより、単一の証明書だけではなく、完全な証明書チェーンのインポートとエクスポートが可能になります。これは[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）取得メカニズムにアクセスできる必要があります（SHOULD）。受信または送信エージェントは、ユーザーが、後で取得することを保証するような方法で、通信相手の着信証明書失効情報を保存できるようにするメカニズムも提供する必要があります（SHOULD）。ただし、着信メッセージから離れて格納されている情報を取得するよりも、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情報を取得して利用する必要があります（SHOULD）。ただし、多くの場合（オフライン検証など）、最新の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は、チェーン検証手順で次の2つの方法で利用できるようになります。a）受信メッセージ、およびb）証明書とCRLの取得メカニズム。着信メッセージの証明書とCRLは、特定の順序である必要はなく、メッセージの送信者または受信者に関連する必要もありません（ほとんどの場合、それらは送信者に関連します）。着信証明書とCRLは、チェーン検証で使用するためにキャッシュし、後で使用するためにオプションで保存する必要があります（SHOULD）。この一時的な証明書とCRLキャッシュは、他の証明書とCRL取得メカニズムを強化して、着信署名メッセージのチェーン検証のために使用する必要があります（SHOULD）。
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）は、証明書発行者によって署名されています。受信エージェントは、[SMIME-MSG]で説明されている512ビットから2048ビットまでの鍵サイズのmd5WithRSAEncryptionおよびsha-1WithRSAEncryption署名アルゴリズムで作成された証明書およびCRLの署名を検証できる必要があります。受信エージェントは、鍵サイズが512ビットから2048ビットのmd2WithRSAEncryption署名アルゴリズムで作成された証明書とCRLの署名を検証できる必要があります（SHOULD）。
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環境で最大の価値を持つ最低限必要な証明書拡張のセットを識別します。 basicConstraints、およびkeyUsage拡張は、[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、およびsubjectAltNamesをエンドユーザー証明書に表示するときに正しく処理する必要があります。定義済みの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.
証明書には、basicContstraints拡張機能を含める必要があります。
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に署名できることを指定するkeyUsage拡張を含む下位の発行者証明書を作成できます。
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エージェントまたは関連する管理ユーティリティまたは機能は、ユーザーの公開鍵と関連する名前情報を与えられた場合、認証要求を生成できなければなりません（MUST）。ほとんどの場合、ユーザーの公開鍵/秘密鍵のペアは同時に生成されます。ただし、キーイング情報が外部プロセスによって生成される場合があります（暗号化トークンでキーペアが生成されたとき、または「キーリカバリ」サービスによって生成されたときなど）。
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.
異なる識別名にバインドされた同じキーペアに対して、複数の有効な（つまり、有効期限が切れておらず、取り消されていない）証明書があってはなりません（SHOULD NOT）。そうでない場合、メッセージの受信者が検出できない方法で、攻撃者が1つの有効な証明書を別の有効な証明書に置き換えることができるというセキュリティ上の欠陥が存在します。ユーザーが自分の名前を変更する（または代替名を作成する）場合、ユーザーエージェントは新しいキーペアを生成する必要があります（SHOULD）。ユーザーが新しい名前または代替名で既存の鍵ペアを再利用したい場合、ユーザーはまず、既存の公開鍵の有効な証明書をすべて取り消す必要があります（SHOULD）。
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拡張を持たなければなりません（MUST）。 CAはこれらの拡張機能を均一に使用する必要があります（SHOULD）。
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証明書を処理する必要があります（SHOULD）。
When selecting an appropriate issuer's certificate to use to verify a given certificate, clients SHOULD process the AuthorityKeyIdentifier and SubjectKeyIdentifier extensions.
特定の証明書の検証に使用する適切な発行者の証明書を選択する場合、クライアントはAuthorityKeyIdentifierおよびSubjectKeyIdentifier拡張を処理する必要があります（SHOULD）。
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およびrsaEncryption OIDを使用したRSA鍵の識別をサポートする必要があります。証明機関は、sha-1WithRSAEncryptionとmd5WithRSAEncryptionをサポートする必要があり、[SMIME-MSG]で説明されているように、証明書要求の署名を検証するためにMD2WithRSAEncryptionをサポートする必要があります。
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キーはrsaEncryption OIDで識別され、sha-1WithRSAEncryption署名アルゴリズムで署名されるべきです（SHOULD）。証明書要求は、md2WithRSAEncryption署名アルゴリズムで署名してはなりません（MUST NOT）。
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.
証明書要求には、証明書の一部（3.2で説明）またはPKCS＃10属性リストの一部として、有効なインターネットメールアドレスを含める必要があります。証明機関は、 "From："ヘッダーのアドレスがこれらのアドレスのいずれかに一致することを確認する必要があります。 CAは、CAオペレーターがアドレスが一致しないメッセージの処理を設定できるようにする必要があります（SHOULD）。
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.
証明機関は、着信メッセージの次の一連の証明要求属性の0または1つのインスタンスの解析をサポートする必要があります（SHOULD）。特定の実装がサポートしていない属性は、リクエスタに警告メッセージを生成するか、警告なしに無視される場合があります。認証要求の作成および送信中に以下の属性を含めることは、対応する名前と公開鍵を認証する認証サービスに関連するポリシーによって決定される可能性が最も高いでしょう。
postalAddress challengePassword unstructuredAddress
postalAddress challengePassword非構造化アドレス
postalAddress is described in [X.520].
postalAddressは[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.
challenge-password属性タイプは、エンティティが証明書の失効をリクエストするときに使用するパスワードを指定します。パスワードの解釈は、証明書の発行者が指定することを目的としています。特定の解釈は必要ありません。 challenge-password属性タイプは、PKCS＃10証明書リクエストを対象としています。
Challenge-password attribute values have ASN.1 type ChallengePassword:
チャレンジパスワードの属性値には、ASN.1タイプのチャレンジパスワードがあります。
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タイプ（たとえば、UNIVERSAL STRING）になる場合、ChallengePasswordはCHOICEタイプになることが予想されます。
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 certification requests.
非構造化アドレス属性タイプは、証明書のサブジェクトのアドレスを非構造化ASCIIまたはT.61文字列として指定します。アドレスの解釈は、証明書の発行者が指定することを意図しています。特定の解釈は必要ありません。おそらく解釈は、X.520 postalAddress属性タイプの代替として行われます。非構造化アドレス属性タイプは、PKCS＃10認証要求を対象としています。
Unstructured-address attribute values have ASN.1 type UnstructuredAddress:
非構造化アドレス属性値には、ASN.1タイプUnstructuredAddressがあります。
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の改行文字（16進コード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タイプ（例：UNIVERSAL STRING）になると、UnstructuredAddressがCHOICEタイプになることが予想されます。
UnstructuredAddress ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
Certification authorities SHOULD use the sha-1WithRSAEncryption signature algorithms when signing certificates.
証明機関は、証明書に署名するときに、sha-1WithRSAEncryption署名アルゴリズムを使用する必要があります。
[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情報を伝えるために使用されます。証明機関は、この形式を使用して、証明要求の正常な履行から生じた証明書情報を返す必要があります。少なくとも、満たされた証明書の応答には、実際のサブジェクト証明書（証明書要求の情報に対応）が含まれている必要があります。応答には、発行者をより高いレベルの証明機関にリンクする他の証明書と、対応する証明書失効リストを含める必要があります（SHOULD）。関連のない証明書と失効情報も受け入れられます。
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
- 証明書内のインターネットメールアドレスがメッセージの送信者と一致しない-証明書チェーンが信頼できる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].
[S MIME-MESSAGE]のセクションA.1からA.4が採用されています。
emailAddress OBJECT IDENTIFIER ::=
{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}
StateOrProvinceName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 8}
locality OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 7}
CommonName OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 3}
Title OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 12}
Organization OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 10}
OrganizationalUnit OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) attributeType(4) 11}
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}
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}
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}
basicConstraints OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 19 }
The ASN.1 definition of basicConstraints certificate extension is:
basicConstraints証明書拡張のASN.1定義は次のとおりです。
basicConstraints basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax
IDENTIFIED BY { id-ce 19 } }
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
keyUsage OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) 29 15 }
The ASN.1 definition of keyUsage certificate extension is:
keyUsage証明書拡張のASN.1定義は次のとおりです。
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)}
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.
[必須] 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 Encryption Version 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：Cryptographic Message Syntax Version 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：Certification Request Syntax Version 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]クロッカー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 Version 2 Message Specification」、RFC 2311、1998年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.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.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.
このメモの内容への多大な貢献は、David Solo、Anil Gangolli、Jeff Thompson、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. 100 Marine Parkway、＃500 Redwood City、CA 94065 USA
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
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz、CA 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
Blake Ramsdell Worldtalk 13122 NE 20th St.、Suite 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 East Middlefield Road Mountain View、CA 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.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。