Internet Engineering Task Force (IETF) C. Wallace
Request for Comments: 6025 Cygnacom Solutions
Category: Informational C. Gardiner
ISSN: 2070-1721 BBN Technologies
October 2010
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模块从ASN.1的一个版本转换为另一个版本，而不会导致“线路上的位”发生变化。本文档不提供ASN.1任何版本的全面教程。相反，它解决了IETF安全区域规范中使用的ASN.1特性，重点是随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.
版权所有（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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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模块转换为新的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的两个不同版本。旧版本（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语法时，或者将ASN.1模块从X.208语法转换为X.68x语法时，许多定义不需要更改，也不受益于更改。对[RFC5911]和[RFC5912]更新的原始ASN.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 }
-- from RFC 5652
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
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 }
-- 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年不推荐使用ANY-DEFINED-BY，但它出现在一些现行规范中。[RFC5280]中的AttributeValue定义使用带有“由注释定义”的ANY将值绑定到类型标识符字段。
-- from RFC 5280
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
-- from RFC 5280
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY -- DEFINED BY AttributeType
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]中Extension和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
}
-- 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 }
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 basicConstraints时，extnValue字段包含编码的basicConstraints作为八位字节字符串的值，如下面编码扩展的转储所示。
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
: }
: }
: }
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
FOO ::= TYPE-IDENTIFIER
BAR ::= 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.
类型标识符是[CCITT.X681.2002]附录A中预定义的信息对象类之一。这提供了从对象标识符到数据类型的简单映射。&id上的标记唯一表示此值在信息对象集中只能出现一次；但是，可以使用相同的&id值定义多个对象。
[RFC5911] uses the TYPE-IDENTIFIER construction to update the definition of ContentInfo, as shown below.
[RFC5911]使用类型标识符构造来更新ContentInfo的定义，如下所示。
-- TYPE-IDENTIFIER definition from X.681
TYPE-IDENTIFIER ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id}
-- 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
-- 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})}
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, ... }
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}
-- 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 信息对象类的定义：类型标识符和内容类型是信息对象类。
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 信息对象集的定义：ContentSet是一个信息对象集。
o Usage of an information object: The definition of ContentInfo uses information from the CONTENT-TYPE information object class.
o 信息对象的用法：ContentInfo的定义使用CONTENT-TYPE信息对象类中的信息。
o Defining constraints using an object set: Both the contentType and content fields are constrained by ContentSet.
o 使用对象集定义约束：contentType和content字段都受ContentSet约束。
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.
如上所述，类型标识符只是将对象标识符与任意数据类型相关联。CONTENT-TYPE是类型标识符。WITH SYNTAX组件允许以更自然的语言表达信息对象定义。
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关联的信息对象的名称。它是内容类型信息对象类的实例。&Type字段被分配值SignedData，&id字段被分配值id SignedData。上面的示例使用类型标识符定义的WITH syntax组件提供的语法。不使用所提供语法的等效定义如下：
ct-SignedData CONTENT-TYPE ::=
{
&id id-signedData,
&Type SignedData
}
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").
ContentSet是从CONTENT-TYPE信息对象类派生的一组信息对象的名称。该集合包含六个信息对象，并且是可扩展的，如省略号所示（请参见第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
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.
ContentInfo中的两个字段都受约束。contentType字段使用一个简单的表约束进行约束，该约束将值限制为ContentSet中对象的相应字段中的值。内容字段使用组件关系约束进行约束。约束将在下一节中讨论。
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编译器能够使用简单表约束检查字段是否包含一个合法值。
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和CrlexExtensions集合之间存在一些重叠。
-- 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 }
-- 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 }}
SignedAttributes ::= Attributes {{ SignedAttributesSet }}
SignedAttributesSet ATTRIBUTE ::=
{ aa-signingTime | aa-messageDigest | aa-contentType, ... }
SignedAttributesSet ATTRIBUTE ::=
{ aa-signingTime | aa-messageDigest | aa-contentType, ... }
UnsignedAttributes ATTRIBUTE ::= { aa-countersignature, ... }
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
-- from updated RFC 2560 module in [RFC5912]
RESPONSE ::= TYPE-IDENTIFIER
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
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.
在本例中，响应字段被约束为包含由responseType字段标识的类型。控制字段使用atNotation标识，例如“@responseType”。atNotation可以相对于最外层的序列、集合或选项来定义，也可以相对于与atNotation关联的字段来定义。当“@”后面没有“.”时，该字段将显示为最外层序列、集合或选项的成员。当“@”后面紧接着一个“.”时，每个“.”表示一个序列、集合或选项，该序列、集合或选项以包含与atNotation关联的字段的序列、集合或选项开头。例如，ResponseBytes可以按如下所示编写。在本例中，语法非常相似，因为最里面和最外面的序列、集合或选项是相同的。
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@.responseType}))}
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
[RFC5912]中的TaggedRequest示例提供了最外层和最内层序列、集合或选择不同的示例。相对于定义中包含的atNotation
requestMessageValue field, the outermost SEQUENCE, SET, or CHOICE is TaggedRequest, and the innermost is the SEQUENCE used to define the orm field.
requestMessageValue字段，最外层的序列、集合或选项是TaggedRequest，最内层的序列用于定义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})
}
}
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
}
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}))
}
-- 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.
或者，上面的示例可以使用正确的atNotation编写，如下所示，算法字段的定义包含在ToBeSigned中。
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}))
}
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
@算法识别器
@.algorithm
@.算法
The atNotation for the signature field has only one representation.
签名字段的atNotation只有一种表示形式。
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字段的值从ExtensionSet对象集中选择的信息对象关联的类型的编码。由于第2.2.2节“组件关系约束”中所述的原因，SubjectPublicKeyInfo定义依赖散文将位字符串绑定到类型标识符，因为不可能表示包含组件关系约束的内容约束，以将算法字段内的类型值绑定到subjectPublicKey字段。
-- 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
}
-- 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
}
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 [RFC5912]
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{SignatureAlgorithms}},
signature BIT STRING
}
-- from updated RFC5280 module in [RFC5912]
Certificate ::= SIGNED{TBSCertificate}
-- 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
参数不必是简单类型。下面的示例演示如何使用信息对象类和信息对象集作为参数。算法标识符定义中的第一个参数是信息对象类。用于此参数的信息对象类必须具有&id和&Params字段，它们确定算法和参数字段的类型。信息对象类中可能存在其他字段，但算法标识符的定义不使用这些字段，如SIGNATURE-ALGORITHM类所示
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.
如下所示。第二个参数是用于约束“算法”和“参数”字段中出现的值的信息对象集。
-- from [RFC5912]
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet}
::= SEQUENCE
{
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE.&Params
({AlgorithmSet}{@algorithm}) OPTIONAL
}
-- 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]
}
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
}
-- 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]提供了两种用于支持可扩展性的机制：扩展标记和版本括号。
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.
延伸标记由省略号表示（即，三个相邻的句点）。扩展标记包含在规范中协议设计者预期未来更改的地方。这也可以通过包含ASN.1模块定义中隐含的可扩展性来实现。隐含的可扩展性相当于在ASN.1模块中定义的每种类型中包含一个扩展标记。在定义对象集的[RFC5911]和[RFC5912]中使用扩展性标记。在其他情况下，更新的模块追溯性地添加了扩展标记，其中字段通过更新添加到早期版本，如下面的CertificateChoices示例所示。
Examples:
示例：
-- from updated RFC 3370 module in [RFC5911]
KeyAgreementAlgs KEY-AGREE ::= { kaa-esdh | kaa-ssdh, ...}
-- 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]]
}
-- 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]在TBSCertificate的定义中添加了版本括号，以说明如何添加issuerUniqueID、SubjectArchitectureQueId和extensions字段，如下所示。
-- 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
]], ... }
-- 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:
至少，将ASN.1模块从X.68x语法降级到X.208需要删除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".
对“任意”使用类型标识符和类型。
Use TYPE-IDENTIFIER.&Type for "ANY DEFINED BY ...".
使用TYPE-IDENTIFIER.&TYPE表示“任何定义者…”。
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模块表示的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]国际电话电报咨询委员会，“抽象语法符号1规范（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]国际电话电报咨询委员会，“抽象语法符号一（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]国际电话电报咨询委员会，“抽象语法符号1（ASN.1）：信息对象规范”，CCITT建议X.6812002年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]国际电话电报咨询委员会，“抽象语法符号1（ASN.1）：约束规范”，CCITT建议X.6822002年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]国际电话电报咨询委员会，“抽象语法符号1（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.690，2002年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 25601999年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 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年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 59112010年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，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
Authors' Addresses
作者地址
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102
卡尔·华莱士·辛尼亚康解决方案套房5400 7925弗吉尼亚州麦克莱恩琼斯支路22102
EMail: cwallace@cygnacom.com
EMail: cwallace@cygnacom.com
Charles Gardiner BBN Technologies 10 Moulton Street Cambridge, MA 02138
马萨诸塞州剑桥莫尔顿街10号Charles Gardiner BBN Technologies 02138
EMail: gardiner@bbn.com
EMail: gardiner@bbn.com