[要約] 要約：RFC 6664は、公開鍵定義のためのS/MIME機能についての規格です。 目的：このRFCの目的は、S/MIMEを使用して公開鍵定義を行うための機能を提供することです。
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 6664 Soaring Hawk Consulting
Category: Informational July 2012
ISSN: 2070-1721
S/MIME Capabilities for Public Key Definitions
公開鍵定義のS / MIME機能
Abstract
概要
This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used.
このドキュメントでは、PKIXワーキンググループで定義されている公開キーの現在のセットに対するASN.1エンコーディングのSecure / Multipurpose Internet Mail Extensions（S / MIME）機能タイプのセットを定義します。これにより、リクエスタは、応答で使用する公開鍵と署名アルゴリズムに関する情報を指定できます。 「Online Certificate Status Protocol Algorithm Agility」（RFC 6277）は、これが使用される場所の例を詳しく説明しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6664.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6664で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4
2. RSA Public Keys . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Generic RSA Public Keys . . . . . . . . . . . . . . . . . 4
2.2. RSASSA-PSS Signature Public Keys . . . . . . . . . . . . . 5
2.3. RSAES-OAEP Key Transport Public Keys . . . . . . . . . . . 6
3. Diffie-Hellman Keys . . . . . . . . . . . . . . . . . . . . . 7
3.1. DSA Signature Public Key . . . . . . . . . . . . . . . . . 7
3.2. DH Key Agreement Keys . . . . . . . . . . . . . . . . . . 8
4. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1. Generic Elliptic Curve Keys . . . . . . . . . . . . . . . 9
4.2. Elliptic Curve DH Keys . . . . . . . . . . . . . . . . . . 10
4.3. Elliptic Curve MQV Keys . . . . . . . . . . . . . . . . . 10
5. RSASSA-PSS Signature Algorithm Capability . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 15
Appendix B. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 18
Appendix C. Future Work . . . . . . . . . . . . . . . . . . . . . 19
In the process of dealing with the Online Certificate Status Protocol (OCSP) agility issues in [RFC6277], it was noted that we really wanted to describe information to be used in selecting a public key, but we did not have any way of doing so. This document fills that hole by defining a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for a small set of public key representations.
[RFC6277]のオンライン証明書ステータスプロトコル（OCSP）の俊敏性の問題に対処する過程で、公開鍵の選択に使用される情報を本当に説明したいと述べましたが、その方法はありませんでした。このドキュメントでは、公開キー表現の小さなセットに対して一連のSecure / Multipurpose Internet Mail Extensions（S / MIME）Capabilityタイプを定義することで、その穴を埋めています。
S/MIME capabilities were originally defined in [SMIMEv3-MSG] as a way for the sender of an S/MIME message to tell the recipient of the message the set of encryption algorithms that were supported by the sender's system. In the beginning, the focus was primarily on communicating the set of encryption algorithms that were supported by the sender. Over time, it was expanded to allow for an S/MIME client to state that it supported new features such as the compression data type and binary encoded contents. The structure was defined so that parameters can be passed in as part of the capability to allow for subsets of algorithms to be used. This was used for the RC2 encryption algorithm, although only two values out of the set of values were ever used. The goal of restricting the set of values is to allow a client to use a simple binary comparison in order to check for equality. The client should never need to decode the capability and do an element-by-element comparison. Historically, this has not been a problem as the vast majority of S/MIME capabilities consist of just the algorithm identifier for the algorithm.
S / MIME機能は、S / MIMEメッセージの送信者がメッセージの受信者に送信者のシステムでサポートされている暗号化アルゴリズムのセットを通知する方法として[SMIMEv3-MSG]で最初に定義されました。最初は、主に送信者がサポートする暗号化アルゴリズムのセットの通信に重点が置かれていました。時間の経過とともに、S / MIMEクライアントが圧縮データタイプやバイナリエンコードされたコンテンツなどの新機能をサポートしていることを示すことができるように拡張されました。構造は、アルゴリズムのサブセットを使用できるようにする機能の一部としてパラメーターを渡すことができるように定義されています。これはRC2暗号化アルゴリズムに使用されましたが、値のセットのうち2つしか使用されていませんでした。値のセットを制限する目的は、クライアントが等しいかどうかを確認するために単純なバイナリ比較を使用できるようにすることです。クライアントは、機能をデコードして要素ごとの比較を行う必要はありません。これまで、S / MIME機能の大部分はアルゴリズムのアルゴリズム識別子のみで構成されているため、これは問題ではありませんでした。
Many people are under the impression that only a single data structure can be assigned to an object identifier, but this is not the case. As an example, the OID rsaEncryption is used in multiple locations for different data. It represents a public key, a key transport algorithm (in S/MIME), and was originally used in the Public-Key Cryptography Standards (PKCS) #7 specification as a signature value identifier (this has since been changed by the S/MIME specifications). One of the implications is that when mapping an object identifier to a data type structure, the location in the ASN.1 structure needs to be taken into consideration as well.
多くの人々は、オブジェクト識別子に割り当てることができるデータ構造は1つだけであるという印象を受けていますが、そうではありません。例として、OID rsaEncryptionは、さまざまなデータの複数の場所で使用されます。これは、公開鍵、鍵転送アルゴリズム（S / MIMEで）を表し、元々は公開鍵暗号化標準（PKCS）＃7仕様で署名値識別子として使用されていました（これはS / MIMEによって変更されています）仕様）。影響の1つは、オブジェクト識別子をデータ型構造にマッピングするときに、ASN.1構造内の場所も考慮する必要があることです。
The main body of the text is written using snippets of ASN.1 that are extracted from the ASN.1 2008 module in Appendix A. ASN.1 2008 is used in this document because it directly represents the metadata that is not representable in the 1988 version of ASN.1 but instead is part of the text. In keeping with the current policy of the PKIX working group, the 1988 module along with the text is the normative module. In the event of a conflict between the content of the two modules, the 1988 module is authoritative.
テキストの本文は、付録AのASN.1 2008モジュールから抽出されたASN.1のスニペットを使用して記述されています。ASN.12008は、1988では表現できないメタデータを直接表すため、このドキュメントで使用されています。 ASN.1のバージョンですが、代わりにテキストの一部です。 PKIXワーキンググループの現在のポリシーに沿って、1988年版のモジュールと本文は規範的なモジュールです。 2つのモジュールの内容に矛盾がある場合は、1988年のモジュールが信頼できます。
When reading this document, it is assumed that you will have a degree of familiarity with the basic object module that is presented in Section 3 of RFC 5912 [RFC5912]. We use the SMIME-CAPS object in this document; it associates two fields together in a single object.
このドキュメントを読む際には、RFC 5912 [RFC5912]のセクション3に示されている基本的なオブジェクトモジュールについてある程度理解していることを前提としています。このドキュメントではSMIME-CAPSオブジェクトを使用しています。 2つのフィールドを1つのオブジェクトに関連付けます。
SMIME-CAPS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id }
These fields are:
これらのフィールドは次のとおりです。
&id contains an object identifier. When placed in an object set, this element is tagged so that no two elements can be placed in the set that have the same value in the &id field. Note that this is not a restriction saying that only a single object can exist with a single object identifier.
＆idにはオブジェクト識別子が含まれています。オブジェクトセットに配置する場合、この要素はタグ付けされるため、＆idフィールドに同じ値を持つ2つの要素をセットに配置できません。これは、単一のオブジェクト識別子を持つ単一のオブジェクトしか存在できないという制限ではないことに注意してください。
&Type optionally contains an ASN.1 type identifier. If the field &Type is not defined, then the optional parameters field of the AlgorithmIdentifier type would be omitted.
＆Typeには、オプションでASN.1タイプ識別子が含まれます。フィールド＆Typeが定義されていない場合、AlgorithmIdentifierタイプのオプションのパラメーターフィールドは省略されます。
The class also has a specialized syntax for how to define an object in this class. The all uppercase words TYPE IDENTIFIER and BY are syntactic sugar to make it easier to read. The square brackets define optional pieces of the syntax.
このクラスには、このクラスでオブジェクトを定義する方法に関する特別な構文もあります。大文字のTYPE IDENTIFIERとBYはすべて、読みやすくするための構文糖です。角括弧は、構文のオプション部分を定義します。
The ASN.1 syntax permits any field in an object to be referenced in another location. This means that if an object called foo has a field named &value, the value can be directly referenced as foo.& value. This means that any updates to values or types are automatically propagated, and we do not need to replicate the data.
ASN.1構文では、オブジェクトの任意のフィールドを別の場所で参照できます。つまり、fooというオブジェクトに＆valueという名前のフィールドがある場合、その値はfoo。＆値として直接参照できます。これは、値またはタイプへの更新は自動的に伝達されるため、データを複製する必要がないことを意味します。
When capitalized, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
大文字の場合、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」この文書は、[RFC2119]で説明されているように解釈されます。
There are currently three different public key object identifiers for RSA public keys. These are RSA, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), and RSA Signature Scheme with Appendix - Probabilistic Signature Scheme (RSASSA-PSS).
現在、RSA公開鍵には3つの異なる公開鍵オブジェクト識別子があります。これらは、RSA、RSA暗号化スキーム-最適な非対称暗号化パディング（RSAES-OAEP）、およびRSA署名スキームと付録-確率的署名スキーム（RSASSA-PSS）です。
Almost all RSA keys that are contained in certificates today use the generic RSA public key format and identifier. This allows for the public key to be used both for key transport and for signature validation (assuming it is compatible with the bits in the key usage extension). The only reason for using one of the more specific public key identifiers is if the user wants to restrict the usage of the RSA public key to a specific algorithm.
現在、証明書に含まれているほとんどすべてのRSAキーは、汎用のRSA公開キー形式と識別子を使用しています。これにより、公開鍵を鍵の転送と署名の検証の両方に使用できるようになります（公開鍵が鍵用途拡張のビットと互換性があると想定）。より具体的な公開キー識別子の1つを使用する唯一の理由は、ユーザーがRSA公開キーの使用を特定のアルゴリズムに制限したい場合です。
For the generic RSA public key, the S/MIME capability that is advertised is a request for a specific key size to be used. This would normally be used for dealing with a request on the key to be used for a signature that the client would then verify. In general, the user would provide a specific key when a key transport algorithm is being considered.
汎用RSA公開鍵の場合、アドバタイズされるS / MIME機能は、使用される特定の鍵サイズの要求です。これは通常、クライアントが検証する署名に使用されるキーの要求を処理するために使用されます。一般に、ユーザーは、キー転送アルゴリズムを検討しているときに特定のキーを提供します。
The ASN.1 that is used for the generic RSA public key is defined as below:
汎用RSA公開鍵に使用されるASN.1は、次のように定義されています。
scap-pk-rsa SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsa.&id
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-rsa is a new SMIME-CAPS object. This object associates the existing object identifier (rsaEncryption) used for the public key in certificates (defined in [RFC3279] and [RFC5912]) with a new type defined in this document.
scap-pk-rsaは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、証明書の公開鍵に使用される既存のオブジェクト識別子（rsaEncryption）（[RFC3279]および[RFC5912]で定義）を、このドキュメントで定義されている新しいタイプに関連付けます。
RSAKeyCapabilities carries the set of desired capabilities for an RSA key. The fields of this type are:
RSAKeyCapabilitiesは、RSAキーに必要な一連の機能を備えています。このタイプのフィールドは次のとおりです。
minKeySize contains the minimum length of the RSA modulus to be used. This field SHOULD NOT contain a value less than 1024.
minKeySizeには、使用するRSAモジュラスの最小長が含まれています。このフィールドには、1024未満の値を含める必要があります（SHOULD NOT）。
maxKeySize contains the maximum length of the RSA modules that should be used. If this field is absent, then no maximum length is requested/expected. This value is normally selected so as not to cause the current code to run unacceptably long when processing signatures.
maxKeySizeには、使用する必要があるRSAモジュールの最大長が含まれています。このフィールドがない場合、最大長は要求されず、予期されません。この値は通常、署名の処理時に現在のコードが許容できないほど長く実行されないようにするために選択されます。
RSAKeySize provides a set of suggested values to be used. The values 1024, 2048, 3072, 7680, and 15360 are from the NIST guide on signature sizes [NIST-SIZES] while the others are common powers of two that are used. The list is not closed, and other values can be used.
RSAKeySizeは、使用する一連の推奨値を提供します。 1024、2048、3072、7680、および15360の値は、署名サイズ[NIST-SIZES]に関するNISTガイドからのものですが、その他は使用される2の一般的な累乗です。リストは閉じられておらず、他の値を使用できます。
While one will use the generic RSA public key identifier in a certificate most of the time, the RSASSA-PSS identifier can be used if the owner of the key desires to restrict the usage of the key to just this algorithm. This algorithm does have the ability to place a set of algorithm parameters in the public key info structure, but they have not been included in this location as the same information should be carried in the signature S/MIME capabilities instead.
ほとんどの場合、証明書で汎用RSA公開鍵識別子を使用しますが、鍵の所有者が鍵の使用をこのアルゴリズムのみに制限したい場合は、RSASSA-PSS識別子を使用できます。このアルゴリズムには、公開鍵情報構造に一連のアルゴリズムパラメーターを配置する機能がありますが、同じ場所に署名S / MIME機能で同じ情報を伝達する必要があるため、これらのパラメーターはこの場所に含まれていません。
The ASN.1 that is used for the RSASSA-PSS public key is defined below:
RSASSA-PSS公開鍵に使用されるASN.1は、以下で定義されています。
scap-pk-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaSSA-PSS.&id
}
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-rsaSSA-PSS is a new SMIME-CAPS object. This object associates the existing object identifier (id-RSASSA-PSS) used for the public key certificates (defined in [RFC4055] and [RFC5912]) with type RSAKeyCapabilities.
scap-pk-rsaSSA-PSSは、新しいSMIME-CAPSオブジェクトです。このオブジェクトは、公開鍵証明書（[RFC4055]および[RFC5912]で定義）に使用される既存のオブジェクト識別子（id-RSASSA-PSS）をタイプRSAKeyCapabilitiesに関連付けます。
While one will use the generic RSA public key identifier in a certificate most of the time, the RSAES-OAEP identifier can be used if the owner of the key desires to restrict the usage of the key to just this algorithm. This algorithm does have the ability to place a set of algorithm parameters in the public key info structure, but they have not been included in this location as the same information should be carried in the key transport S/MIME capabilities instead.
ほとんどの場合、証明書では汎用のRSA公開鍵識別子を使用しますが、鍵の所有者が鍵の使用をこのアルゴリズムのみに制限したい場合は、RSAES-OAEP識別子を使用できます。このアルゴリズムには、公開鍵情報構造に一連のアルゴリズムパラメーターを配置する機能がありますが、同じ場所にキートランスポートS / MIME機能で同じ情報を伝達する必要があるため、これらのパラメーターはこの場所に含まれていません。
The ASN.1 that is used for the RSAES-OAEP public key is defined below:
RSAES-OAEP公開鍵に使用されるASN.1は、以下で定義されています。
scap-pk-rsaES-OAEP SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaES-OAEP.&id
}
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-rsaES-OAEP is a new SMIME-CAPS object. This object associates the existing object identifier (id-RSAES-OAEP) used for the public key certificates (defined in [RFC4055] and [RFC5912]) with type RSAKeyCapabilities.
scap-pk-rsaES-OAEPは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、公開鍵証明書（[RFC4055]および[RFC5912]で定義）に使用される既存のオブジェクト識別子（id-RSAES-OAEP）をタイプRSAKeyCapabilitiesに関連付けます。
There are currently two Diffie-Hellman (DH) public key object identifiers. These are DH key agreement and Digital Signature Standard (DSA).
現在、2つのDiffie-Hellman（DH）公開鍵オブジェクト識別子があります。これらは、DH鍵合意およびデジタル署名標準（DSA）です。
This public key type is used for the validation of DSA signatures.
この公開鍵タイプは、DSA署名の検証に使用されます。
The ASN.1 that is used for DSA keys is defined below:
DSAキーに使用されるASN.1は、以下で定義されています。
scap-pk-dsa SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dsa.&id
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-dsa is a new SMIME-CAPS object. This object associates the existing object identifier (id-dsa) used for the public key in certificates (defined in [RFC3279] and [RFC5912]) with a new type defined here, DSAKeyCapabilities.
scap-pk-dsaは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、証明書の公開鍵に使用される既存のオブジェクト識別子（id-dsa）（[RFC3279]および[RFC5912]で定義）を、ここで定義される新しいタイプDSAKeyCapabilitiesに関連付けます。
DSAKeyCapabilities carries the desired set of capabilities for the DSA key. The fields of this type are:
DSAKeyCapabilitiesは、DSAキーに必要な一連の機能を備えています。このタイプのフィールドは次のとおりです。
keySizes is used when only a key size is needed to be specified and not a specific group. It is expected that this would be the most commonly used of the two options. In key sizes, the fields are used as follows:
keySizesは、特定のグループではなく、キーサイズのみを指定する必要がある場合に使用されます。これは、2つのオプションの中で最も一般的に使用されると予想されます。キーサイズでは、フィールドは次のように使用されます。
minKeySize contains the minimum length of the DSA modulus to be used.
minKeySizeには、使用するDSAモジュラスの最小長が含まれています。
maxKeySize contains the maximum length of the DSA modules that should be used. If this field is absent, then no maximum length is requested/expected.
maxKeySizeには、使用する必要があるDSAモジュールの最大長が含まれています。このフィールドが存在しない場合、最大長は要求/期待されません。
maxSizeP contains the maximum length of the value p that should be used. If this field is absent, then no maximum length is imposed.
maxSizePには、使用する値pの最大長が含まれています。このフィールドがない場合、最大長は課されません。
maxSizeQ contains the maximum length of the value q that should be used. If this field is absent, then no maximum length is imposed.
maxSizeQには、使用する必要がある値qの最大長が含まれています。このフィールドがない場合、最大長は課されません。
maxSizeG contains the maximum length of the value g that should be used. If this field is absent, then no maximum length is imposed.
maxSizeGには、使用する値gの最大長が含まれています。このフィールドがない場合、最大長は課されません。
keyParams contains the exact set of DSA for the key used to sign the message. This field is provided for completeness and to match the fields for Elliptic Curve; however, it is expected that usage of this field will be extremely rare.
keyParamsには、メッセージの署名に使用される鍵のDSAの正確なセットが含まれています。このフィールドは、完全性と楕円曲線のフィールドと一致させるために提供されています。ただし、このフィールドの使用は非常にまれであると予想されます。
This public key type is used with the DH key agreement algorithm.
この公開鍵タイプは、DH鍵合意アルゴリズムで使用されます。
The ASN.1 that is used for DH keys is defined below:
DHキーに使用されるASN.1は、以下で定義されています。
scap-pk-dh SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dh.&id
}
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-dh is a new SMIME-CAPS object. This object associates the existing object identifier (dhpublicnumber) used for the public key algorithm in the certificates (defined in [RFC3279] and [RFC5912]) with a new type defined above, DSAKeyCapabilities.
scap-pk-dhは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、証明書の公開鍵アルゴリズムに使用される既存のオブジェクト識別子（dhpublicnumber）（[RFC3279]および[RFC5912]で定義）を、上記で定義された新しいタイプDSAKeyCapabilitiesに関連付けます。
There are currently three Elliptic Curve Cryptography (ECC) public key object identifiers. These are EC, EC-DH, and Elliptic Curve Menezes-Qu-Vanstone (EC-MQV).
現在、3つの楕円曲線暗号（ECC）公開鍵オブジェクト識別子があります。これらは、EC、EC-DH、および楕円曲線Menezes-Qu-Vanstone（EC-MQV）です。
Almost all ECC keys that are contained in certificates today use the generic ECC public key format and identifier. This allows for the public key to be used both for key agreement and for signature validation (assuming the appropriate bits are in the certificate). The only reason for using one of the more specific public key identifier is if the user wants to restrict the usage of the ECC public key to a specific algorithm.
現在、証明書に含まれているほとんどすべてのECC鍵は、汎用のECC公開鍵形式と識別子を使用しています。これにより、公開鍵を鍵合意と署名検証の両方に使用できます（適切なビットが証明書にあると想定）。より具体的な公開キー識別子の1つを使用する唯一の理由は、ユーザーがECC公開キーの使用を特定のアルゴリズムに制限したい場合です。
For the generic ECC public key, the S/MIME capability that is advertised is a request for a specific group to be used.
汎用ECC公開鍵の場合、アドバタイズされるS / MIME機能は、使用される特定のグループの要求です。
The ASN.1 that is used for the generic ECC public key is defined below:
汎用ECC公開鍵に使用されるASN.1は、以下に定義されています。
scap-pk-ec SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ec.&id
}
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-ec is a new SMIME-CAPS object. This object associates the existing object identifier (id-ecPublicKey) used for the public key algorithm in the certificates (defined in [RFC5480] and [RFC5912]) with the new type EC-SMimeCaps.
scap-pk-ecは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、証明書（[RFC5480]および[RFC5912]で定義）の公開鍵アルゴリズムに使用される既存のオブジェクト識別子（id-ecPublicKey）を新しいタイプEC-SMimeCapsに関連付けます。
EC-SMimeCaps carries a sequence of at least one ECParameters structure. This allows for multiple curves to be requested in a single capability request. A maximum/minimum style of specifying sizes is not provided as much greater care is required in selecting a specific curve than is needed to create the parameters for a DSA/DH key. As specified in [RFC5480], for PKIX-compliant certificates, only the namedCurve choice of ECParameters is expected to be used.
EC-SMimeCapsは、少なくとも1つのECParameters構造のシーケンスを保持します。これにより、単一の機能要求で複数の曲線を要求できます。サイズを指定する最大/最小のスタイルは提供されていません。特定の曲線を選択する際には、DSA / DHキーのパラメーターを作成するために必要なよりもはるかに注意が必要です。 [RFC5480]で指定されているように、PKIX準拠の証明書では、ECParametersのnamedCurveの選択のみが使用されることが想定されています。
This public key type is used with the Elliptic Curve Diffie-Hellman key agreement algorithm.
この公開鍵タイプは、Elliptic Curve Diffie-Hellman鍵合意アルゴリズムで使用されます。
The ASN.1 that is used for EC-DH keys is defined below:
EC-DHキーに使用されるASN.1は、以下で定義されています。
scap-pk-ecDH SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecDH.&id
}
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-ecDH is a new SMIME-CAPS object. This object associates the existing object identifier (id-ecDH) used for the public key algorithm in the certificate (defined in [RFC5480] and [RFC5912]) with the same type structure used for public keys.
scap-pk-ecDHは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、証明書の公開鍵アルゴリズムに使用される既存のオブジェクト識別子（id-ecDH）（[RFC5480]および[RFC5912]で定義）を、公開鍵に使用されるのと同じタイプ構造に関連付けます。
This public key type is used with the Elliptic Curve MQV key agreement algorithm.
この公開鍵タイプは、Elliptic Curve MQV鍵合意アルゴリズムで使用されます。
The ASN.1 that is used for EC-MQV keys is defined below:
EC-MQVキーに使用されるASN.1は、以下で定義されています。
scap-pk-ecMQV SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecMQV.&id
}
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-pk-ecMQV is a new SMIME-CAPS object. This object associates the existing object identifier (id-ecMQV) used for the public key algorithm in the certificate (defined in [RFC5480] and [RFC5912]) with the same type structure used for public keys.
scap-pk-ecMQVは新しいSMIME-CAPSオブジェクトです。このオブジェクトは、証明書の公開鍵アルゴリズムに使用される既存のオブジェクト識別子（id-ecMQV）（[RFC5480]および[RFC5912]で定義）を、公開鍵に使用されるのと同じタイプ構造に関連付けます。
This document defines a new SMIMECapability for the RSASSA-PSS signature algorithm. One already exists in [RFC4055] where the parameters field is not used.
このドキュメントでは、RSASSA-PSS署名アルゴリズムの新しいSMIMECapabilityを定義しています。パラメータフィールドが使用されていない[RFC4055]にすでに存在しています。
When the S/MIME group defined an S/MIME capability for the RSASSA-PSS signature algorithm, it was done in the context of how S/MIME defines and uses S/MIME capabilities. When placed in an S/MIME message [SMIME-MSG] or in a certificate [RFC4262], it is always placed in a
S / MIMEグループがRSASSA-PSS署名アルゴリズムのS / MIME機能を定義したとき、S / MIMEがS / MIME機能を定義して使用する方法のコンテキストで行われました。 S / MIMEメッセージ[SMIME-MSG]または証明書[RFC4262]に配置される場合、常に
sequence of capabilities. This means that one could place the identifier for RSASSA-PSS in the sequence along with the identifier for MD5, SHA-1, and SHA-256. The assumption was then made that one could compute the matrix of all answers, and the publisher would support all elements in the matrix. This has the possibility that the publisher could accidentally publish a point in the matrix that is not supported.
機能のシーケンス。これは、RSASSA-PSSの識別子をMD5、SHA-1、およびSHA-256の識別子と一緒にシーケンスに配置できることを意味します。次に、すべての回答のマトリックスを計算でき、発行者がマトリックス内のすべての要素をサポートすると仮定しました。これにより、パブリッシャーがサポートされていないマトリックス内のポイントを誤ってパブリッシュする可能性があります。
In this situation, there is only a single item that is published. This means that we need to publish all of the associated information along with the identifier for the signature algorithm in a single entity. For this reason, we now define a new parameter type to be used as the SMIMECapability type, which contains a hash identifier and a mask identifier. The ASN.1 used for this is as follows:
この状況では、公開されるアイテムは1つだけです。つまり、関連するすべての情報と署名アルゴリズムの識別子を単一のエンティティで公開する必要があります。このため、ハッシュ識別子とマスク識別子を含むSMIMECapability型として使用される新しいパラメーター型を定義します。これに使用されるASN.1は次のとおりです。
scap-sa-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RsaSsa-Pss-sig-caps
IDENTIFIED BY sa-rsaSSA-PSS.&id
}
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg SMIMECapability{{ MaskAlgorithmSet }},
maskAlg SMIMECapability{{ ... }} OPTIONAL,
trailerField INTEGER DEFAULT 1
}
scap-mf-mgf1 SMIME-CAPS ::= {
TYPE SMIMECapability{{ ... }}
IDENTIFIED BY id-mgf1
}
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...}
In the above ASN.1, we have defined the following:
上記のASN.1では、以下を定義しています。
scap-sa-rsaSSA-PSS is a new SMIME-CAPS object. This object associates the existing object identifier (id-RSASSA-PSS) used for the signature algorithm (defined in [RFC4055] and [RFC5912]) with the new type RsaSsa-Pss-sig-caps.
scap-sa-rsaSSA-PSSは、新しいSMIME-CAPSオブジェクトです。このオブジェクトは、署名アルゴリズム（[RFC4055]および[RFC5912]で定義）に使用される既存のオブジェクト識別子（id-RSASSA-PSS）を新しいタイプRsaSsa-Pss-sig-capsに関連付けます。
RsaSsa-Pss-sig-caps carries the desired set of capabilities for the RSASSA-PSS signature algorithm. The fields of this type are:
RsaSsa-Pss-sig-capsは、RSASSA-PSS署名アルゴリズムに必要な一連の機能を備えています。このタイプのフィールドは次のとおりです。
hashAlg contains the S/MIME capability for the hash algorithm we are declaring we support with the RSASSA-PSS signature algorithm.
hashAlgには、RSASSA-PSS署名アルゴリズムでサポートすることを宣言しているハッシュアルゴリズムのS / MIME機能が含まれています。
maskAlg contains the S/MIME capability for the mask algorithm we are declaring we support with the RSASSA-PSS signature algorithm.
maskAlgには、RSASSA-PSS署名アルゴリズムでサポートすることを宣言しているマスクアルゴリズムのS / MIME機能が含まれています。
trailerField specifies which trailer field algorithm is being supported. This MUST be the value 1.
trailerFieldは、サポートされているトレーラーフィールドアルゴリズムを指定します。これは値1でなければなりません。
NOTE: In at least one iteration of the design, we used a sequence of hash identifiers and a sequence of masking functions and again made the assumption that the entire matrix would be supported. This has been removed at this point since the original intent of S/MIME capabilities is that one should be able to do a binary comparison of the DER encoding of the field and determine a specific capability was published. We could return to using the sequence if we wanted to lose the ability to do a binary compare but needed to shorten the encodings. This does not currently appear to be an issue at this point.
注：設計の少なくとも1回の反復で、一連のハッシュ識別子と一連のマスキング関数を使用し、マトリックス全体がサポートされることを再度想定しました。 S / MIME機能の本来の目的は、フィールドのDERエンコードのバイナリ比較を実行し、特定の機能が公開されていることを確認できるようにする必要があるため、この時点で削除されました。バイナリ比較を実行する機能を失いたいが、エンコーディングを短くする必要がある場合は、シーケンスの使用に戻ることができます。現在のところ、これは問題ではないようです。
This document provides new fields that can be placed in an S/MIME capabilities sequence. There are number of considerations that need to be taken into account when doing this.
このドキュメントは、S / MIME機能シーケンスに配置できる新しいフィールドを提供します。これを行う際に考慮する必要のある考慮事項がいくつかあります。
As mentioned above, we have defined data structures to be associated with object identifiers in cases where an association already exists. When either encoding or decoding structures, care needs to be taken that the association used is one appropriate for the location in the surrounding ASN.1 structure. This means that one needs to make sure that only public keys are placed in public key locations, signatures are placed in signature locations, and S/MIME capabilities are placed in SMIMECapability locations. Failure to do so will create decode errors at best and can cause incorrect behavior at worst.
上記のように、関連付けが既に存在する場合にオブジェクト識別子に関連付けるデータ構造を定義しました。構造をエンコードまたはデコードする場合、使用される関連付けが周囲のASN.1構造内の場所に適したものであるように注意する必要があります。これは、公開鍵のみが公開鍵の場所に配置され、署名が署名場所に配置され、S / MIME機能がSMIMECapabilityの場所に配置されていることを確認する必要があることを意味します。そうしないと、せいぜいデコードエラーが発生し、最悪の場合は正しくない動作を引き起こす可能性があります。
The more specific the information that is provided in an S/MIME Capabilities field, the better the end results are going to be. Specifying a signature algorithm means that there are no questions for the receiver that the signature algorithm is supported. Signature algorithms can be implied by specifying both public key algorithms and hash algorithms together. If the list includes RSA v1.5, EC-DSA, SHA-1, and SHA-256, the implication is that all four values in the cross section are supported by the sender. If the sender does not support EC-DSA with SHA-1, this would lead to a situation where the recipient uses a signature algorithm that the sender does not support. Omitting SHA-1 from the list may lead to the problem where both entities support RSA v1.5 with SHA-1 as their only common algorithm, but this is no longer discoverable by the recipient.
S / MIME Capabilitiesフィールドで提供される情報が具体的であるほど、最終結果は良くなります。署名アルゴリズムを指定することは、署名アルゴリズムがサポートされていることを受信者に質問する必要がないことを意味します。署名アルゴリズムは、公開鍵アルゴリズムとハッシュアルゴリズムの両方を一緒に指定することで暗示されます。リストにRSA v1.5、EC-DSA、SHA-1、SHA-256が含まれている場合、クロスセクションの4つの値すべてが送信者によってサポートされていることを意味します。送信者がSHA-1を使用したEC-DSAをサポートしていない場合、受信者が送信者がサポートしていない署名アルゴリズムを使用する状況になります。リストからSHA-1を省略すると、両方のエンティティが唯一の共通アルゴリズムとしてSHA-1を使用したRSA v1.5をサポートするという問題が発生する可能性がありますが、受信者はこれを発見できなくなりました。
As a general rule, providing more information about the algorithms that are supported is preferable. The more choices that are provided the recipient, the greater the likelihood that a common algorithm with good security can be used by both parties. However, one should avoid being exhaustive in providing the list of algorithms to the recipient. The greater the number of algorithms that are passed, the more difficult it is for a recipient to make intelligent decisions about which algorithm to use. This is a more significant problem when there are more than two entities involved in the "negotiation" of a common algorithm to be used (such as sending an encrypted S/MIME message where a common content encryption algorithm is needed). The larger the set of algorithms and the more recipients involved, the more memory and processing time will be needed in order to complete the decision-making process.
原則として、サポートされているアルゴリズムに関する詳細情報を提供することをお勧めします。受信者に提供される選択肢が多いほど、セキュリティが優れた共通のアルゴリズムを両方の当事者が使用できる可能性が高くなります。ただし、受信者にアルゴリズムのリストを提供することを徹底することは避けてください。渡されるアルゴリズムの数が多いほど、どのアルゴリズムを使用するかについて受信者がインテリジェントな決定を行うことが難しくなります。これは、使用される一般的なアルゴリズムの「交渉」に関与するエンティティが3つ以上ある場合（より一般的なコンテンツ暗号化アルゴリズムが必要な場合に暗号化されたS / MIMEメッセージを送信する場合など）に、より重大な問題になります。アルゴリズムのセットが大きくなり、関係する受信者が増えるほど、意思決定プロセスを完了するために必要なメモリと処理時間が増えます。
The S/MIME capabilities are defined so that the order of algorithms in the sequence is meant to encode a preference order by the sender of the sequence. Many entities will ignore the order preference when making a decision either by using their own preferred order or using a random decision from a matrix.
S / MIME機能は、シーケンス内のアルゴリズムの順序が、シーケンスの送信者による優先順序をエンコードするように定義されています。多くのエンティティは、独自の優先順位を使用するか、マトリックスからのランダムな決定を使用して決定を行うときに、順序の優先順位を無視します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W.、and R. Housley、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3279、April 2002。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、2005年6月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[NIST-SIZES] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management -- Part 1: General", NIST Special Publication 800-57, March 2007.
[NIST-SIZES] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「鍵管理の推奨事項-パート1：一般」、NIST特別刊行物800-57、 2007年3月。
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, December 2005.
[RFC4262] Santesson、S。、「X / 509 Certificate Extension for Secure / Multipurpose Internet Mail Extensions（S / MIME）Capabilities」、RFC 4262、2005年12月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912] Hoffman、P.およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、2010年6月。
[RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011.
[RFC6277] Santesson、S.およびP. Hallam-Baker、「Online Certificate Status Protocol Algorithm Agility」、RFC 6277、2011年6月。
[SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME-MSG] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[SMIMEv3-MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[SMIMEv3-MSG] Ramsdell、B。、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。
This appendix contains a module compatible with the work done to update the PKIX ASN.1 modules to recent versions of the ASN.1 specifications [RFC5912]. This appendix is to be considered informational per the current direction of the PKIX working group.
この付録には、PKIX ASN.1モジュールをASN.1仕様の最新バージョン[RFC5912]に更新するために行われた作業と互換性のあるモジュールが含まれています。この付録は、PKIXワーキンググループの現在の方針に従って情報提供と見なされます。
PUBLIC-KEY-SMIME-CAPABILITIES
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pubKeySMIMECaps-08(78) }
DEFINITIONS ::=
BEGIN
IMPORTS
SMIME-CAPS, PUBLIC-KEY, SMIMECapability
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
pk-rsa, pk-dsa, pk-dh, pk-ec, pk-ecDH, pk-ecMQV, ECParameters
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
pk-rsaSSA-PSS, pk-rsaES-OAEP, sa-rsaSSA-PSS,
HashAlgorithms, id-mgf1
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54)}
;
--
-- Define a set containing all of the S/MIME capabilities defined
-- by this document.
--
SMimeCaps SMIME-CAPS ::= {
PubKeys-SMimeCaps |
scap-sa-rsaSSA-PSS
}
PubKeys-SMimeCaps SMIME-CAPS ::= {
scap-pk-rsa | scap-pk-rsaSSA-PSS |
scap-pk-dsa |
scap-pk-ec | scap-pk-ecDH | scap-pk-ecMQV
}
｝
-- -- We defined RSA keys from the modules in RFC 3279 and RFC 4055. --
--RFC 3279およびRFC 4055のモジュールからRSAキーを定義しました。-
scap-pk-rsa SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsa.&id
}
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
scap-pk-rsaES-OAEP SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaES-OAEP.&id
}
scap-pk-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RSAKeyCapabilities
IDENTIFIED BY pk-rsaSSA-PSS.&id
}
scap-sa-rsaSSA-PSS SMIME-CAPS ::= {
TYPE RsaSsa-Pss-sig-caps
IDENTIFIED BY sa-rsaSSA-PSS.&id
}
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg SMIMECapability{{ MaskAlgorithmSet }},
maskAlg SMIMECapability{{ ... }} OPTIONAL,
trailerField INTEGER DEFAULT 1
}
scap-mf-mgf1 SMIME-CAPS ::= {
TYPE SMIMECapability{{ ... }}
IDENTIFIED BY id-mgf1
}
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgf1, ...}
-- -- We define DH/DSA keys from the module in RFC 3279. --
--RFC 3279のモジュールからDH / DSAキーを定義します。-
scap-pk-dsa SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dsa.&id
}
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
scap-pk-dh SMIME-CAPS ::= {
TYPE DSAKeyCapabilities
IDENTIFIED BY pk-dh.&id
}
-- -- We define Elliptic Curve keys from the module in RFC 3279. --
--RFC 3279のモジュールから楕円曲線キーを定義します。-
scap-pk-ec SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ec.&id
}
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
scap-pk-ecDH SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecDH.&id
}
scap-pk-ecMQV SMIME-CAPS ::= {
TYPE EC-SMimeCaps
IDENTIFIED BY pk-ecMQV.&id
}
END
終わり
This appendix contains the normative ASN.1 module for this document.
この付録には、このドキュメントの規範的なASN.1モジュールが含まれています。
PUBLIC-KEY-SMIME-CAPABILITIES-88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pubKeySMIMECaps-88(77) }
DEFINITIONS ::=
BEGIN
IMPORTS
ECParameters
FROM PKIX1Algorithms2008
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
45 }
id-mgf1
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
;
；
-- -- We define RSA keys from the modules in RFC 3279 and RFC 4055. --
--RFC 3279およびRFC 4055のモジュールからRSAキーを定義します。-
RSAKeyCapabilities ::= SEQUENCE {
minKeySize RSAKeySize,
maxKeySize RSAKeySize OPTIONAL
}
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 |
8192 | 15360, ...)
RsaSsa-Pss-sig-caps ::= SEQUENCE {
hashAlg AlgorithmIdentifier, maskAlg AlgorithmIdentifier OPTIONAL, trailerField INTEGER DEFAULT 1 }
hashAlg AlgorithmIdentifier、maskAlg AlgorithmIdentifier OPTIONAL、trailerField INTEGER DEFAULT 1}
-- -- We define DH/DSA keys from the module in RFC 3279. --
--RFC 3279のモジュールからDH / DSAキーを定義します。-
DSAKeyCapabilities ::= CHOICE {
keySizes [0] SEQUENCE {
minKeySize DSAKeySize,
maxKeySize DSAKeySize OPTIONAL,
maxSizeP [1] INTEGER OPTIONAL,
maxSizeQ [2] INTEGER OPTIONAL,
maxSizeG [3] INTEGER OPTIONAL
},
keyParams [1] pk-dsa.&Params
}
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 )
-- -- We define Elliptic Curve keys from the module in RFC 3279. --
--RFC 3279のモジュールから楕円曲線キーを定義します。-
EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters
END
終わり
A future revision of [RFC5912] should be done at some point to expand the definition of the PUBLIC-KEY class and allow for an SMIMECapability to be included in the class definition. This would encourage people to think about this as an issue when defining new public key structures in the future.
[RFC5912]の将来の改訂は、PUBLIC-KEYクラスの定義を拡張し、SMIMECapabilityをクラス定義に含めることができるようにするために、ある時点で行う必要があります。これは、将来的に新しい公開鍵構造を定義するときに、これを問題として考えることを人々に促すでしょう。
Author's Address
著者のアドレス
Jim Schaad Soaring Hawk Consulting
ジムシャードソアリングホークコンサルティング
EMail: ietf@augustcellars.com