[要約] RFC 6025は、ASN.1（Abstract Syntax Notation One）形式のデータを他の形式に変換するための手法を提供しています。このRFCの目的は、ASN.1データの相互運用性を向上させるために、異なるプロトコルやシステム間でASN.1データを翻訳する方法を提供することです。
Internet Engineering Task Force (IETF) C. Wallace
Request for Comments: 6025 Cygnacom Solutions
Category: Informational C. Gardiner
ISSN: 2070-1721 BBN Technologies
October 2010
ASN.1 Translation
ASN.1翻訳
Abstract
概要
Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version.
抽象構文表記法1（ASN.1）は、IETFセキュリティエリア全体で広く使用されており、長年にわたりされています。いくつかの仕様は現在の廃止予定バージョンのASN.1を使用して書かれており、いくつかは現在のバージョンのASN.1を使用して書かれました。すべてのASN.1コンパイラが古い構文と現在の構文の両方をサポートしていません。この文書は、仕様作成者とASN.1モジュールを1つのバージョンのASN.1から別のバージョンに変換するためのガイダンスを提供することを目的としています。この文書は、ASN.1の任意のバージョンの包括的なチュートリアルを提供しません。代わりに、ASN.1バージョンによって異なるアイテムに焦点を当てて、IETFセキュリティエリアの仕様で使用されるASN.1機能に対処します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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）の製品です。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/rfc6025.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、http：//www.rfc-editor.org/info/rfc6025で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2010 IETFの信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（http://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. ASN.1 Design Elements . . . . . . . . . . . . . . . . . . . . 3
2.1. Open Types . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. ANY DEFINED BY . . . . . . . . . . . . . . . . . . . . 4
2.1.2. OCTET STRINGs and BIT STRINGs . . . . . . . . . . . . 5
2.1.3. Information Object Classes . . . . . . . . . . . . . . 5
2.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Simple Table Constraints . . . . . . . . . . . . . . . 8
2.2.2. Component Relation Constraints . . . . . . . . . . . . 9
2.2.3. Content Constraints . . . . . . . . . . . . . . . . . 11
2.3. Parameterization . . . . . . . . . . . . . . . . . . . . . 12
2.4. Versioning and Extensibility . . . . . . . . . . . . . . . 13
2.4.1. Extension Markers . . . . . . . . . . . . . . . . . . 14
2.4.2. Version Brackets . . . . . . . . . . . . . . . . . . . 14
3. Character Set Differences . . . . . . . . . . . . . . . . . . 15
4. ASN.1 Translation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Downgrading from X.68x to X.208 . . . . . . . . . . . . . 16
4.2. Upgrading from X.208 to X.68x . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 18
This document is intended to serve as a tutorial for converting ASN.1 modules written using [CCITT.X208.1988] to [CCITT.X680.2002], or vice versa. Preparation of this document was motivated by [RFC5911] and [RFC5912], which provide updated ASN.1 modules for a number of RFCs.
この文書は、[CCITT.X208.1988]を使用して書かれたASN.1モジュールを[CCITT.X680.2002]、またはその逆に変換するためのチュートリアルとして機能することを目的としています。この文書の調製は[RFC5911]と[RFC5912]によって動機付けられ、これはいくつかのRFCのための更新されたASN.1モジュールを提供します。
The intent of this specification is to assist with translation of ASN.1 from one version to another without resulting in any changes to the encoded results when using the Basic Encoding Rules or Distinguished Encoding Rules [CCITT.X209.1988] [CCITT.X690.2002]. Other encoding rules were not considered.
この仕様の目的は、基本的なエンコーディング規則または識別符号化規則を使用するときの符号化結果への変更を生じさせることなく、あるバージョンから別のバージョンへのASN.1の翻訳を支援することです[CCITT.X209.1988] [CCITT.X690]。2002]。他の符号化規則は考慮されなかった。
Transforming a new ASN.1 module to an older ASN.1 module can be performed in a fairly mechanical manner; much of the transformation consists of deleting new constructs. Transforming an older ASN.1 module to a newer ASN.1 module can also be done fairly mechanically, if one does not wish to move many of the constraints that are contained in the prose into the ASN.1 module. If the constraints are to be added, then the conversion can be a complex process.
新しいASN.1モジュールを古いASN.1モジュールに変換すると、かなりの機械的な方法で実行できます。変換の多くは新しい構成要素を削除することから成ります。古いASN.1モジュールを新しいASN.1モジュールに変換すると、PROSEに含まれている多くの制約がASN.1モジュールに含まれていない場合は、かなり機械的に行うことができます。制約を追加する場合は、変換は複雑なプロセスになる可能性があります。
This document addresses two different versions of ASN.1. The old (1988) version was defined in a single document (X.208) and the newer (1998, 2002) version is defined in a series of documents (X.680, X.681, X.682, and X.683). For convenience, the series of documents is henceforth referred to as X.68x. Specific documents from the series are referenced by name where appropriate.
このドキュメントはASN.1の2つの異なるバージョンに対処します。古い（1988）のバージョンは単一の文書（X.208）で定義され、新しい（1998,2002）バージョンは一連の文書で定義されています（X.680、X.681、X.682、およびX.683）。便宜上、一連の文書はX.68Xと呼ばれています。シリーズからの特定の文書は、適切な場合に名前によって参照されます。
When translating an ASN.1 module from X.208 syntax to X.68x syntax, or vice versa, many definitions do not require or benefit from change. Review of the original ASN.1 modules updated by [RFC5911] and [RFC5912] and the revised modules included in those documents indicates that most changes can be sorted into one of a few categories. This section describes these categories.
ASN.1モジュールをX.208構文からX.68X構文に変換する場合、またはその逆の場合、多くの定義は必要とされないか、変更から利益を得ることができません。[RFC5911]と[RFC5912]によって更新されたオリジナルのASN.1モジュールのレビューとそれらの文書に含まれる改訂モジュールは、ほとんどの変更をいくつかのカテゴリのうちの1つに分類できることを示しています。このセクションではこれらのカテゴリについて説明します。
Protocols often feature flexible designs that enable other (later) specifications to define the syntax and semantics of some features. For example, [RFC5280] includes the definition of the Extension structure. There are many instances of extensions defined in other specifications. Several mechanisms to accommodate this practice are available in X.208, X.68x, or both, as described below.
プロトコルはしばしば他の（後）仕様を有効にしていくつかの機能の構文と意味を定義する柔軟な設計を特徴としています。たとえば、[RFC5280]は拡張構造の定義を含みます。他の仕様で定義されている拡張機能の多くのインスタンスがあります。この慣行に対応するためのいくつかのメカニズムは、以下に説明するように、X.208、X.68X、またはその両方で利用可能です。
X.208 defines the ANY DEFINED BY production for specifying open types. This typically appears in a SEQUENCE along with an OBJECT IDENTIFIER that indicates the type of object that is encoded. The ContentInfo structure, shown below from [RFC5652], uses ANY DEFINED BY along with an OBJECT IDENTIFIER field to identify and convey arbitrary types of data. Each content type to be wrapped in a ContentInfo is assigned a unique OBJECT IDENTIFIER, such as the id-signedData shown below. However, X.208 does not provide a formal means for establishing a relationship between a type and the type identifier. Any associations are done in the comments of the module and/or the text of the associated document.
X.208では、オープンタイプを指定するためのプロダクションによって定義された任意のものを定義します。これは通常、エンコードされているオブジェクトの種類を示すオブジェクト識別子と共にシーケンス内に表示されます。[RFC5652]から以下に示すContentInfo構造体は、オブジェクト識別子フィールドとともに定義された任意の任意の任意のデータを使用して、任意のタイプのデータを識別します。ContentInfoに折り返す各コンテンツタイプには、以下に示すID-SignedDataなど、一意のオブジェクト識別子が割り当てられています。ただし、X.208は、型と型識別子との間の関係を確立するための形式的な手段を提供していません。任意の関連付けは、モジュールのコメントおよび/または関連文書のテキストで行われます。
-- from RFC 5652
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
ANY DEFINED BY may also appear using an INTEGER to indicate the type of object that is encoded, as shown in the following example from [RFC5280].
[RFC5280]からの次の例に示すように、整数を使用して整数を使用して表示されます。
-- from RFC 5280
ExtensionAttribute ::= SEQUENCE {
extension-attribute-type [0] IMPLICIT INTEGER
(0..ub-extension-attributes),
extension-attribute-value [1]
ANY DEFINED BY extension-attribute-type }
Though the usage of ANY DEFINED BY was deprecated in 1994, it appears in some active specifications. The AttributeValue definition in [RFC5280] uses ANY with a DEFINED BY comment to bind the value to a type identifier field.
1994年に定義されたいずれかの使用法は廃止予定であるが、それはいくつかの積極的な仕様に現れる。[RFC5280]のattributeValue定義は、定義されたコメントを使用して値を型識別子フィールドにバインドします。
-- from RFC 5280
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY -- DEFINED BY AttributeType
Both X.208 and X.68x allow open types to be implemented using OCTET STRINGs and BIT STRINGs as containers. The definitions of Extension and SubjectPublicKeyInfo in [RFC5280] demonstrate the usage of OCTET STRING and BIT STRING, respectively, to convey information that is further defined using ASN.1.
X.208とX.68Xの両方で、オープンタイプをオクテット文字列とコンテナとしてビット文字列を使用して実装できます。[RFC5280]の拡張子とSubjectPublicKeyInfoの定義は、ASN.1を使用してさらに定義されている情報を伝えるために、それぞれオクテット文字列とビット文字列の使用法を示しています。
-- from RFC 5280
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
In both cases, the prose of the specification describes that the adjacent OBJECT IDENTIFIER value indicates the type of structure within the value of the primitive OCTET STRING or BIT STRING type. For example, where an extnID field contains the value id-ce-basicConstraints, the extnValue field contains an encoded BasicConstraints as the value of the OCTET STRING, as shown in the dump of an encoded extension below.
どちらの場合も、仕様の散文は、隣接するオブジェクト識別子値が、プリミティブオクテット文字列またはビット文字列型の値内の構造のタイプを示すことを説明しています。たとえば、extnidフィールドに値ID-CE-CE-BASINCONSTRANTSが含まれている場合、extnValueフィールドには、符号化された拡張子のダンプに示されている符号化された基本Constraintsが、以下の符号化された拡張子のダンプに含まれています。
Tag Length Value
30 15: SEQUENCE {
06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
01 1: BOOLEAN TRUE
04 5: OCTET STRING, encapsulates {
30 3: SEQUENCE {
01 1: BOOLEAN TRUE
: }
: }
: }
Information object classes are defined in [CCITT.X681.2002]. Object classes allow protocol designers to relate pieces of data that are in some way associated. In the most generic of terms, an Information Object class can be thought of as a database schema, with Information Object Sets being instances of the databases.
情報オブジェクトクラスは[CCITT.X681.2002]で定義されています。オブジェクトクラスは、プロトコル設計者が何らかの形で関連付けられているデータを関連付けることを可能にします。最も一般的な用語では、情報オブジェクトクラスはデータベーススキーマとして考えることができ、情報オブジェクトはデータベースのインスタンスであることを示しています。
Unlike type definitions, object classes with the same structure are not equivalent. Thus, if you have:
型定義とは異なり、同じ構造のオブジェクトクラスは同等ではありません。したがって、あなたが持っているならば：
FOO ::= TYPE-IDENTIFIER
BAR ::= TYPE-IDENTIFIER
FOO and BAR are not interchangeable.
FooとBarは交換可能ではありません。
TYPE-IDENTIFIER is one of the predefined information object classes in Annex A of [CCITT.X681.2002]. This provides for a simple mapping from an OBJECT IDENTIFIER to a data type. The tag UNIQUE on &id means that this value may appear only once in an Information Object Set; however, multiple objects can be defined with the same &id value.
TYPE-IDは、[CCITT.X681.2002]の附属書Aの事前定義された情報オブジェクトクラスの1つです。これは、オブジェクト識別子からデータ型への単純なマッピングを提供します。タグ一意のON＆IDは、この値が情報オブジェクトセットに一度だけ現れることがあることを意味します。ただし、同じ＆ID値で複数のオブジェクトを定義できます。
[RFC5911] uses the TYPE-IDENTIFIER construction to update the definition of ContentInfo, as shown below.
[RFC5911]次に示すように、ContentInfoの定義を更新するには、Type-Identifier Constructionを使用します。
-- TYPE-IDENTIFIER definition from X.681
TYPE-IDENTIFIER ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id}
-- from updated RFC 5652 module in [RFC5911]
CONTENT-TYPE ::= TYPE-IDENTIFIER
ContentType ::= CONTENT-TYPE.&id
ContentInfo ::= SEQUENCE {
contentType CONTENT-TYPE.
&id({ContentSet}),
content [0] EXPLICIT CONTENT-TYPE.
&Type({ContentSet}{@contentType})}
ContentSet CONTENT-TYPE ::= {
-- Define the set of content types to be recognized.
ct-Data | ct-SignedData | ct-EncryptedData | ct-EnvelopedData |
ct-AuthenticatedData | ct-DigestedData, ... }
-- other CONTENT-TYPE instances not shown for brevity
ct-SignedData CONTENT-TYPE ::=
{ SignedData IDENTIFIED BY id-signedData}
This example illustrates the following:
この例は次のことを示しています。
o Definition of an information object class: TYPE-IDENTIFIER and CONTENT-TYPE are information object classes.
o 情報オブジェクトクラスの定義：type-識別子とcontent-typeは情報オブジェクトクラスです。
o Definition of an information object, or an instance of an information object class: ct-SignedData is an information object.
o 情報オブジェクトの定義、または情報オブジェクトクラスのインスタンス：CT-SignedDataは情報オブジェクトです。
o Definition of an information object set: ContentSet is an information object set.
o 情報オブジェクトセットの定義：Conteghetは情報オブジェクトセットです。
o Usage of an information object: The definition of ContentInfo uses information from the CONTENT-TYPE information object class.
o 情報オブジェクトの使用法：ContentInfoの定義は、Content-Type Informationオブジェクトクラスからの情報を使用します。
o Defining constraints using an object set: Both the contentType and content fields are constrained by ContentSet.
o オブジェクト・セットを使用した制約の定義：ContentTypeフィールドとコンテンツフィールドの両方がCONTECTESETによって制限されます。
As noted above, TYPE-IDENTIFIER simply associates an OBJECT IDENTIFIER with an arbitrary data type. CONTENT-TYPE is a TYPE-IDENTIFIER. The WITH SYNTAX component allows for a more natural language expression of information object definitions.
上記のように、Type-IDは単にオブジェクト識別子を任意のデータ型と関連付けます。content-typeは型識別子です。with構文コンポーネントは、情報オブジェクト定義のより自然な言語表現を可能にします。
ct-SignedData is the name of an information object that associated the identifier id-signedData with the data type SignedData. It is an instance of the CONTENT-TYPE information object class. The &Type field is assigned the value SignedData, and the &id field is assigned the value id-signedData. The example above uses the syntax provided by the WITH SYNTAX component of the TYPE-IDENTIFIER definition. An equivalent definition that does not use the provided syntax is as follows:
CT-SignedDataは、識別子ID-SignedDataをデータ型SignedDataに関連付けた情報オブジェクトの名前です。Content-Type Informationオブジェクトクラスのインスタンスです。＆TYPEフィールドには値SignedDataが割り当てられ、＆IDフィールドには値ID-SignedDataが割り当てられます。上記の例では、タイプ識別子定義のwith構文コンポーネントによって提供される構文を使用します。提供された構文を使用しない同等の定義は次のとおりです。
ct-SignedData CONTENT-TYPE ::=
{
&id id-signedData,
&Type SignedData
}
ContentSet is the name of a set of information objects derived from the CONTENT-TYPE information object class. The set contains six information objects and is extensible, as indicated by the ellipsis (see Section 2.4, "Versioning and Extensibility").
CONTENNEETは、Content-Type Information Objectクラスから派生した一連の情報オブジェクトの名前です。このセットには6つの情報オブジェクトが含まれており、省略記号によって示されるように拡張可能です（セクション2.4「バージョン管理と拡張性」を参照）。
ContentInfo is defined using type information from an information object, i.e., the type of the contentType field is that of the &id field from CONTENT-TYPE. An equivalent definition is as follows:
ContentInfoは、情報オブジェクトからのタイプ情報を使用して定義されます。すなわち、ContentTypeフィールドの型は、content-typeからの＆IDフィールドの型です。同等の定義は次のとおりです。
ContentType ::= OBJECT IDENTIFIER
Both fields in ContentInfo are constrained. The contentType field is
constrained using a simple table constraint that restricts the values
to those from the corresponding field of the objects in ContentSet.
The content field is constrained using a component relationship
constraint. Constraints are discussed in the next section.
The X.68x versions of the ASN.1 specifications introduced the ability to use the object information sets as part of the constraint on the values that a field can take. Simple table constraints are used to restrict the set of values that can occur in a field. Component relation constraints allow for the restriction of a field based on contents of other fields in the type.
ASN.1仕様のX.68xバージョンは、フィールドが取ることができる値の制約の一部としてオブジェクト情報セットを使用する機能を導入しました。単純なテーブル制約は、フィールド内で発生する可能性がある値のセットを制限するために使用されます。コンポーネントの関係の制約は、タイプ内の他のフィールドの内容に基づいてフィールドの制限を可能にします。
Simple table constraints are widely used in [RFC5911] and [RFC5912] to limit implementer options (although the constraints are almost always followed by or include extensibility markers, which make the parameters serve as information not as limitations). Table constraints are defined in [CCITT.X682.2002].
実装者のオプションを制限するには、[RFC5911]と[RFC5912]で単純なテーブル制約が広く使用されています（制約はほとんどの場合、拡張マーカーが続く、パラメータを制限としてはなく情報として機能させます）。テーブル制約は[CCITT.X682.2002]で定義されています。
Some ASN.1 compilers have the ability to use the simple table constraint to check that a field contains one of the legal values.
一部のASN.1コンパイラには、単純な表制約を使用して、フィールドに有効な値が1つ含まれていることを確認することができます。
The following example from [RFC5911] demonstrates using table constraints to clarify the intended usage of a particular field. The parameters indicate the types of attributes that are typically found in the signedAttrs and unsignedAttrs fields. In this example, the object sets are disjoint but this is not required. For example, in [RFC5912], there is some overlap between the CertExtensions and CrlExtensions sets.
[RFC5911]から次の例は、特定のフィールドの意図された使用法を明確にするためにテーブル制約を使用しています。パラメータは、通常、SignEdattrsフィールドとUnsignedAttrsフィールドに表示される属性の種類を示します。この例では、オブジェクトセットは互いに素ですが、これは必須ではありません。たとえば、[RFC5912]では、CertExtensionsとCrlextensionsセットの間に重複があります。
-- from updated RFC 5652 module in [RFC5911]
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT Attributes
{{UnsignedAttributes}} OPTIONAL }
SignedAttributes ::= Attributes {{ SignedAttributesSet }}
SignedAttributesSet ATTRIBUTE ::=
{ aa-signingTime | aa-messageDigest | aa-contentType, ... }
UnsignedAttributes ATTRIBUTE ::= { aa-countersignature, ... }
Component relation constraints are often used to bind the type field of an open type to the identifier field. Using the binding in this way allows a compiler to immediately decode the associated type when the containing structure is defined. The following example from [RFC2560] as updated in [RFC5912] demonstrates this usage.
コンポーネント関係の制約は、開いている型の型フィールドを識別子フィールドにバインドするためによく使用されます。このようにバインディングを使用することで、コンパイラは、含有構造が定義されている場合に関連するタイプを直ちに復号することができます。[RFC5912]で更新された[RFC2560]からの次の例は、この使用法を示しています。
-- from updated RFC 2560 module in [RFC5912]
RESPONSE ::= TYPE-IDENTIFIER
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
In this example, the response field is constrained to contain a type identified by the responseType field. The controlling field is identified using atNotation, e.g., "@responseType". atNotation can be defined relative to the outermost SEQUENCE, SET, or CHOICE or relative to the field with which the atNotation is associated. When there is no '.' immediately after the '@', the field appears as a member of the outermost SEQUENCE, SET, or CHOICE. When there is a '.' immediately after the '@', each '.' represents a SEQUENCE, SET, or CHOICE starting with the SEQUENCE, SET, or CHOICE that contains the field with which the atNotation is associated. For example, ResponseBytes could have been written as shown below. In this case, the syntax is very similar since the innermost and outermost SEQUENCE, SET, or CHOICE are the same.
この例では、応答フィールドは、応答型フィールドによって識別される型を含むように制限されています。制御フィールドは、ATNotation、例えば「@Responsetype」を使用して識別されます。ATNotationは、ATNotationが関連付けられているフィールドに対する最外側のシーケンス、セット、または選択または相対的なものと比較して定義できます。'」がないとき'@'の直後に、フィールドは最も外側のシーケンス、設定、または選択のメンバーとして表示されます。'。'があるとき「@」の直後、それぞれの「。」ATNotationが関連付けられているフィールドを含むシーケンス、設定、または選択から始まるシーケンス、セット、または選択を表します。たとえば、ResponseBytesは以下のように書かれている可能性があります。この場合、内側と最も外側のシーケンス、設定、または選択は同じであるため、構文は非常に似ています。
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@.responseType}))}
The TaggedRequest example from [RFC5912] provides an example where the outermost and innermost SEQUENCE, SET, or CHOICE are different. Relative to the atNotation included in the definition of the requestMessageValue field, the outermost SEQUENCE, SET, or CHOICE is TaggedRequest, and the innermost is the SEQUENCE used to define the orm field.
[RFC5912]からのTagggeDrequestの例は、最も外側と最も内側のシーケンス、設定、または選択が異なる例を提供します。RequestMessageValueフィールドの定義に含まれているATNOTATIONとの相対、最も外側のシーケンス、設定、または選択はTagggequestであり、最も内側はORMフィールドを定義するために使用されるシーケンスです。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OTHER-REQUEST.&id({OtherRequests}),
requestMessageValue OTHER-REQUEST.&Type({OtherRequests}
{@.requestMessageType})
}
}
When referencing a field using atNotation, the definition of the field must be included within the outermost SEQUENCE, SET, or CHOICE. References to fields within structures that are defined separately are not allowed. For example, the following example includes invalid atNotation in the definition of the signature field within the SIGNED parameterized type.
ATNotationを使用してフィールドを参照する場合、フィールドの定義は最外側の順序、設定、または選択内に含める必要があります。別々に定義されている構造内のフィールドへの参照は許可されていません。たとえば、次の例では、署名付きパラメータ化型内の署名フィールドの定義に無効なatnotationを含む。
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE {
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE.
&Params({AlgorithmSet}{@algorithm}) OPTIONAL
}
-- example containing invalid atNotation
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier AlgorithmIdentifier
{ SIGNATURE-ALGORITHM, {...}}
},
signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
{SignatureAlgorithms}
{@algorithmIdentifier.algorithm}))
}
Alternatively, the above example could be written with correct atNotation as follows, with the definition of the algorithm field included within ToBeSigned.
あるいは、上記の例は、Totbesignedの範囲内に含まれるアルゴリズムフィールドの定義を用いて、以下のように正しいatnotationで書くことができる。
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier SEQUENCE {
algorithm SIGNATURE-ALGORITHM.
&id({SignatureAlgorithms}),
parameters SIGNATURE-ALGORITHM.
&Params({SignatureAlgorithms}
{@algorithmIdentifier.algorithm})
},
signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
{SignatureAlgorithms}
{@algorithmIdentifier.algorithm}))
}
In the above example, the outermost SEQUENCE, SET, or CHOICE relative to the parameters field is the SIGNED parameterized type. The innermost structure is the SEQUENCE used as the type for the algorithmIdentifier field. The atNotation for the parameters field could be expressed using any of the following representations:
上記の例では、パラメータフィールドに対する最も外側のシーケンス、設定、または選択は符号付きパラメータ化型です。最も内側の構造は、AlgorithmIdentifierフィールドの型として使用されるシーケンスです。パラメータフィールドのATNotationは、以下のいずれかの表現を使用して表現できます。
@algorithmIdentifier.algorithm
@ algorithmIdentifier.Algorithm.
@.algorithm
@。アルゴリズム
The atNotation for the signature field has only one representation.
署名フィールドのatnotationには1つの表現しかありません。
Open types implemented as OCTET STRINGs or BIT STRINGs can be constrained using the contents constraints syntax defined in [CCITT.X682.2002]. Below are the revised definitions from [RFC5911] and [RFC5912]. These show usage of OCTET STRING and BIT STRING along with constrained sets of identifiers. The Extension definition uses a content constraint that requires the value of the OCTET STRING to be an encoding of the type associated with the information object selected from the ExtensionSet object set using the value of the extnID field. For reasons described in Section 2.2.2, "Component Relation Constraints", the SubjectPublicKeyInfo definition relies on prose to bind the BIT STRING to the type identifier because it is not possible to express a content constraint that includes a component relationship constraint to bind the type value within the algorithm field to the subjectPublicKey field.
オクテット文字列またはビット文字列として実装されているオープンタイプは、[CCITT.X682.2002]で定義されている内容制約構文を使用して制約されます。以下は[RFC5911]から[RFC5912]の改訂された定義です。これらは、識別された識別子セットとともに、オクテット文字列とビット文字列の使用を示しています。拡張定義は、extnidフィールドの値を使用してExtenSetオブジェクトセットから選択された情報オブジェクトに関連付けられている型オブジェクトに関連付けられている型の符号化を要求するコンテンツ制約を使用します。2.2.2項「コンポーネントリレーション制約」で説明されている理由で、SubjectPublicKeyInfo定義は、タイプをバインドするためのコンポーネント関係の制約を含むコンテンツ制約を表現することができないため、PROSEを型識別子にバインドすることができます。[Algorithm]フィールド内の[TubronsPublicKey]フィールド内の値。
-- from updated RFC 5280 module in [RFC5912]
Extension{EXTENSION:ExtensionSet} ::= SEQUENCE {
extnID EXTENSION.&id({ExtensionSet}),
critical BOOLEAN
-- (EXTENSION.&Critical({ExtensionSet}{@extnID}))
DEFAULT FALSE,
extnValue OCTET STRING (CONTAINING
EXTENSION.&ExtnType({ExtensionSet}{@extnID}))
-- contains the DER encoding of the ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier{PUBLIC-KEY,
{PublicKeyAlgorithms}},
subjectPublicKey BIT STRING
}
Parameterization is defined in [CCITT.X683.2002] and can also be used to define new types in a way similar to the macro notation described in Annex A of X.208. The following example from [RFC5912] shows this usage. The toBeSigned field takes the type passed as a parameter.
パラメータ化は[CCITT.X683.2002]で定義され、X.208の附属書Aに記載されているマクロ表記と同様の方法で新しいタイプを定義するためにも使用できます。[RFC5912]からの次の例は、この使用法を示しています。TOBESIGNEDフィールドは、パラメータとして渡される型を取ります。
-- from [RFC5912]
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{SignatureAlgorithms}},
signature BIT STRING
}
-- from updated RFC5280 module in [RFC5912]
Certificate ::= SIGNED{TBSCertificate}
Parameters need not be simple types. The following example demonstrates the usage of an information object class and an information object set as parameters. The first parameter in the definition of AlgorithmIdentifier is an information object class. Information object classes used for this parameter must have &id and &Params fields, which determine the type of the algorithm and parameters fields. Other fields may be present in the information object class, but they are not used by the definition of AlgorithmIdentifier, as demonstrated by the SIGNATURE-ALGORITHM class shown below. The second parameter is an information object set that is used to constrain the values that appear in the algorithm and parameters fields.
パラメータは単純な型である必要はありません。次の例では、情報オブジェクトクラスとパラメータとして設定された情報オブジェクトの使用方法を示しています。algorithmIdentifierの定義の最初のパラメーターは、情報オブジェクトクラスです。このパラメータに使用される情報オブジェクトクラスは、＆paramsフィールドを持つ必要があります。これにより、アルゴリズムとパラメータフィールドのタイプが決定されます。他のフィールドはInformation Objectクラスに存在している可能性がありますが、以下に示す署名アルゴリズムクラスによって実証されるように、AlgorithmIdentifierの定義によって使用されません。2番目のパラメータは、アルゴリズムフィールドとパラメータフィールドに表示される値を制限するために使用される情報オブジェクトセットです。
-- from [RFC5912]
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet}
::= SEQUENCE
{
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE.&Params
({AlgorithmSet}{@algorithm}) OPTIONAL
}
SIGNATURE-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER,
&Params OPTIONAL,
&Value OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&HashSet DIGEST-ALGORITHM OPTIONAL,
&PublicKeySet PUBLIC-KEY OPTIONAL,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[VALUE &Value]
[PARAMS [TYPE &Params] ARE ¶mPresence ]
[HASHES &HashSet]
[PUBLIC KEYS &PublicKeySet]
[SMIME CAPS &smimeCaps]
}
-- from updated RFC 2560 module in [RFC5912]
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{sa-dsaWithSHA1 | sa-rsaWithSHA1 |
sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
}
Specifications are often revised and ASN.1 modules updated to include new components. [CCITT.X681.2002] provides two mechanisms useful in supporting extensibility: extension markers and version brackets.
仕様が改訂され、ASN.1モジュールが新しいコンポーネントを含めるように更新されます。[CCITT.X681.2002]は、拡張マーカーとバージョンブラケットの拡張性をサポートするのに役立つ2つのメカニズムを提供します。
An extension marker is represented by an ellipsis (i.e., three adjacent periods). Extension markers are included in specifications at points where the protocol designer anticipates future changes. This can also be achieved by including EXTENSIBILITY IMPLIED in the ASN.1 module definition. EXTENSIBILITY IMPLIED is the equivalent to including an extension marker in each type defined in the ASN.1 module. Extensibility markers are used throughout [RFC5911] and [RFC5912] where object sets are defined. In other instances, the updated modules retroactively added extension markers where fields were added to an earlier version by an update, as shown in the CertificateChoices example below.
延長マーカは、省略記号（すなわち、3つの隣接期間）によって表される。展開マーカーは、プロトコル設計者が将来の変更を予想するポイントで仕様に含まれています。これは、ASN.1モジュール定義に暗黙の拡張性を含めることによっても達成することができます。extensibilidibilidibilidibilidibilidは、ASN.1モジュールで定義されている各タイプの拡張マーカを含めることと同等です。拡張マーカーは、[RFC5911]と[RFC5912]では、オブジェクト・セットが定義されている[RFC5912]で使用されます。他の例では、更新されたモジュールは、以下のCertificateChoicesの例に示すように、フィールドが更新によって以前のバージョンに追加された拡張マーカーを遡って追加しました。
Examples:
例：
-- from updated RFC 3370 module in [RFC5911]
KeyAgreementAlgs KEY-AGREE ::= { kaa-esdh | kaa-ssdh, ...}
-- from updated RFC 5652 module in [RFC5911]
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
...,
[[3: v1AttrCert [1] IMPLICIT AttributeCertificateV1]],
-- Obsolete
[[4: v2AttrCert [2] IMPLICIT AttributeCertificateV2]],
[[5: other [3] IMPLICIT OtherCertificateFormat]]
}
Protocol designers should use extension markers within definitions that are likely to change. For example, extensibility markers should be used when enumerating error values.
プロトコル設計者は、変更する可能性が高い定義内で拡張マーカーを使用する必要があります。たとえば、エラー値を列挙するときに拡張マーカーを使用する必要があります。
Version brackets can be used to indicate features that are available in later versions of an ASN.1 module but not in earlier versions. [RFC5912] added version brackets to the definition of TBSCertificate to illustrate the addition of the issuerUniqueID, subjectUniqueID, and extensions fields, as shown below.
バージョンブラケットを使用して、後のバージョンのASN.1モジュールで使用可能な機能を示すために使用できますが、以前のバージョンでは使用できません。[RFC5912]以下に示すように、IssuerUniqueID、MainterUniquidId、およびExtensionsフィールドの追加を説明するために、TBSCertificateの定義にバージョンブラケットを追加しました。
-- from updated RFC 5280 module in [RFC5912]
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{SignatureAlgorithms}},
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
... ,
[[2: -- If present, version MUST be v2
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL
]],
[[3: -- If present, version MUST be v3 --
extensions [3] ExtensionSet{{CertExtensions}} OPTIONAL
]], ... }
X.68s uses a character set that is a superset of the character set defined in X.208. The character set defined in X.208 includes the following:
X.68Sは、X.208で定義されている文字セットのスーパーセットである文字セットを使用します。X.208で定義されている文字セットには、次のものが含まれています。
A to Z
AからZ
a to z
AからZ
0 to 9
0から9
:=,{}<.
：=、{} <。
()[]-'"
（）[] - '」
The character set in X.68x additionally includes the following:
X.68Xの文字セットには、次のものが含まれます。
!&*/;>@^_|
The > and | characters can also be used in X.208 syntax in macro definitions.
>と|文字は、マクロ定義のX.208構文でも使用できます。
At a minimum, downgrading an ASN.1 module from X.68x syntax to X.208 requires the removal of features not supported by X.208. As indicated above, the features most commonly used in IETF Security Area ASN.1 modules are information object classes (and object sets), content constraints, parameterization, extension markers, and version brackets. Extension markers and version brackets can simply be deleted (or commented out). The definitions for information object classes and object sets can also be deleted or commented out, as these will not be used. The following checklist can be used in most cases:
最低限、X.68X構文からX.208へのASN.1モジュールのダウングレードには、X.208ではサポートされていない機能の削除が必要です。上記のように、IETFセキュリティエリアASN.1モジュールで最も一般的に使用される機能は、情報オブジェクトクラス（およびオブジェクトセット）、コンテンツ制約、パラメータ化、拡張マーカー、およびバージョンブラケットです。拡張マーカーとバージョンのブラケットは、単純に削除（またはコメントアウト）できます。これらは使用されないので、情報オブジェクトクラスとオブジェクトセットの定義も削除またはコメントアウトできます。ほとんどの場合、次のチェックリストを使用できます。
o Remove all Information Set Class, Information Set Object, and Information Set Object Set definitions and imports from the file.
o すべての情報セットクラス、情報セットオブジェクト、および情報セットオブジェクトセットの定義とファイルからのインポートを削除します。
o Replace all fixed Type Information Set Class element references with the fixed type. (That is, replace FOO.&id with OBJECT IDENTIFIER.)
o 固定タイプの情報セットクラス要素参照を固定型で置き換えます。（つまり、foo。＆idをオブジェクト識別子に置き換えます。）
o Delete all simple constraints.
o すべての単純な制約を削除します。
o Delete all CONTAINING statements.
o すべての含張ステートメントを削除します。
o Replace all variable Type Information Set Class element references with either ANY or ANY DEFINED BY statements.
o すべての変数型情報を置き換えるクラス要素参照は、任意のまたは任意のステートメントによって定義された任意のもので置き換えます。
o Remove version and extension markers.
o バージョンと拡張マーカーを削除します。
o Manually enforce all instances of parameterized types.
o パラメータ化された型のすべてのインスタンスを手動で強制します。
The amount of change associated with upgrading from X.208 syntax to X.68x syntax is dependent on the reasons for changing and personal style. A minimalist approach could consist of altering any deprecated features, most commonly ANY DEFINED BY, and adding any necessary extensibility markers. A more comprehensive approach may include the introduction of constraints, parameterization, versioning, extensibility, etc.
X.208構文からX.68Xの構文へのアップグレードに関連する変更の量は、変更や個人用スタイルの理由によって異なります。ミニマリストアプローチは、廃止予定の機能を変更し、最も一般的には一般的に必要な拡張マーカーを追加し、追加することができます。より包括的なアプローチには、制約、パラメータ化、バージョン管理、拡張性などの導入が含まれる場合があります。
The following checklist can be used when upgrading a module without introducing constraints:
制約を導入せずにモジュールをアップグレードするときは、次のチェックリストを使用できます。
Use TYPE-IDENTIFIER.&Type for "ANY".
タイプ識別子を使用してください。 "any"のタイプ。
Use TYPE-IDENTIFIER.&Type for "ANY DEFINED BY ...".
タイプ識別子を使用してください。「定義された任意のもの」のタイプ。
When constraints are introduced during an upgrade, additional steps are necessary:
アップグレード中に制約が導入されると、追加のステップが必要です。
1. Identify each unique class that should be defined based on what types of things exist.
1. どのような種類のものに基づいて定義されるべき各固有のクラスを識別します。
2. Define an Information Object Class for each of the classes above with the appropriate elements.
2. 上記の各クラスの情報オブジェクトクラスを適切な要素で定義します。
3. Define all of the appropriate Information Object Sets based on the classes defined in step 2 along with the different places that they should be used.
3. ステップ2で定義されたクラスに基づいて、それらを使用する必要があるさまざまな場所に基づいて、すべての適切な情報オブジェクトセットを定義します。
4. Replace ANY by the appropriate class and variable type element.
4. 適切なクラスと変数型要素によって任意のものを置き換えます。
5. Replace ANY DEFINED BY with the appropriate variable type element and the components constraint. Replace the element used in the constraint with the appropriate fixed type element and simple constraint.
5. 適切な変数型要素とコンポーネントの制約を使用して定義された任意のものを置き換えます。制約で使用される要素を適切な固定型要素と単純な制約と置き換えます。
6. Add any simple constraints as appropriate.
6. 必要に応じて簡単な制約を追加してください。
7. Define any objects and fill in elements for object sets as appropriate.
7. オブジェクトを定義し、必要に応じてオブジェクトセットの要素を入力します。
Where a module is downgraded from X.68x syntax to X.208 there is loss of potential automated enforcement of constraints expressed by the author of the module being downgraded. These constraints should be captured in prose or ASN.1 comments and enforced through other means, as necessary.
モジュールがX.68X構文からX.208にダウングレードされている場合、ダウングレードされているモジュールの作成者によって表現された制約の自動化された能力が失われます。これらの制約は、必要に応じて、散文またはASN.1のコメントで捕獲され、他の手段を通して実施されるべきです。
Depending on the feature set of the ASN.1 compiler being used, the code to enforce and use constraints may be generated automatically or may require the programmer to do this independently. It is the responsibility of the programmer to ensure that the constraints on the ASN.1 expressed either in prose or in the ASN.1 module are actually enforced.
使用されているASN.1コンパイラの機能セットに応じて、制約を強制して使用するためのコードは自動的に生成されてもよく、またはプログラマにこれを独立して行う必要があるかもしれません。ASN.1の制約が実際に適用されていることを確認するのは、プログラマーの責任です。
[CCITT.X208.1988] International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, November 1988.
[CCITT.X208.1988]国際電話と電信諮問委員会、「抽象構文表記法の仕様（ASN.1）」、CCITT勧告X.208、1988年11月。
[CCITT.X680.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[CCITT.X680.2002]国際電話と電信諮問委員会、「Abstract Syntax Notation One（ASN.1）：基本表記の仕様」、CCITT勧告X.680、2002年7月。
[CCITT.X681.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Information object specification", CCITT Recommendation X.681, July 2002.
[CCITT.X681.2002]国際電話と電信諮問委員会、「Abstract Syntax Notation One（ASN.1）：情報オブジェクト仕様」、CCITT勧告X.681、2002年7月。
[CCITT.X682.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Constraint specification", CCITT Recommendation X.682, July 2002.
[CCITT.X682.2002]国際電話と電信諮問委員会、「Abstract Syntax Notation One（ASN.1）：制約仕様」、CCITT勧告X.682、2002年7月。
[CCITT.X683.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications", CCITT Recommendation X.683, July 2002.
[CCITT.X683.2002]国際電話と電信諮問委員会、「抽象構文表記法1（ASN.1）：ASN.1仕様のパラメータ化」、CCITT勧告X.683、2002年7月。
[CCITT.X209.1988] International Telephone and Telegraph Consultative Committee, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, 1988.
[CCITT.X209.1988]国際電話と電信諮問委員会、「抽象構文表記の基本符号化規則の仕様（ASN.1）」、CCITT勧告X.209,1988。
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002]国際電話と電信諮問委員会、「ASN.1エンコーディングルール：基本符号化規則（BER）、基準符号化規則（CER）および識別エンコーディング規則（DER）」、CCITT勧告X.6902002年7月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. ADAMS、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC 2560、1999年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R.、 "Cryptographic Message Syntax（CMS）"、STD 70、RFC 5652、2009年9月。
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
[RFC5911] Hoffman、P.およびJ.Schaad、「暗号メッセージ構文（CMS）およびS / MIMEのための新しいASN.1モジュール」、RFC 5911、2010年6月。
[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、「新しいASN.1公開鍵インフラストラクチャのための新しいASN.1モジュール（PKIX）」、RFC 5912、2010年6月。
Authors' Addresses
著者の住所
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102
Carl Wallace CygnaCom Solutions Suite 5400 7925 Jones Branch Drive Mclean、VA 22102
EMail: cwallace@cygnacom.com
Charles Gardiner BBN Technologies 10 Moulton Street Cambridge, MA 02138
チャールズガーディナBBNテクノロジー10 Moulton Street Cambridge、MA 02138
EMail: gardiner@bbn.com