RFC5035 日本語訳
5035 Enhanced Security Services (ESS) Update: Adding CertID AlgorithmAgility. J. Schaad. August 2007. (Format: TXT=32674 bytes) (Updates RFC2634) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Schaad Request for Comments: 5035 Soaring Hawk Consulting Updates: 2634 August 2007 Category: Standards Track
Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5035年の高く昇っているタカのコンサルティングは以下をアップデートします。 2634 2007年8月のカテゴリ: 標準化過程
Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility
警備の強化サービス(ESS)は以下をアップデートします。 CertIDアルゴリズムの機敏さを加えます。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose.
S/MIMEのためのEnhanced Security Servicesが記録するオリジナル(RFC2634)では、署名で合法化に使用されるために暗号で証明書をリンクするための構造は紹介されました。 この構造は、SHA-1を使用するために配線されました。 このドキュメントは、アルゴリズムの機敏さを持つために構造を考慮して、このために新しい属性を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Updates to RFC 2634 . . . . . . . . . . . . . . . . . . . 2
2. Replace Section 5.4 'Signing Certificate Attribute
Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Insert New Section 5.4.1 'Signing Certificate Attribute
Definition Version 2' . . . . . . . . . . . . . . . . . . . . 4
4. Insert New Section 5.4.1.1 'Certificate Identification
Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Insert New Section 5.4.2 'Signing Certificate Attribute
Definition Version 1' . . . . . . . . . . . . . . . . . . . . 7
6. Insert New Section 5.4.2.1 'Certificate Identification
Version 1' . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 記法. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2。 RFC2634.2 2に、アップデートします。 セクション5.4'署名証明書属性定義'.3 3を取り替えてください。 新しいセクション5.4.1'署名証明書属性定義バージョン2'.4 4を挿入してください。 新しいセクション5.4.1.1'証明書識別バージョン2'.5 5を挿入してください。 新しいセクション5.4.2'署名証明書属性定義バージョン1'.7 6を挿入してください。 新しいセクション5.4.2.1'証明書識別バージョン1'.8 7を挿入してください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 8。 引用規格. . . . . . . . . . . . . . . . . . . . . 10付録A.ASN.1モジュール. . . . . . . . . . . . . . . . . . . . 11
Schaad Standards Track [Page 1] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[1ページ]
1. Introduction
1. 序論
In the original Enhanced Security Services (ESS) for S/MIME document [ESS], a structure for cryptographically linking the certificate to be used in validation with the signature was defined. This structure, called ESSCertID, identifies a certificate by its hash. The structure is hardwired to use a SHA-1 hash value. The recent attacks on SHA-1 require that we define a new attribute that allows for the use of different algorithms. This document performs that task.
S/MIMEドキュメント[ESS]のためのオリジナルのEnhanced Security Services(ESS)では、署名で合法化に使用されるために暗号で証明書をリンクするための構造は定義されました。 ESSCertIDと呼ばれるこの構造はハッシュで証明書を特定します。 構造は、SHA-1ハッシュ値を使用するために配線されます。 SHA-1に対する最近の攻撃は、私たちが異なったアルゴリズムの使用を考慮する新しい属性を定義するのを必要とします。このドキュメントはそのタスクを実行します。
This document defines the structure ESSCertIDv2 along with a new attribute SigningCertificateV2, which uses the updated structure. This document allows for the structure to have algorithm agility by including an algorithm identifier and defines a new signed attribute to use the new structure.
このドキュメントは新しい属性SigningCertificateV2に伴う構造ESSCertIDv2を定義します。(SigningCertificateV2はアップデートされた構造を使用します)。 このドキュメントは、アルゴリズム識別子を含んでいることによってアルゴリズムの機敏さを持つために構造を考慮して、新しい構造を使用するために新しい署名している属性を定義します。
This document specifies the continued use of ESSCertID to ensure compatibility when SHA-1 is used for certificate disambiguation.
このドキュメントは、SHA-1が証明書曖昧さの解消に使用されるとき、互換性を確実にするためにESSCertIDの継続的な使用を指定します。
1.1. Notation
1.1. 記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Updates to RFC 2634
1.2. RFC2634へのアップデート
This document updates Section 5.4 of RFC 2634. Once the updates are applied, the revised section will have the following structure:
このドキュメントはRFC2634のセクション5.4をアップデートします。 アップデートがいったん適用されていると、改訂されたセクションには、以下の構造があるでしょう:
5.4 Signing Certificate Attribute Definitions
5.4 署名証明書属性定義
5.4.1 Signing Certificate Attribute Definition Version 2
5.4.1 証明書属性定義がバージョン2であると署名すること。
5.4.1.1 Certificate Identification Version 2
5.4.1.1 証明書識別バージョン2
5.4.2 Signing Certificate Attribute Definition Version 1
5.4.2 証明書属性定義がバージョン1であると署名すること。
5.4.2.1 Certificate Identification Version 1
5.4.2.1 証明書識別バージョン1
In addition, the ASN.1 module in Appendix A is replaced.
さらに、Appendix AのASN.1モジュールを取り替えます。
Schaad Standards Track [Page 2] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[2ページ]
2. Replace Section 5.4 'Signing Certificate Attribute Definitions'
2. '署名証明書属性定義'というセクション5.4を取り替えてください。
5.4 Signing Certificate Attribute Definitions
5.4 署名証明書属性定義
The signing certificate attribute is designed to prevent simple substitution and re-issue attacks, and to allow for a restricted set of certificates to be used in verifying a signature.
署名証明書属性は、簡単な代替と再発行攻撃を防いで、制限されたセットの証明書が署名について確かめる際に使用されるのを許容するように設計されています。
Two different attributes exist for this due to a flaw in the original design. The only substantial difference between the two attributes is that SigningCertificateV2 allows for hash algorithm agility, while SigningCertificate forces the use of the SHA-1 hash algorithm. With the recent advances in the ability to create hash collisions for SHA-1, it is wise to move forward sooner rather than later.
2つの異なった属性が当初の設計における欠点のためこれのために存在しています。 2つの属性の唯一のかなりの違いがSigningCertificateV2がハッシュアルゴリズムの機敏さを考慮するということです、SigningCertificateはSHA-1ハッシュアルゴリズムの使用を強制しますが。 SHA-1のためにハッシュ衝突を作成する能力における最近の進歩に、後でというよりむしろより早く前方へ動くのは賢明です。
When the SHA-1 hash function is used, the SigningCertificate attribute MUST be used. The SigningCertificateV2 attribute MUST be used if any algorithm other than SHA-1 is used and SHOULD NOT be used for SHA-1. Applications SHOULD recognize both attributes as long as they consider SHA-1 able to distinguish between two different certificates, (i.e., the possibility of a collision is sufficiently low). If both attributes exist in a single message, they are independently evaluated.
SHA-1ハッシュ関数が使用されているとき、SigningCertificate属性を使用しなければなりません。 SHA-1において、使用されるSHA-1とSHOULD NOT以外の何かアルゴリズムが使用されているなら、SigningCertificateV2属性を使用しなければなりません。 SHA-1が2通の異なった証明書を見分けることができると考える限り、アプリケーションSHOULDは両方の属性を認識します、(すなわち、衝突が十分低いaの可能性。) 両方の属性がただ一つのメッセージに存在しているなら、それらは独自に評価されます。
Four cases exist that need to be taken into account when using this attribute for correct processing:
正しい処理にこの属性を使用するとき、考慮に入れられる必要がある4つのケースが存在しています:
1. Signature validates and the hashes match: This is the success
case.
1. 署名は有効にして、ハッシュは合わせます: これは成功例です。
2. Signature validates and the hashes do not match: In this case,
the certificate contained the correct public key, but the
certificate containing the public key is not the one that the
signer intended to be used. In this case the application should
attempt a search for a different certificate with the same public
key and for which the hashes match. If no such certificate can
be found, this is a failure case.
2. 署名は有効にして、ハッシュは合わせません: この場合、証明書は正しい公開鍵を含みましたが、公開鍵を含む証明書は署名者が使用されるつもりであったものではありません。 この場合、アプリケーションは、同じ公開鍵がある異なった証明書の検索を試みて、ハッシュが合っているもののためにそうするべきです。 どんなそのような証明書も見つけることができないなら、これは失敗そうです。
3. Signature fails validation and the hashes match: In this case, it
can be assumed that the signature has been modified in some
fashion. This is a failure case.
3. 署名は合法化に失敗します、そして、ハッシュは合っています: この場合、署名が何らかのファッションで変更されたと思うことができます。 これは失敗そうです。
4. Signature fails validation and the hashes do not match: In this
case, it can be either that the signature has been modified, or
that the wrong certificate has been used. Applications should
attempt a search for a different certificate that matches the
hash value in the attribute and use the new certificate to retry
the signature validation.
4. 署名は合法化に失敗します、そして、ハッシュは合っていません: この場合、署名が変更されたか、または間違った証明書が使用されたのが、どちらかであることができます。 アプリケーションは、属性におけるハッシュ値に合っている異なった証明書のために検索を試みて、署名合法化を再試行するのに新しい証明書を使用するべきです。
Schaad Standards Track [Page 3] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[3ページ]
3. Insert New Section 5.4.1 'Signing Certificate Attribute Definition
Version 2'
3. 新しいセクション5.4.1'署名証明書属性定義バージョン2'を挿入してください。
5.4.1 Signing Certificate Attribute Definition Version 2
5.4.1 証明書属性定義がバージョン2であると署名すること。
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of certificates to be used in verifying a signature.
署名証明書属性は、簡単な代替と再発行攻撃を防いで、制限されたセットの証明書が署名について確かめる際に使用されるのを許容するように設計されています。
SigningCertificateV2 is identified by the OID:
SigningCertificateV2はOIDによって特定されます:
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
イド-aa-signingCertificateV2オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)47をメンバーと同じくらい具体化させます。
The attribute has the ASN.1 definition:
属性に、ASN.1定義があります:
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificateV2:、:= 系列本命SEQUENCE OF ESSCertIDv2、方針SEQUENCE OF PolicyInformation OPTIONAL
certs
contains the list of certificates that are to be used in
validating the message. The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 for this
certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in
the SignerInfo, the issuerSerial field MAY be omitted. The
certificate identified is used during the signature verification
process. If the hash of the certificate does not match the
certificate used to verify the signature, the signature MUST be
considered invalid.
本命はメッセージを有効にする際に使用されることになっている証明書のリストを含みます。 証明書識別子の系列で特定された最初の証明書は署名について確かめるのに使用される証明書であるに違いありません。 この証明書SHOULDのためのESSCertIDv2のコード化はissuerSerial分野を含んでいます。 他の規制が、issuerAndSerialNumberがSignerInfoに存在するのを確実にするなら、issuerSerial分野は省略されるかもしれません。 特定された証明書は署名照合プロセスの間、使用されます。 証明書のハッシュが署名について確かめるのに使用される証明書に合っていないなら、無効であると署名を考えなければなりません。
If more than one certificate is present, subsequent certificates
limit the set of certificates that are used during validation.
Certificates can be either attribute certificates (limiting
authorizations) or public key certificates (limiting path
validation). The issuerSerial field (in the ESSCertIDv2
structure) SHOULD be present for these certificates, unless the
client who is validating the signature is expected to have easy
access to all the certificates required for validation. If only
the signing certificate is present in the sequence, there are no
restrictions on the set of certificates used in validating the
signature.
1通以上の証明書が存在しているなら、その後の証明書は合法化の間に使用される証明書のセットを制限します。 証明書は、属性証明書(承認を制限する)か公開鍵証明書のどちらかであるかもしれません(経路合法化を制限して)。 issuerSerialは(ESSCertIDv2構造の)SHOULDをさばきます。これらの証明書のために存在してください、署名を有効にしているクライアントが合法化に必要であるすべての証明書にたやすく近づく手段を持っていないと予想される場合。 署名証明書だけが系列で存在しているなら、制限が全く署名を有効にする際に使用される証明書のセットにありません。
Schaad Standards Track [Page 4] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[4ページ]
policies
contains a sequence of policy information terms that identify
those certificate policies that the signer asserts apply to the
certificate, and under which the certificate should be relied
upon. This value suggests a policy value to be used in the
relying party's certification path validation. The definition of
PolicyInformation can be found in [RFC3280].
方針は適用される署名者が証明書に断言するそれらの証明書方針を特定して、証明書を当てにされるべきである方針情報諸条件の系列を含んでいます。 この値は、信用パーティーの証明経路合法化に使用されるために保険価額を示します。 [RFC3280]でPolicyInformationの定義を見つけることができます。
If present, the SigningCertificateV2 attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include multiple instances of the SigningCertificateV2 attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificateV2 attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在しているなら、SigningCertificateV2属性は署名している属性であるに違いありません。 それは未署名の属性であるはずがありません。 CMSはSignedAttributesをSET OF Attributeと定義します。 SignerInfoはSigningCertificateV2属性の複数のインスタンスを含んではいけません。 署名している属性がattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 SigningCertificateV2属性はAttributeValueのただ一つのインスタンスだけを含まなければなりません。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
4. Insert New Section 5.4.1.1 'Certificate Identification Version 2'
4. 新しいセクション5.4.1.1'証明書識別バージョン2'を挿入してください。
Insert the following text as a new section.
新しいセクションとして以下のテキストを挿入してください。
5.4.1.1 Certificate Identification Version 2
5.4.1.1 証明書識別バージョン2
The best way to identify certificates is an often-discussed issue. The ESSCertIDv2 structure supplies two different fields that are used for this purpose.
証明書を特定する最も良い方法はしばしば議論された問題です。 ESSCertIDv2構造はこのために使用される2つの異なった野原を供給します。
The hash of the entire certificate allows for a verifier to check that the certificate used in the verification process was the same certificate the signer intended. Hashes are convenient in that they are frequently used by certificate stores as a method of indexing and retrieving certificates as well. The use of the hash is required by this structure since the detection of substituted certificates is based on the fact they would map to different hash values.
全体の証明書のハッシュは、検証が、検証プロセスで使用される証明書が署名者が意図した同じ証明書であったのをチェックするのを許容します。 それらがまた、証明書に索引をつけて、検索するメソッドとして頻繁に証明書店によって使用されるので、ハッシュは便利です。 代入された証明書の検出がそれらが異なったハッシュ値に写像する事実に基づいているので、ハッシュの使用はこの構造によって必要とされます。
The issuer/serial number pair is the method of identification of certificates used in [RFC3280]. That document imposes a restriction for certificates that the issuer distinguished name must be present. The issuer/serial number pair would therefore normally be sufficient to identify the correct signing certificate. (This assumes the same issuer name is not reused from the set of trust anchors.) The issuer/serial number pair can be stored in the sid field of the SignerInfo object. However, the sid field is not covered by the signature. In the cases where the issuer/serial number pair is not used in the sid or the issuer/serial number pair needs to be signed, it SHOULD be placed in the issuerSerial field of the ESSCertIDv2 structure.
発行人/通し番号組は[RFC3280]で使用される証明書の識別のメソッドです。 そのドキュメントは証明書のための発行人分類名が存在していなければならないという制限を課します。 したがって、通常、発行人/通し番号組は正しい署名証明書を特定するために十分でしょう。 (これは、同じ発行人名が信頼アンカーのセットから再利用されないと仮定します。) SignerInfoオブジェクトのsid分野に発行人/通し番号組を保存できます。 しかしながら、sid分野は署名でカバーされていません。 発行人/通し番号組がsidで使用されないか、または発行人/通し番号組が、署名される必要があって、それがSHOULDである場合では、ESSCertIDv2構造のissuerSerial分野に置かれてください。
Schaad Standards Track [Page 5] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[5ページ]
Attribute certificates and additional public key certificates containing information do not have an issuer/serial number pair represented anywhere in a SignerInfo object. When an attribute certificate or an additional public key certificate is not included in the SignedData object, it becomes much more difficult to get the correct set of certificates based only on a hash of the certificate. For this reason, these certificates SHOULD be identified by the IssuerSerial object.
情報を含む属性証明書と追加公開鍵証明書で、SignerInfoオブジェクトで何処にも発行人/通し番号組の代理をしません。 属性証明書か追加公開鍵証明書がSignedDataオブジェクトに含まれていないとき、正しいセットの証明書を証明書のハッシュだけに基づかせているのははるかに難しくなります。 この理由で、これらはSHOULDを証明します。IssuerSerialオブジェクトで、特定されます。
This document defines a certificate identifier as:
このドキュメントは証明書識別子を以下と定義します。
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
DEFAULT {algorithm id-sha256},
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertIDv2:、:= 系列hashAlgorithm AlgorithmIdentifier DEFAULTアルゴリズムイド-sha256、certHash Hash、issuerSerial IssuerSerial OPTIONAL
Hash ::= OCTET STRING
以下を論じ尽くしてください:= 八重奏ストリング
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
IssuerSerial:、:= 系列発行人GeneralNames、serialNumber CertificateSerialNumber
The fields of ESSCertIDv2 are defined as follows:
ESSCertIDv2の分野は以下の通り定義されます:
hashAlgorithm
contains the identifier of the algorithm used in computing
certHash.
hashAlgorithmはcertHashを計算する際に使用されるアルゴリズムに関する識別子を含んでいます。
certHash
is computed over the entire DER-encoded certificate (including the
signature) using the SHA-1 algorithm.
certHashは、全体のDERによってコード化された証明書(署名を含んでいる)に関してSHA-1アルゴリズムを使用することで計算されます。
issuerSerial
holds the identification of the certificate. The issuerSerial
would normally be present unless the value can be inferred from
other information (e.g., the sid field of the SignerInfo object).
issuerSerialは証明書の識別を保持します。 他の情報(例えば、SignerInfoオブジェクトのsid分野)から値を推論できないなら、通常、issuerSerialは存在しているでしょう。
The fields of IssuerSerial are defined as follows:
IssuerSerialの分野は以下の通り定義されます:
issuer
contains the issuer name of the certificate. For non-attribute
certificates, the issuer MUST contain only the issuer name from
the certificate encoded in the directoryName choice of
GeneralNames. For attribute certificates, the issuer MUST contain
the issuer name field from the attribute certificate.
発行人は証明書の発行人名を含みます。 非属性証明書に関しては、発行人はGeneralNamesのdirectoryName選択でコード化された証明書からの発行人名だけを含まなければなりません。 属性証明書に関しては、発行人は属性証明書からの発行人名前欄を含まなければなりません。
Schaad Standards Track [Page 6] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[6ページ]
serialNumber
holds the serial number that uniquely identifies the certificate
for the issuer.
serialNumberは唯一発行人のための証明書を特定する通し番号を保持します。
5. Insert New Section 5.4.2 'Signing Certificate Attribute Definition
Version 1'
5. 新しいセクション5.4.2'署名証明書属性定義バージョン1'を挿入してください。
(Note: This section does not present new material. This section contains the original contents of Section 5.4 in [ESS], which are retained with minor changes in this specification to achieve backwards compatibility.)
(以下に注意してください。 このセクションは新素材を贈りません。 このセクションは[ESS]にセクション5.4に関するオリジナルコンテンツを含みます。(それは、この仕様に基づくマイナーチェンジで保有されて、)互換性を後方に獲得します。)
Insert the following text as a new section.
新しいセクションとして以下のテキストを挿入してください。
5.4.2 Signing Certificate Attribute Definition Version 1
5.4.2 証明書属性定義がバージョン1であると署名すること。
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of certificates to be used in verifying a signature.
署名証明書属性は、簡単な代替と再発行攻撃を防いで、制限されたセットの証明書が署名について確かめる際に使用されるのを許容するように設計されています。
The definition of SigningCertificate is
SigningCertificateの定義はそうです。
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificate:、:= 系列本命SEQUENCE OF ESSCertID、方針SEQUENCE OF PolicyInformation OPTIONAL
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
イド-aa-signingCertificateオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)12をメンバーと同じくらい具体化させます。
The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertID for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid.
証明書識別子の系列で特定された最初の証明書は署名について確かめるのに使用される証明書であるに違いありません。 この証明書SHOULDのためのESSCertIDのコード化はissuerSerial分野を含んでいます。 他の規制が、issuerAndSerialNumberがSignerInfoに存在するのを確実にするなら、issuerSerial分野は省略されるかもしれません。 特定された証明書は署名照合プロセスの間、使用されます。 証明書のハッシュが署名について確かめるのに使用される証明書に合っていないなら、無効であると署名を考えなければなりません。
If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of certificates that are used during validation. Certificates can be either attribute certificates (limiting authorizations) or public key certificates (limiting path validation). The issuerSerial field (in the ESSCertID structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have
1通以上の証明書がESSCertIDsの系列で存在しているなら、最初のものの後の証明書は合法化の間に使用される証明書のセットを制限します。 証明書は、属性証明書(承認を制限する)か公開鍵証明書のどちらかであるかもしれません(経路合法化を制限して)。 issuerSerialがさばく、(ESSCertID構造) SHOULDでは、これらの証明書のために存在してください、署名を有効にしているクライアントが持つために期待していない場合
Schaad Standards Track [Page 7] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[7ページ]
easy access to all the certificates required for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of certificates used in validating the signature.
すべての証明書への簡単なアクセスが合法化に必要です。 署名証明書だけが系列で存在しているなら、制限が全く署名を有効にする際に使用される証明書のセットにありません。
The sequence of policy information terms identifies those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation.
方針情報用語の系列は証明書に適用して、署名者が、断言する証明書を当てにされるべきであるそれらの証明書方針を特定します。 この値は、信用パーティーの証明経路合法化に使用されるために保険価額を示します。
If present, the SigningCertificate attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. Cryptographic Message Syntax (CMS) defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include multiple instances of the SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificate attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在しているなら、SigningCertificate属性は署名している属性であるに違いありません。 それは未署名の属性であるはずがありません。 暗号のMessage Syntax(CMS)はSignedAttributesをSET OF Attributeと定義します。 SignerInfoはSigningCertificate属性の複数のインスタンスを含んではいけません。 署名している属性がattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 SigningCertificate属性はAttributeValueのただ一つのインスタンスだけを含まなければなりません。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
6. Insert New Section 5.4.2.1 'Certificate Identification Version 1'
6. 新しいセクション5.4.2.1'証明書識別バージョン1'を挿入してください。
(Note: This section does not present new material. This section contains the original contents of Section 5.4 in [ESS], which are retained with minor changes in this specification to achieve backwards compatibility.)
(以下に注意してください。 このセクションは新素材を贈りません。 このセクションは[ESS]にセクション5.4に関するオリジナルコンテンツを含みます。(それは、この仕様に基づくマイナーチェンジで保有されて、)互換性を後方に獲得します。)
Delete old Section 5.4.1
古いセクション5.4.1を削除してください。
Insert the following as new text
新しいテキストとして以下を挿入してください。
5.4.2.1 Certificate Identification Version 1
5.4.2.1 証明書識別バージョン1
Certificates are uniquely identified using the information in the ESSCertID structure. Discussion can be found in Section 5.4.1.1.
証明書は、ESSCertID構造で情報を使用することで唯一特定されます。 セクション5.4.1で.1に議論を見つけることができます。
This document defines a certificate identifier as:
このドキュメントは証明書識別子を以下と定義します。
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID:、:= 系列certHashハッシュで、issuerSerial IssuerSerial任意です。
Schaad Standards Track [Page 8] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[8ページ]
The fields of ESSCertID are defined as follows:
ESSCertIDの分野は以下の通り定義されます:
certHash
is computed over the entire DER-encoded certificate (including the
signature).
certHashは全体のDERによってコード化された証明書に関して計算されます(署名を含んでいて)。
issuerSerial
holds the identification of the certificate. This field would
normally be present unless the value can be inferred from other
information (e.g., the sid field of the SignerInfo object).
issuerSerialは証明書の識別を保持します。 他の情報(例えば、SignerInfoオブジェクトのsid分野)から値を推論できないなら、通常、この分野は存在しているでしょう。
The fields of IssuerSerial are discussed in Section 5.4.1.1
セクション5.4.1でIssuerSerialの分野について議論する、.1
7. Security Considerations
7. セキュリティ問題
This document is designed to address the security issue of a substituted certificate used by the validator. If a different certificate is used by the validator than the signer, the validator may not get the correct result. An example of this would be that the original certificate was revoked and a new certificate with the same public key was issued for a different individual. Since the issuer/ serial number field is not protected, the attacker could replace this and point to the new certificate and validation would be successful.
このドキュメントは、validatorによって使用された代入された証明書の安全保障問題を扱うように設計されています。 署名者と異なった証明書がvalidatorによって使用されるなら、validatorは正しい結果を得ないかもしれません。 この例はオリジナルの証明書を取り消して、異なった個人のために同じ公開鍵がある新しい証明書を発行したということでしょう。 発行人/通し番号分野が保護されないので、攻撃者は、これを取り替えて、新しい証明書を示すことができました、そして、合法化はうまくいっているでしょう。
The attributes defined in this document are to be placed in locations that are protected by the signature. This attribute does not provide any additional security if placed in an unsigned or un-authenticated location.
本書では定義された属性は署名で保護される位置に置かれることです。 未署名の、または、不-認証された位置に置かれるなら、この属性は少しの追加担保も提供しません。
The attributes defined in this document permit a signer to select a hash algorithm to identify a certificate. A poorly selected hash algorithm may provide inadequate protection against certificate substitution or result in denial of service for this protection. By employing the attributes defined in this specification with the same hash algorithm used for message signing, the sender can ensure that these attributes provide commensurate security.
本書では定義された属性は、署名者が証明書を特定するためにハッシュアルゴリズムを選択することを許可します。 不十分に選択されたハッシュアルゴリズムは証明書代替か結果に対する不十分な保護をこの保護のためのサービスの否定に提供するかもしれません。 同じハッシュアルゴリズムがメッセージ署名に使用されている状態でこの仕様に基づき定義された属性を使うことによって、送付者は、これらの属性が等しいセキュリティを提供するのを保証できます。
Since recipients must support the hash algorithm to verify the signature, selecting the same hash algorithm also increases the likelihood that the hash algorithm is supported in the context of certificate identification. Note that an unsupported hash algorithm for certificate identification does not preclude validating the message but does deny the message recipient protection against certificate substitution.
受取人が署名について確かめるためにハッシュアルゴリズムをサポートしなければならないので、同じハッシュアルゴリズムを選択すると、また、ハッシュアルゴリズムが証明書識別の文脈でサポートされる可能性は広げられます。 証明書識別のためのサポートされないハッシュアルゴリズムがメッセージを有効にするのを排除しませんが、証明書代替に対するメッセージ受取人保護を否定することに注意してください。
To ensure that legacy implementations are provided protection against certificate substitution, clients are permitted to include both ESScertID and ESScertIDv2 in the same message. Since these
証明書代替に対する保護がレガシー実装に提供されるのを保証するために、クライアントが同じメッセージにESScertIDとESScertIDv2の両方を含んでいることが許可されています。 これら以来
Schaad Standards Track [Page 9] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[9ページ]
attributes are generated and evaluated independently, the contents could conceivably be in conflict. Specifically, where a signer has multiple certificates containing the same public key, the two attributes could specify different signing certificates. The result of signature processing may vary depending on which certificate is used to validate the signature.
属性は、独自に生成されて、評価されて、コンテンツは闘争多分中であるかもしれません。 明確に、署名者には同じ公開鍵を含む複数の証明書があるところでは、2つの属性が異なった署名証明書を指定するかもしれません。 どの証明書が署名を有効にするのに使用されるかによって、署名処理の結果は異なるかもしれません。
Recipients that attempt to evaluate both attributes may choose to reject such a message.
両方の属性を評価するのを試みる受取人は、そのようなメッセージを拒絶するのを選ぶかもしれません。
8. Normative References
8. 引用規格
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
[RFC3280] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、フォード、W.、ポーク、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF8]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
Schaad Standards Track [Page 10] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[10ページ]
Appendix A. ASN.1 Module
付録A.ASN.1モジュール
Replace the ASN.1 module in RFC 2634 with this one.
RFC2634のASN.1モジュールをこれに取り替えてください。
ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS) [RFC3852]
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}
-- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module
-- 1988 Syntax [RFC3280]
AlgorithmIdentifier, CertificateSerialNumber
FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
ExtendedSecurityServices-2006、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)のイドモッズ風のess-2006(30)、DEFINITIONS IMPLICIT TAGS:、:= BEGIN IMPORTS--暗号のMessage Syntax(CMS)[RFC3852]ContentType、IssuerAndSerialNumber、SubjectKeyIdentifier FROM CryptographicMessageSyntax2004、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)、--PKIX CertificateとCRL Profile、セクションA.1 Explicity Tagged Module--1988Syntax[RFC3280]AlgorithmIdentifier、CertificateSerialNumber FROM PKIX1Explicit88iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax [RFC3280]
PolicyInformation, GeneralNames
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)};
-- PKIX CertificateとCRL Profile、Sec A.2 Implicitly Tagged Module--1988Syntax[RFC3280]PolicyInformation、GeneralNames FROM PKIX1Implicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)。
-- Extended Security Services -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to -- have at least one entry. MAX indicates the upper bound is -- unspecified. Implementations are free to choose an upper bound that -- suits their environment.
-- 拡張Security Services--、構造物が「サイズ(1..MAX)を配列する」、出現、コネ数個のASN.1--このモジュールによる構造物。 または、有効なASN.1SEQUENCEがゼロを持つことができる、--より多くのエントリー。 (1..MAX)構造物がSEQUENCEを抑制するSIZE--少なくとも1つのエントリーを持ってください。 MAXは、上限がそうであることを示します--不特定です。 実装は自由に上限にそれを選ぶことができます--彼らの環境に合います。
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- UTF8String:、:= [普遍的な12]内在している八重奏ストリング
-- The contents are formatted as described in [UTF8]
-- 内容は中で説明されるようにフォーマットされます。[UTF8]
-- Section 2.7
-- セクション2.7
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames
}
ReceiptRequest:、:= 系列signedContentIdentifier ContentIdentifier、receiptsFrom ReceiptsFrom、GeneralNamesのreceiptsTo系列サイズ(1..ub-receiptsTo)
Schaad Standards Track [Page 11] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[11ページ]
ub-receiptsTo INTEGER ::= 16
ub-receiptsTo整数:、:= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
イド-aa-receiptRequestオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)1をメンバーと同じくらい具体化させます。
ContentIdentifier ::= OCTET STRING
ContentIdentifier:、:= 八重奏ストリング
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
イド-aa-contentIdentifierオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)7をメンバーと同じくらい具体化させます。
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier, -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames
}
ReceiptsFrom:、:= 選択allOrFirstTier[0]AllOrFirstTier--、以前「allOrNone[0]AllOrNone」receiptList[1]SEQUENCE OF GeneralNames
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1)
}
AllOrFirstTier:、:= 整数--、以前AllOrNone allReceipts(0)、firstTierRecipients(1)
-- Section 2.8
-- セクション2.8
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING
}
以下を領収書を出させてください:= 系列バージョンESSVersion、contentType ContentType、signedContentIdentifier ContentIdentifier、originatorSignatureValue OCTET STRING
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
イドct領収書OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドct(1)1をメンバーと同じくらい具体化させます。
ESSVersion ::= INTEGER { v1(1) }
ESSVersion:、:= 整数v1(1)
-- Section 2.9
-- セクション2.9
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType
}
ContentHints:、:= 系列contentDescription UTF8String(サイズ(1..MAX))任意である、contentType ContentType
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
イド-aa-contentHint物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)4をメンバーと同じくらい具体化させます。
-- Section 2.10
-- セクション2.10
MsgSigDigest ::= OCTET STRING
MsgSigDigest:、:= 八重奏ストリング
Schaad Standards Track [Page 12] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[12ページ]
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
イド-aa-msgSigDigest物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)5をメンバーと同じくらい具体化させます。
-- Section 2.11
-- セクション2.11
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING
}
ContentReference:、:= 系列contentType ContentType、signedContentIdentifier ContentIdentifier、originatorSignatureValue八重奏ストリング
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
イド-aa-contentReference物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)10をメンバーと同じくらい具体化させます。
-- Section 3.2
-- セクション3.2
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL
}
ESSSecurityLabel:、:= セットします。セキュリティ方針識別子SecurityPolicyIdentifier、セキュリティ分類SecurityClassification OPTIONAL、プライバシーマークESSPrivacyMark OPTIONAL、セキュリティカテゴリSecurityCategories OPTIONAL
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
イド-aa-securityLabel物の識別子:、:= iso(1)が(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)2をメンバーと同じくらい具体化させる、SecurityPolicyIdentifier:、:= 物の識別子
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5)
}(0..ub-integer-options)
SecurityClassification:、:= INTEGER、無印の(0)、(1)、部外秘な(2)、秘密の(3)、秘密(4)、トップシークレットの(5)を非分類しました。(0..ub整数オプション)
ub-integer-options INTEGER ::= 256
ub整数オプションINTEGER:、:= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ESSPrivacyMark:、:= 選択pString PrintableString(サイズ(1..ubプライバシーマークの長さ))、utf8String UTF8String(サイズ(1..MAX))
ub-privacy-mark-length INTEGER ::= 128
ubプライバシーマークの長さのINTEGER:、:= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
SecurityCategories:、:= SecurityCategoryのサイズ(1..ubセキュリティカテゴリ)を設定してください。
Schaad Standards Track [Page 13] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[13ページ]
ub-security-categories INTEGER ::= 64
ubセキュリティカテゴリINTEGER:、:= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
SecurityCategory:、:= 系列[0] OBJECT IDENTIFIERをタイプしてください、そして、値[1]ANY DEFINED BYはタイプします。
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
--以下に注意してください。 前述のSecurityCategory構文は同じ状態で作成されます--以下のSecurityCategory構文--X.411仕様に記録されるとしてencodingsに魔法をかけてください: -- --SecurityCategory:、:= 系列
-- type [0] SECURITY-CATEGORY, -- value [1] ANY DEFINED BY type } -- --SECURITY-CATEGORY MACRO ::= --BEGIN --TYPE NOTATION ::= type | empty --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) --END
-- [0] SECURITY-CATEGORYをタイプしてください--値[1]ANY DEFINED BYはタイプします。 -- --セキュリティカテゴリマクロ:、:= --始まってください--記法をタイプしてください:、:= タイプ| --VALUE NOTATIONを空にしてください:、:= 値(VALUE OBJECT IDENTIFIER)の--END
-- Section 3.4
-- セクション3.4
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
EquivalentLabels:、:= ESSSecurityLabelの系列
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
イド-aa-equivalentLabels物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)9をメンバーと同じくらい具体化させます。
-- Section 4.4
-- セクション4.4
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
MLExpansionHistory:、:= 系列サイズ、(1..ubミリリットル、拡大歴史、)、MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3 }
イド-aa-mlExpandHistory物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)3をメンバーと同じくらい具体化させます。
ub-ml-expansion-history INTEGER ::= 64 MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL
}
ubミリリットル、拡大歴史、INTEGER:、:= 64MLData:、:= 系列expansionTime GeneralizedTimeの、そして、mlReceiptPolicy MLReceiptPolicy任意のmailListIdentifier EntityIdentifier
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier
}
EntityIdentifier:、:= 選択issuerAndSerialNumber IssuerAndSerialNumber、subjectKeyIdentifier SubjectKeyIdentifier
Schaad Standards Track [Page 14] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[14ページ]
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames
}
MLReceiptPolicy:、:= 選択なにも、[0]NULL、insteadOf[1]SEQUENCE SIZE(1..MAX)OF GeneralNames、inAdditionTo[2]SEQUENCE SIZE(1..MAX)OF GeneralNames
-- Section 5.4
-- セクション5.4
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificate:、:= 系列本命SEQUENCE OF ESSCertID、方針SEQUENCE OF PolicyInformation OPTIONAL
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
イド-aa-signingCertificate物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)12をメンバーと同じくらい具体化させます。
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
SigningCertificateV2:、:= 系列本命SEQUENCE OF ESSCertIDv2、方針SEQUENCE OF PolicyInformation OPTIONAL
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
イド-aa-signingCertificateV2物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)47をメンバーと同じくらい具体化させます。
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
イド-sha256 OBJECT IDENTIFIER:、:= (16) 共同iso-ituのt(2)国の私たち、(840) 組織(1)gov(101) csor(3) nistalgorithm(4) hashalgs(2)1
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
DEFAULT {algorithm id-sha256},
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertIDv2:、:= 系列hashAlgorithm AlgorithmIdentifier DEFAULTアルゴリズムイド-sha256、certHash Hash、issuerSerial IssuerSerial OPTIONAL
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
ESSCertID:、:= 系列certHash細切れ肉料理で、issuerSerial IssuerSerial任意です。
Hash ::= OCTET STRING IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
以下を論じ尽くしてください:= 八重奏ストリングIssuerSerial:、:= 系列発行人GeneralNames、serialNumber CertificateSerialNumber
END
終わり
Schaad Standards Track [Page 15] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[15ページ]
-- of ExtendedSecurityServices-2006
-- ExtendedSecurityServices-2006について
Author's Address
作者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高く昇るタカのコンサルティング私書箱675金の延べ棒、ワシントン 98251
EMail: jimsch@exmsft.com
メール: jimsch@exmsft.com
Schaad Standards Track [Page 16] RFC 5035 ESSCertID Update August 2007
RFC5035ESSCertIDが2007年8月にアップデートするSchaad標準化過程[16ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Schaad Standards Track [Page 17]
Schaad標準化過程[17ページ]
一覧
スポンサーリンク
