RFC 3641 - Generic String Encoding Rules (GSER) for ASN.1 Types 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3641
タイトル : RFC 3641 - ASN.1型のための汎用文字列符号化規則（GSER）
翻訳編集 : 自動生成＆有志による翻訳・編集

[要約] RFC 3641 - Generic String Encoding Rules (GSER) for ASN.1 Typesは、ASN.1型のための一般的な文字列エンコーディングルールを定義しています。この文書は、ASN.1データ構造を人間が読みやすい形式で表現する方法を提供し、主にデバッグやプロトコル仕様の文書化に利用されます。関連するRFCには、ASN.1を定義するRFC 3642や、X.509証明書を扱うRFC 5280などがあります。GSERは、技術者がASN.1データを直接解釈しやすくするためのツールとして重要です。

Network Working Group                                            S. Legg
Request for Comments: 3641                           Adacel Technologies
Category: Standards Track                                   October 2003

Generic String Encoding Rules (GSER) for ASN.1 Types

ASN.1型のための汎用文字列符号化規則（GSER）

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.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.

このドキュメントは、汎用文字列符号化規則（GSER）と呼ばれる一連のASN.1エンコーディング規則を定義します。これは、任意のASN.1データ型の値に対して人間が読めるテキストエンコーディングを生成します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Generic String Encoding Rules. . . . . . . . . . . . . . . . .  3
       3.1.  Type Referencing Notations . . . . . . . . . . . . . . .  3
       3.2.  Restricted Character String Types. . . . . . . . . . . .  4
       3.3.  ChoiceOfStrings Types. . . . . . . . . . . . . . . . . .  5
       3.4.  Identifiers. . . . . . . . . . . . . . . . . . . . . . .  6
       3.5.  BIT STRING . . . . . . . . . . . . . . . . . . . . . . .  7
       3.6.  BOOLEAN. . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.7.  ENUMERATED . . . . . . . . . . . . . . . . . . . . . . .  8
       3.8.  INTEGER. . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.9.  NULL . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.10. OBJECT IDENTIFIER and RELATIVE-OID . . . . . . . . . . .  8
       3.11. OCTET STRING . . . . . . . . . . . . . . . . . . . . . .  9
       3.12. CHOICE . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.13. SEQUENCE and SET . . . . . . . . . . . . . . . . . . . . 10
       3.14. SEQUENCE OF and SET OF . . . . . . . . . . . . . . . . . 10
       3.15. CHARACTER STRING . . . . . . . . . . . . . . . . . . . . 11
       3.16. EMBEDDED PDV . . . . . . . . . . . . . . . . . . . . . . 11
       3.17. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . . 11

       3.18. INSTANCE OF. . . . . . . . . . . . . . . . . . . . . . . 11
       3.19. REAL . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.20. Variant Encodings. . . . . . . . . . . . . . . . . . . . 12
   4.  GSER Transfer Syntax . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.1.  Normative References . . . . . . . . . . . . . . . . . . 13
       6.2.  Informative References . . . . . . . . . . . . . . . . . 14
   7.  Intellectual Property Notice . . . . . . . . . . . . . . . . . 15
   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

1. Introduction

1. はじめに

This document defines a set of ASN.1 [8] encoding rules, called the Generic String Encoding Rules or GSER, that produce a human readable UTF-8 [6] character string encoding of ASN.1 values of any given arbitrary ASN.1 type.

このドキュメントは、汎用文字列符号化規則（GSER）と呼ばれる一連のASN.1 [8]エンコーディング規則を定義します。これは、任意のASN.1型のASN.1値に対して、人間が読めるUTF-8 [6]文字列エンコーディングを生成します。

Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER) [12] encoded value. The ASN.1 value is an abstract concept that is independent of any particular encoding. BER is just one possible encoding of an ASN.1 value.

「ASN.1値」は、基本符号化規則（BER）[12]でエンコードされた値を意味するものではないことに注意してください。ASN.1値は、特定のエンコーディングとは無関係な抽象的な概念です。BERは、ASN.1値の可能なエンコーディングの1つにすぎません。

GSER is based on ASN.1 value notation [8], with changes to accommodate the notation's use as a transfer syntax, and to support well established ad-hoc string encodings for Lightweight Directory Access Protocol (LDAP) [14] directory data types.

GSERはASN.1値表記[8]に基づいていますが、転送構文としての使用に対応するための変更が加えられており、Lightweight Directory Access Protocol（LDAP）[14]ディレクトリデータ型のための確立されたアドホックな文字列エンコーディングをサポートしています。

Though primarily intended for defining the LDAP-specific encoding of new LDAP attribute syntaxes and assertion syntaxes, these encoding rules could also be used in other domains where human readable renderings of ASN.1 values would be useful.

主に、新しいLDAP属性構文およびアサーション構文のLDAP固有のエンコーディングを定義することを意図していますが、これらのエンコーディング規則は、ASN.1値の人間が読める表現が役立つ他のドメインでも使用できます。

Referencing GSER is sufficient to define a human readable text encoding for values of a specific ASN.1 type, however other specifications may wish to provide a customized Augmented Backus-Naur Form (ABNF) [3] description, independent of the ASN.1, as a convenience for the implementor (equivalent ABNF for the GSER encodings for ASN.1 types commonly occurring in LDAP syntaxes is provided in a separate document [15]). Such a specification SHOULD state that if there is a discrepancy between the customized ABNF and the GSER encoding defined by this document, that the GSER encoding takes precedence.

GSERを参照することは、特定のASN.1型の値に対して人間が読めるテキストエンコーディングを定義するのに十分ですが、他の仕様では、実装者の便宜のために、ASN.1とは独立したカスタマイズされた拡張バッカス・ナウア記法（ABNF）[3]記述を提供したい場合があります（LDAP構文で一般的に発生するASN.1型のGSERエンコーディングのための同等のABNFは、別のドキュメント[15]で提供されています）。そのような仕様では、カスタマイズされたABNFとこのドキュメントで定義されたGSERエンコーディングの間に不一致がある場合、GSERエンコーディングが優先されることを明記すべきです（SHOULD）。

2. Conventions

2. 規約

Throughout this document, "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 value.

このドキュメント全体を通して、「型（type）」はASN.1型を意味し、「値（value）」はASN.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 BCP 14, RFC 2119 [1].

このドキュメントのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、BCP 14, RFC 2119 [1] に記載されているように解釈されるものとします。

3. Generic String Encoding Rules

3. 汎用文字列符号化規則

The GSER encoding of a value of any ASN.1 type is described by the following ABNF [3]:

任意のASN.1型の値のGSERエンコーディングは、以下のABNF [3] で記述されます：

Value = BitStringValue / BooleanValue / CharacterStringValue / ChoiceValue / EmbeddedPDVValue / EnumeratedValue / ExternalValue / GeneralizedTimeValue / IntegerValue / InstanceOfValue / NullValue / ObjectDescriptorValue / ObjectIdentifierValue / OctetStringValue / RealValue / RelativeOIDValue / SequenceOfValue / SequenceValue / SetOfValue / SetValue / StringValue / UTCTimeValue / VariantEncoding

The ABNF for each of the above rules is given in the following sections.

上記の各規則のABNFは、以下のセクションで示されています。

3.1 Type Referencing Notations

3.1. 型参照表記法

A value of a type with a defined type name is encoded according to the type definition on the right hand side of the type assignment for the type name.

定義された型名を持つ型の値は、その型名の型割り当ての右辺にある型定義に従ってエンコードされます。

A value of a type denoted by the use of a parameterized type with actual parameters is encoded according to the parameterized type with the DummyReferences [11] substituted with the actual parameters.

実パラメータを持つパラメータ化型を使用して示される型の値は、DummyReferences [11] を実パラメータで置換したパラメータ化型に従ってエンコードされます。

A value of a tagged or constrained type is encoded as a value of the type without the tag or constraint, respectively. Tags do not appear in the string encodings defined by this document. See X.680 [8] and X.682 [10] for the details of ASN.1 constraint notation.

タグ付き型または制約付き型の値は、それぞれタグまたは制約のない型の値としてエンコードされます。タグは、このドキュメントで定義される文字列エンコーディングには現れません。ASN.1制約表記の詳細については、X.680 [8] および X.682 [10] を参照してください。

A value of an open type denoted by an ObjectClassFieldType (Clause 14 of X.681 [9]) is encoded according to the specific type of the value.

ObjectClassFieldType（X.681 [9]の第14条）で示されるオープン型の値は、その値の特定の型に従ってエンコードされます。

A value of a fixed type denoted by an ObjectClassFieldType is encoded according to that fixed type.

ObjectClassFieldTypeで示される固定型の値は、その固定型に従ってエンコードされます。

A value of a selection type is encoded according to the type referenced by the selection type.

選択型の値は、選択型によって参照される型に従ってエンコードされます。

A value of a type described by TypeFromObject notation (Clause 15 of X.681 [9]) is encoded according to the denoted type.

TypeFromObject表記（X.681 [9]の第15条）によって記述された型の値は、示された型に従ってエンコードされます。

A value of a type described by ValueSetFromObjects notation (Clause 15 of X.681 [9]) is encoded according to the governing type.

ValueSetFromObjects表記（X.681 [9]の第15条）によって記述された型の値は、ガバニング型に従ってエンコードされます。

3.2. Restricted Character String Types

3.2. 制限された文字列型

The contents of a string value are encoded as a UTF-8 character string between double quotes, regardless of the ASN.1 string type. Depending on the ASN.1 string type and an application's internal representation of that string type, a translation to or from the UTF-8 character encoding may be required. NumericString, PrintableString, IA5String, and VisibleString (ISO646String) are compatible with UTF-8 and do not require any translation. BMPString (UCS-2) and UniversalString (UCS-4) have a direct mapping to and from UTF-8 [6]. For the remaining string types see X.680 [8]. Any embedded double quotes in the resulting UTF-8 character string are escaped by repeating the double quote characters.

文字列値の内容は、ASN.1文字列型に関係なく、二重引用符で囲まれたUTF-8文字列としてエンコードされます。ASN.1文字列型とその文字列型のアプリケーションの内部表現によっては、UTF-8文字エンコーディングへの変換、またはUTF-8からの変換が必要になる場合があります。NumericString、PrintableString、IA5String、およびVisibleString（ISO646String）はUTF-8と互換性があり、変換は必要ありません。BMPString（UCS-2）とUniversalString（UCS-4）はUTF-8 [6]との直接的なマッピングを持ちます。残りの文字列型についてはX.680 [8]を参照してください。結果として得られるUTF-8文字列内の埋め込み二重引用符は、二重引用符を繰り返すことによってエスケープされます。

A value of the NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, BMPString, UniversalString or UTF8String type is encoded according to the <StringValue> rule.

NumericString、PrintableString、TeletexString（T61String）、VideotexString、IA5String、GraphicString、VisibleString（ISO646String）、GeneralString、BMPString、UniversalString、またはUTF8String型の値が<StringValue>ルールに従ってエンコードされます。

StringValue = dquote *SafeUTF8Character dquote

      dquote            = %x22 ; " (double quote)

      SafeUTF8Character = %x00-21 / %x23-7F /   ; ASCII minus dquote
                          dquote dquote /       ; escaped double quote
                          %xC0-DF %x80-BF /     ; 2 byte UTF-8 character
                          %xE0-EF 2(%x80-BF) /  ; 3 byte UTF-8 character
                          %xF0-F7 3(%x80-BF)    ; 4 byte UTF-8 character

A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor type is encoded as a string value. GeneralizedTime and UTCTime use the VisibleString character set so the conversion to UTF-8 is trivial. ObjectDescriptor uses the GraphicString type.

GeneralizedTime型、UTCTime型、またはObjectDescriptor型の値は、文字列値としてエンコードされます。GeneralizedTimeとUTCTimeはVisibleString文字セットを使用するため、UTF-8への変換は容易です。ObjectDescriptorはGraphicString型を使用します。

GeneralizedTimeValue = StringValue UTCTimeValue = StringValue ObjectDescriptorValue = StringValue

3.3. ChoiceOfStrings Types

3.3. ChoiceOfStrings型

It is not uncommon for ASN.1 specifications to define types that offer a CHOICE between two or more alternative ASN.1 string types, where the particular alternative chosen carries no semantic significance (DirectoryString [7] being a prime example). Such types are defined to avoid having to use a complicated character encoding for all values when most values could use a simpler string type, or to deal with evolving requirements that compel the use of a broader character set while still maintaining backward compatibility.

ASN.1仕様において、2つ以上の代替ASN.1文字列型の間でCHOICE（選択）を提供する型を定義することは珍しくありません。ここで、選択された特定の代替案は意味的な重要性を持ちません（DirectoryString [7]がその代表例です）。このような型は、ほとんどの値がより単純な文字列型を使用できる場合に、すべての値に対して複雑な文字エンコーディングを使用しなければならない事態を避けるため、あるいは、下位互換性を維持しつつ、より広い文字セットの使用を強制する進化する要件に対処するために定義されます。

GSER encodes values of all the ASN.1 string types as UTF-8 character strings so the particular alternative that is chosen from a purely syntactic CHOICE of string types makes no material difference to the final encoding of the string value.

GSERはすべてのASN.1文字列型の値をUTF-8文字列としてエンコードするため、文字列型の純粋に構文上のCHOICEから選択された特定の代替案は、文字列値の最終的なエンコーディングに実質的な違いをもたらしません。

While there are certain ASN.1 constructs that betray the semantic significance of the alternatives within a CHOICE type, the absence of those constructs does not necessarily mean that a CHOICE type is purely syntactic. Therefore, it is necessary for specifications to declare the purely syntactic CHOICE types so that they may be more compactly encoded (see Section 3.12). These declared CHOICE types are referred to as ChoiceOfStrings types.

CHOICE型内の代替案の意味的な重要性を示す特定のASN.1構成要素が存在しますが、それらの構成要素が存在しないことは、必ずしもCHOICE型が純粋に構文的であることを意味するわけではありません。したがって、よりコンパクトにエンコードできるように（セクション3.12を参照）、仕様で純粋に構文的なCHOICE型を宣言する必要があります。これらの宣言されたCHOICE型は、ChoiceOfStrings型と呼ばれます。

To be eligible to be declared a ChoiceOfStrings type, an ASN.1 type MUST satisfy the following conditions.

ChoiceOfStrings型として宣言される資格を得るためには、ASN.1型は以下の条件を満たさなければなりません（MUST）。

a) The type is a CHOICE type.

a) 型はCHOICE型である。

b) The component type of each alternative is one of the following ASN.1 restricted string types: NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, BMPString, UniversalString or UTF8String.

b) 各代替案のコンポーネント型は、NumericString、PrintableString、TeletexString（T61String）、VideotexString、IA5String、GraphicString、VisibleString（ISO646String）、GeneralString、BMPString、UniversalStringまたはUTF8Stringのいずれかです。

c) All the alternatives are of different restricted string types, i.e., no two alternatives have the same ASN.1 restricted string type.

c) すべての代替案は異なる制限された文字列型である。すなわち、同じASN.1制限文字列型を持つ2つの代替案は存在しない。

d) Either none of the alternatives has a constraint, or all of the alternatives have exactly the same constraint.

d) 代替案のいずれにも制約がないか、またはすべての代替案がまったく同じ制約を持っている。

Tagging on the alternative types is ignored.

代替型に関するタグ付けは無視されます。

Consider the ASN.1 parameterized type definition of DirectoryString.

DirectoryStringのASN.1パラメータ化型定義を考えてみましょう。

      DirectoryString { INTEGER : maxSize } ::= CHOICE {
          teletexString     TeletexString (SIZE (1..maxSize)),
          printableString   PrintableString (SIZE (1..maxSize)),
          bmpString         BMPString (SIZE (1..maxSize)),
          universalString   UniversalString (SIZE (1..maxSize)),
          uTF8String        UTF8String (SIZE (1..maxSize)) }

Any use of the DirectoryString parameterized type with an actual parameter defines an ASN.1 type that satisfies the above conditions. Recognising that the alternative within a DirectoryString carries no semantic significance, this document declares (each and every use of) DirectoryString{} to be a ChoiceOfStrings type.

実パラメータを伴うDirectoryStringパラメータ化型の使用はすべて、上記の条件を満たすASN.1型を定義します。DirectoryString内の代替案が意味的な重要性を持たないことを認識し、このドキュメントはDirectoryString{}（のあらゆる使用）をChoiceOfStrings型として宣言します。

Other specifications MAY declare other types satisfying the above conditions to be ChoiceOfStrings types. The declaration SHOULD be made at the point where the ASN.1 type is defined, otherwise it SHOULD be made at the point where it is introduced as, or in, an LDAP attribute or assertion syntax.

他の仕様では、上記の条件を満たす他の型をChoiceOfStrings型として宣言してもよい（MAY）。宣言は、そのASN.1型が定義されている場所で行われるべきです（SHOULD）。そうでない場合は、LDAP属性構文またはアサーション構文として、あるいはその中で導入される場所で行われるべきです（SHOULD）。

3.4. Identifiers

3.4. 識別子

An <identifier> conforms to the definition of an identifier in ASN.1 notation (Clause 11.3 of X.680 [8]). It begins with a lowercase letter and is followed by zero or more letters, digits, and hyphens. A hyphen is not permitted to be the last character, nor is it to be followed by another hyphen. The case of letters in an identifier is always significant.

<identifier>（識別子）は、ASN.1表記における識別子の定義（X.680 [8]の第11.3条）に準拠します。これは小文字で始まり、0個以上の文字、数字、ハイフンが続きます。ハイフンは最後の文字であってはならず、別のハイフンの直後に続いてはなりません。識別子内の文字の大文字と小文字は常に区別されます。

      identifier    = lowercase *alphanumeric *(hyphen 1*alphanumeric)
      alphanumeric  = uppercase / lowercase / decimal-digit
      uppercase     = %x41-5A  ; "A" to "Z"
      lowercase     = %x61-7A  ; "a" to "z"
      decimal-digit = %x30-39  ; "0" to "9"
      hyphen        = "-"

3.5. BIT STRING

A value of the BIT STRING type is encoded according to the <BitStringValue> rule. If the definition of the BIT STRING type includes a named bit list, the <bit-list> form of <BitStringValue> MAY be used. If the number of bits in a BIT STRING value is a multiple of four, the <hstring> form of <BitStringValue> MAY be used. Otherwise, the <bstring> form of <BitStringValue> is used.

BIT STRING型の値は、<BitStringValue>ルールに従ってエンコードされます。BIT STRING型の定義が名前付きビットリストを含んでいる場合、<BitStringValue>の<bit-list>形式を使用してもよい（MAY）。BIT STRING値のビット数が4の倍数である場合、<BitStringValue>の<hstring>形式を使用してもよい（MAY）。それ以外の場合は、<BitStringValue>の<bstring>形式が使用されます。

      BitStringValue = bstring / hstring / bit-list

The <bit-list> rule encodes the one bits in the bit string value as a comma separated list of identifiers. Each <identifier> MUST be one of the identifiers in the named bit list, and MUST NOT appear more than once in the same <bit-list>. The <bstring> rule encodes each bit as the character "0" or "1" in order from the first bit to the last bit. The <hstring> rule encodes each group of four bits as a hexadecimal number where the first bit is the most significant. An odd number of hexadecimal digits is permitted.

<bit-list>ルールは、ビット文字列値の中で1になっているビットを、識別子のカンマ区切りリストとしてエンコードします。各<identifier>は、名前付きビットリスト内の識別子の1つでなければならず（MUST）、同じ<bit-list>内に複数回現れてはなりません（MUST NOT）。<bstring>ルールは、最初のビットから最後のビットへの順序で、各ビットを文字 "0" または "1" としてエンコードします。<hstring>ルールは、4ビットの各グループを16進数としてエンコードします。ここで、最初のビットが最上位ビットとなります。奇数個の16進数字も許可されます。

      bit-list          = "{" [ sp identifier
                             *( "," sp identifier ) ] sp "}"

      hstring           = squote *hexadecimal-digit squote %x48 ; '...'H

      hexadecimal-digit = %x30-39 /  ; "0" to "9"
                          %x41-46    ; "A" to "F"

      bstring           = squote *binary-digit squote %x42  ; '...'B
      binary-digit      = "0" / "1"

      sp                = *%x20  ; zero, one or more space characters
      squote            =  %x27  ; ' (single quote)

3.6. BOOLEAN

A value of the BOOLEAN type is encoded according to the <BooleanValue> rule.

BOOLEAN型の値は、<BooleanValue>ルールに従ってエンコードされます。

      BooleanValue = %x54.52.55.45 /   ; "TRUE"
                     %x46.41.4C.53.45  ; "FALSE"

3.7. ENUMERATED

A value of the ENUMERATED type is encoded according to the <EnumeratedValue> rule. The <identifier> MUST be one of those in the list of enumerations in the definition of the ENUMERATED type.

ENUMERATED型の値は、<EnumeratedValue>ルールに従ってエンコードされます。<identifier>は、ENUMERATED型の定義にある列挙リストのいずれかでなければなりません（MUST）。

      EnumeratedValue = identifier

3.8. INTEGER

A value of the INTEGER type is encoded according to the <IntegerValue> rule. If the definition of the INTEGER type includes a named number list, the <identifier> form of <IntegerValue> MAY be used, in which case the <identifier> MUST be one of the identifiers in the named number list.

INTEGER型の値は、<IntegerValue>ルールに従ってエンコードされます。INTEGER型の定義が名前付き番号リストを含んでいる場合、<IntegerValue>の<identifier>形式を使用してもよい（MAY）。その場合、<identifier>は名前付き番号リスト内の識別子の1つでなければなりません（MUST）。

IntegerValue = "0" / positive-number / ("-" positive-number) / identifier

      positive-number = non-zero-digit *decimal-digit
      non-zero-digit  = %x31-39  ; "1" to "9"

3.9. NULL

A value of the NULL type is encoded according to the <NullValue> rule.

NULL型の値は<NullValue>ルールに従ってエンコードされます。

      NullValue = %x4E.55.4C.4C  ; "NULL"

3.10. OBJECT IDENTIFIER and RELATIVE-OID

3.10. OBJECT IDENTIFIER および RELATIVE-OID

A value of the OBJECT IDENTIFIER type is encoded according to the <ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule allows either a dotted decimal representation of the OBJECT IDENTIFIER value or an object descriptor name, i.e., <descr>. The <descr> rule is described in RFC 2252 [4]. An object descriptor name is potentially ambiguous and should be used with care.

OBJECT IDENTIFIER型の値は、<ObjectIdentifierValue>ルールに従ってエンコードされます。<ObjectIdentifierValue>ルールは、OBJECT IDENTIFIER値のドット区切り10進表記、またはオブジェクト記述子名、すなわち<descr>のいずれかを許可します。<descr>ルールはRFC 2252 [4]で記述されています。オブジェクト記述子名は潜在的に曖昧であるため、慎重に使用すべきです。

      ObjectIdentifierValue = numeric-oid / descr
      numeric-oid           = oid-component 1*( "." oid-component )
      oid-component         = "0" / positive-number

A value of the RELATIVE-OID type is encoded according to the <RelativeOIDValue> rule.

RELATIVE-OID型の値は、<RelativeOIDValue>ルールに従ってエンコードされます。

RelativeOIDValue = oid-component *( "." oid-component )

3.11. OCTET STRING

A value of the OCTET STRING type is encoded according to the <OctetStringValue> rule. The octets are encoded in order from the first octet to the last octet. Each octet is encoded as a pair of hexadecimal digits where the first digit corresponds to the four most significant bits of the octet. If the hexadecimal string does not have an even number of digits, the four least significant bits in the last octet are assumed to be zero.

OCTET STRING型の値は、<OctetStringValue>ルールに従ってエンコードされます。オクテットは、最初のオクテットから最後のオクテットへの順序でエンコードされます。各オクテットは、1対の16進数字としてエンコードされ、最初の数字がそのオクテットの最上位4ビットに対応します。16進文字列の桁数が偶数でない場合、最後のオクテットの最下位4ビットはゼロであると見なされます。

      OctetStringValue = hstring

3.12. CHOICE

A value of a CHOICE type is encoded according to the <ChoiceValue> rule. The <ChoiceOfStringsValue> encoding MAY be used if the corresponding CHOICE type has been declared a ChoiceOfStrings type. This document declares DirectoryString to be a ChoiceOfStrings type (see Section 3.3). Otherwise, the <IdentifiedChoiceValue> form of <ChoiceValue> is used.

CHOICE型の値は、<ChoiceValue>ルールに従ってエンコードされます。対応するCHOICE型がChoiceOfStrings型として宣言されている場合、<ChoiceOfStringsValue>エンコーディングを使用してもよい（MAY）。このドキュメントは、DirectoryStringをChoiceOfStrings型として宣言します（セクション3.3を参照）。それ以外の場合は、<ChoiceValue>の<IdentifiedChoiceValue>形式が使用されます。

ChoiceValue = IdentifiedChoiceValue / ChoiceOfStringsValue IdentifiedChoiceValue = identifier ":" Value ChoiceOfStringsValue = StringValue

For implementations that recognise the internal structure of the DirectoryString CHOICE type (e.g., X.500 directories [16]), if the character string between the quotes in a <StringValue> contains only characters that are permitted in a PrintableString, the DirectoryString is assumed to use the printableString alternative, otherwise it is assumed to use the uTF8String alternative. The <IdentifiedChoiceValue> rule MAY be used for a value of type DirectoryString to indicate an alternative other than the one that would be assumed from the string contents. No matter what alternative is chosen, the <Value> will still be a UTF-8 encoded character string. However, it is a syntax error if the characters in the UTF-8 string cannot be represented in the string type of the chosen alternative.

DirectoryString CHOICE型の内部構造を認識する実装（例：X.500ディレクトリ[16]）の場合、<StringValue>の引用符内の文字列にPrintableStringで許可されている文字のみが含まれている場合、DirectoryStringはprintableStringの代替を使用すると想定され、そうでない場合はuTF8Stringの代替を使用すると想定されます。<IdentifiedChoiceValue>ルールは、文字列の内容から想定されるもの以外の代替を示すために、DirectoryString型の値に使用してもよい（MAY）。どの代替が選択されたとしても、<Value>は依然としてUTF-8エンコードされた文字列です。ただし、UTF-8文字列内の文字が、選択された代替の文字列型で表現できない場合は、構文エラーとなります。

Implementations that do not care about the internal structure of a DirectoryString value MUST be able to parse the <IdentifiedChoiceValue> form for a DirectoryString value, though the particular identifier found will be of no interest.

DirectoryString値の内部構造に関知しない実装は、DirectoryString値の<IdentifiedChoiceValue>形式を解析できなければなりません（MUST）。ただし、見つかった特定の識別子は重要ではありません。

3.13. SEQUENCE and SET

3.13. SEQUENCE および SET

A value of a SEQUENCE type is encoded according to the <SequenceValue> rule. The <ComponentList> rule encodes a comma separated list of the particular component values present in the SEQUENCE value, where each component value is preceded by the corresponding identifier from the SEQUENCE type definition. The components are encoded in the order of their definition in the SEQUENCE type.

SEQUENCE型の値は、<SequenceValue>ルールに従ってエンコードされます。<ComponentList>ルールは、SEQUENCE値に存在する特定のコンポーネント値のカンマ区切りリストをエンコードします。ここで、各コンポーネント値の前には、SEQUENCE型定義の対応する識別子が置かれます。コンポーネントは、SEQUENCE型における定義の順序でエンコードされます。

      SequenceValue = ComponentList

      ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
      NamedValue    = identifier msp Value
      msp           = 1*%x20  ; one or more space characters

A value of a SET type is encoded according to the <SetValue> rule. The components are encoded in the order of their definition in the SET type (i.e., just like a SEQUENCE value). This is a deliberate departure from ASN.1 value notation where the components of a SET can be written in any order.

SET型の値は、<SetValue>ルールに従ってエンコードされます。コンポーネントは、SET型における定義の順序でエンコードされます（つまり、SEQUENCE値とまったく同様です）。これは、SETのコンポーネントを任意の順序で記述できるASN.1値表記からの意図的な逸脱です。

      SetValue = ComponentList

SEQUENCE and SET type definitions are sometimes extended by the inclusion of additional component types, so an implementation SHOULD be capable of skipping over any <NamedValue> encoding with an identifier that is not recognised, on the assumption that the sender is using a more recent definition of the SEQUENCE or SET type.

SEQUENCEおよびSET型の定義は、追加のコンポーネント型を含めることによって拡張されることがあるため、実装は、送信者がSEQUENCEまたはSET型のより新しい定義を使用していると仮定して、認識されない識別子を持つ<NamedValue>エンコーディングをスキップできるべきです（SHOULD）。

3.14. SEQUENCE OF and SET OF

3.14. SEQUENCE OF および SET OF

A value of a SEQUENCE OF type is encoded according to the <SequenceOfValue> rule, as a comma separated list of the instances in the value. Each instance is encoded according to the component type of the SEQUENCE OF type.

SEQUENCE OF型の値は、<SequenceOfValue>ルールに従って、値内のインスタンスのカンマ区切りリストとしてエンコードされます。各インスタンスは、SEQUENCE OF型のコンポーネント型に従ってエンコードされます。

      SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"

A value of a SET OF type is encoded according to the <SetOfValue> rule, as a list of the instances in the value. Each instance is encoded according to the component type of the SET OF type.

SET OF型の値は、<SetOfValue>ルールに従って、値内のインスタンスのリストとしてエンコードされます。各インスタンスは、SET OF型のコンポーネント型に従ってエンコードされます。

      SetOfValue      = "{" [ sp Value *( "," sp Value) ] sp "}"

3.15. CHARACTER STRING

A value of the unrestricted CHARACTER STRING type is encoded according to the corresponding SEQUENCE type defined in Clause 40.5 of X.680 [8] (see [15] for equivalent ABNF).

無制限のCHARACTER STRING型の値は、X.680 [8]の第40.5条で定義されている対応するSEQUENCE型に従ってエンコードされます（同等のABNFについては[15]を参照）。

      CharacterStringValue = SequenceValue

3.16. EMBEDDED PDV

A value of the EMBEDDED PDV type is encoded according to the corresponding SEQUENCE type defined in Clause 33.5 of X.680 [8] (see [15] for equivalent ABNF).

EMBEDDED PDV型の値は、X.680 [8]の第33.5条で定義されている対応するSEQUENCE型に従ってエンコードされます（同等のABNFについては[15]を参照）。

      EmbeddedPDVValue = SequenceValue

3.17. EXTERNAL

A value of the EXTERNAL type is encoded according to the corresponding SEQUENCE type defined in Clause 8.18.1 of X.690 [12] (see [15] for equivalent ABNF).

EXTERNAL型の値は、X.690 [12]の第8.18.1条で定義されている対応するSEQUENCE型に従ってエンコードされます（同等のABNFについては[15]を参照）。

      ExternalValue = SequenceValue

3.18. INSTANCE OF

A value of the INSTANCE OF type is encoded according to the corresponding SEQUENCE type defined in Annex C of X.681 [9].

INSTANCE OF型の値は、X.681 [9]の附属書Cで定義されている対応するSEQUENCE型に従ってエンコードされます。

      InstanceOfValue = SequenceValue

3.19. REAL

A value of the REAL type MUST be encoded as "0" if it is zero, otherwise it is encoded as the special value <PLUS-INFINITY>, the special value <MINUS-INFINITY>, an optionally signed <realnumber>, or as a value of the corresponding SEQUENCE type for REAL defined in Clause 20.5 of X.680 [8] (see [15] for equivalent ABNF).

REAL型の値は、ゼロの場合は "0" としてエンコードしなければなりません（MUST）。それ以外の場合は、特殊値 <PLUS-INFINITY>、特殊値 <MINUS-INFINITY>、オプションで符号付きの <realnumber>、または X.680 [8] の第20.5条で定義されたREALに対応するSEQUENCE型の値としてエンコードされます（同等のABNFについては[15]を参照）。

      RealValue  = "0"               ; zero REAL value
                   / PLUS-INFINITY   ; positive infinity
                   / MINUS-INFINITY  ; negative infinity
                   / realnumber      ; positive base 10 REAL value
                   / "-" realnumber  ; negative base 10 REAL value
                   / SequenceValue   ; non-zero REAL value, base 2 or 10

      realnumber = mantissa exponent
      mantissa   = (positive-number [ "." *decimal-digit ])
                   / ( "0." *("0") positive-number )
      exponent   = "E" ( "0" / ([ "-" ] positive-number))

      PLUS-INFINITY  = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
                          ; "PLUS-INFINITY"
      MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
                          ; "MINUS-INFINITY"

3.20. Variant Encodings

3.20. バリアントエンコーディング

The values of some named complex ASN.1 types have special string encodings. These special encodings are always used instead of the encoding that would otherwise apply based on the ASN.1 type definition.

名前付き複合ASN.1型のいくつかの値は、特別な文字列エンコーディングを持ちます。これらの特別なエンコーディングは、ASN.1の定義に基づいて適用されるエンコードの代わりに常に使用されます。

VariantEncoding = RDNSequenceValue / RelativeDistinguishedNameValue / ORAddressValue

A value of the RDNSequence type, i.e., a distinguished name, is encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN character string. The character string is first derived according to the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then encoded as if it were a UTF8String value, i.e., between double quotes with any embedded double quotes escaped by being repeated.

RDNSequence型の値、すなわち識別名（Distinguished Name）は、<RDNSequenceValue>ルールに従って、引用符付きのLDAPDN文字列としてエンコードされます。文字列は、まずRFC 2253 [5]のセクション3の<distinguishedName>ルールに従って導出され、次にそれがUTF8String値であるかのように、すなわち、埋め込まれた二重引用符を繰り返すことでエスケープした上で、二重引用符で囲んでエンコードされます。

      RDNSequenceValue = StringValue

A RelativeDistinguishedName value that is not part of an RDNSequence value is encoded according to the <RelativeDistinguishedNameValue> rule as a quoted character string. The character string is first derived according to the <name-component> rule in Section 3 of RFC 2253 [5], and then encoded as if it were a UTF8String value.

RDNSequence値の一部ではないRelativeDistinguishedName値は、<RelativeDistinguishedNameValue>ルールに従って、引用符付き文字列としてエンコードされます。文字列は、まずRFC 2253 [5]のセクション3の<name-component>ルールに従って導出され、次にそれがUTF8String値であるかのようにエンコードされます。

      RelativeDistinguishedNameValue = StringValue

A value of the ORAddress type is encoded according to the <ORAddressValue> rule as a quoted character string. The character string is first derived according to the textual representation of MTS.ORAddress from RFC 2156 [2], and then encoded as if it were an IA5String value.

ORAddress型の値は、<ORAddressValue>ルールに従って、引用符付き文字列としてエンコードされます。文字列は、まずRFC 2156 [2]のMTS.ORAddressのテキスト表現に従って導出され、次にそれがIA5String値であるかのようにエンコードされます。

      ORAddressValue = StringValue

4. GSER Transfer Syntax

4. GSER転送構文

The following OBJECT IDENTIFIER has been assigned by Adacel Technologies, under an arc assigned to Adacel by Standards Australia, to identify the Generic String Encoding Rules:

以下のOBJECT IDENTIFIERは、Generic String Encoding Rulesを識別するために、Standards AustraliaによってAdacelに割り当てられたアークの下で、Adacel Technologiesによって割り当てられました。

{ 1 2 36 79672281 0 0 }

{1 2 36 79672281 0 0}

This OBJECT IDENTIFIER would be used, for example, to describe the transfer syntax for a GSER encoded data-value in an EMBEDDED PDV value.

このOBJECT IDENTIFIERは、例えば、EMBEDDED PDV値内のGSERエンコードされたデータ値の転送構文を記述するために使用されます。

5. Security Considerations

5. セキュリティに関する考慮事項

The Generic String Encoding Rules do not define a canonical encoding. That is, a transformation from a GSER encoding into some other encoding (e.g., BER) and back into GSER will not necessarily reproduce the original GSER octet encoding. Therefore, GSER MUST NOT be used where a canonical encoding is needed.

Generic String Encoding Rulesは、正規化エンコーディング（canonical encoding）を定義しません。つまり、GSERエンコーディングから他のエンコーディング（例：BER）へ変換し、再びGSERに戻したとしても、必ずしも元のGSERオクテットエンコーディングが再現されるとは限りません。したがって、正規化エンコーディングが必要な場所でGSERを使用してはなりません（MUST NOT）。

Furthermore, GSER does not necessarily enable the exact octet encoding of values of the TeletexString, VideotexString, GraphicString or GeneralString types to be reconstructed, so a transformation from a Distinguished Encoding Rules (DER) [12] encoding to GSER and back to DER may not reproduce the original DER encoding. Therefore, GSER MUST NOT be used to re-encode, whether for storage or transmission, ASN.1 abstract values whose original binary encoding must be recoverable. Such recovery is needed for the verification of digital signatures. In such cases, protocols ought to use DER or a DER-reversible encoding.

さらに、GSERは、TeletexString、VideotexString、GraphicString、またはGeneralString型の値の正確なオクテットエンコーディングの再構築を必ずしも可能にしないため、識別符号化規則（DER）[12]エンコーディングからGSERへ変換し、DERに戻したとしても、元のDERエンコーディングが再現されない可能性があります。したがって、保存用か送信用かに関わらず、元のバイナリエンコーディングが復元可能でなければならないASN.1抽象値を再エンコードするためにGSERを使用してはなりません（MUST NOT）。このような復元は、デジタル署名の検証に必要です。そのような場合、プロトコルはDERまたはDER可逆エンコーディングを使用すべきです。

When interpreting security-sensitive fields, and in particular fields used to grant or deny access, implementations MUST ensure that any comparisons are done on the underlying abstract value, regardless of the particular encoding used.

セキュリティに敏感なフィールド、特にアクセスの許可または拒否に使用されるフィールドを解釈する場合、実装は、使用される特定のエンコーディングに関係なく、基礎となる抽象値に対して比較が行われることを保証しなければなりません（MUST）。

6. References

6. 参考文献

6.1. Normative References

6.1. 規範的参考文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.

[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.

[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

   [7]  ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
        Information Technology - Open Systems Interconnection - The
        Directory: Selected attribute types

   [8]  ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Specification of basic notation

   [9]  ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Information object specification

   [10] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Constraint specification

   [11] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Parameterization of ASN.1 specifications

[12] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)

6.2. Informative References

6.2. 参考引用文献

[13] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.

[14] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.

[15] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003.

   [16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
        Information Technology - Open Systems Interconnection - The
        Directory: Overview of concepts, models and services

7. Intellectual Property Notice

7. 知的財産権に関する表示

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.

IETFは、このドキュメントに記載された技術の実装または使用に関連すると主張される可能性のある知的財産権やその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが利用可能であるか否かの範囲に関して、いかなる立場も取りません。また、そのような権利を特定するための努力を行ったことも表明しません。標準化過程および標準関連文書における権利に関するIETFの手順に関する情報は、BCP-11に記載されています。公開のために利用可能にされた権利の主張のコピー、および利用可能にされるライセンスの保証、あるいはこの仕様の実装者や利用者によるそのような所有権の使用に対する一般的なライセンスまたは許可を得るために行われた試みの結果は、IETF事務局から入手できます。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETFは、この標準を実践するために必要となる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について、関心のある当事者が注意を喚起することを求めます。情報はIETF事務局長宛てに送付してください。

8. Author's Address

8. 著者の住所

Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA

   Phone: +61 3 8530 7710
   Fax:   +61 3 8530 7888
   EMail: steven.legg@adacel.com.au

9. Full Copyright Statement

9. 完全な著作権表示

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントおよびその翻訳は、コピーして他者に提供することができ、その内容にコメントしたり、説明したり、実装を支援したりする派生著作物は、いかなる種類の制限もなく、全体または一部を準備、コピー、公開、配布することができます。ただし、上記の著作権表示およびこの段落が、そのようなすべてのコピーおよび派生著作物に含まれていることが条件となります。ただし、このドキュメント自体は、著作権表示やインターネットソサエティまたは他のインターネット組織への参照を削除するなど、いかなる方法でも変更してはなりません。ただし、インターネット標準を開発する目的で必要な場合（その場合はインターネット標準プロセスで定義された著作権の手順に従う必要があります）、または英語以外の言語に翻訳する必要がある場合は除きます。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

上記で付与された制限付きの許可は永続的なものであり、インターネットソサエティまたはその後継者や譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントおよびここに含まれる情報は「現状のまま」提供され、インターネットソサエティおよびインターネットエンジニアリングタスクフォースは、明示または黙示を問わず、ここに含まれる情報の使用がいかなる権利も侵害しないという保証や、商品性または特定の目的への適合性の黙示の保証を含むがこれらに限定されない、すべての保証を否認します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディタ機能のための資金は、現在インターネットソサエティによって提供されています。