[要約] 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）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット社会（2003）。全著作権所有。
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）と呼ばれる抽象構文表記法のセット（GSER）を定義しています。
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
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の値の文字列エンコーディングタイプ。
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]ディレクトリデータ型のための確立されたAD-HOC文字列エンコーディングをサポートします。
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]説明を提供したいと思うかもしれない。実装者の利便性として（GSERエンコーディングのための同等のABNFは、LDAP構文で一般的に発生しているタイプのための同等のABNFは別の文書[15]）で提供されています。そのような仕様は、カスタマイズされたABNFとこの文書によって定義されたGSERエンコーディングとの間に不一致がある場合、GSERエンコードが優先されることを述べるべきである。
Throughout this document, "type" shall be taken to mean an ASN.1 type, and "value" shall be taken to mean an ASN.1 value.
この文書全体を通して、ASN.1の種類を意味するように「タイプ」とし、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].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、BCP 14、RFC 2119 [1]に記載されているように解釈される。
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
value = bitStringValue / BooeanValue / CharacterStringValue / ChoiceValue / EnveddedPDVValue / enumeratedValue / experdEdpDValue / enaumeratedValue / intermalvalue / instancefalue / nullValue / objectDescriptorValue / objectIdentifierValue / sequenceFalue / sequenceValue / setOfValue / setValue / stringvalue / variantEncoding
The ABNF for each of the above rules is given in the following sections.
上記の各規則のABNFは、以下のセクションで説明されています。
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 Notation（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）によって記述された型の値は、管理タイプに従って符号化される。
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文字エンコーディングへの翻訳が必要になる場合があります。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、GraphString、VisibleString（ISO646String）、GeneralString、BMPString、UniversalString、またはUTF8Stringタイプの値が<StringValue>ルールに従ってエンコードされます。
StringValue = dquote *SafeUTF8Character dquote
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.
一般化タイプタイプの値、utctime型、またはObjectDescriptorタイプの値は文字列値としてエンコードされています。GeneralizedTimeとutctime visibleString文字セットを使用して、UTF-8への変換が簡単です。ObjectDescriptorはGraphicStringタイプを使用します。
GeneralizedTimeValue = StringValue UTCTimeValue = StringValue ObjectDescriptorValue = StringValue
GeneralizedTimeValue = StringValue utctimevalue = StringValue ObjectDescriptorValue = StringValue.
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文字列型の間に選択を提供する型を定義することは珍しくありません。ここで、特定の代替案が意味的に意味を持たない、特定の代替案は意味的有意性を持っていません（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文字列としてエンコードしているため、文字列型の純粋に構文解除された文字列型から選択されている特定の選択肢は、文字列値の最終的なエンコーディングに値差を与えません。
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.
選択型内の選択肢の意味的意義を裏付ける特定のASN.1構築物があるが、それらの構築物が存在しないことは必ずしも選択型が純粋に構文的であることを意味するものではない。したがって、仕様がコンパクトに符号化される可能性があるように、純粋に構文的選択タイプを宣言する必要があります（セクション3.12を参照）。これらの宣言された選択タイプはChoecomEOFStrings型と呼ばれます。
To be eligible to be declared a ChoiceOfStrings type, an ASN.1 type MUST satisfy the following conditions.
ChoiceOfStringsタイプの宣言されている資格がある場合、ASN.1タイプは次の条件を満たす必要があります。
a) The type is a CHOICE type.
a) タイプは選択型です。
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、TeletexString（T61String）、VideoTexString、IA5String、GraphString、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) すべての代替案は異なる制限された文字列型のものです。
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.
ASN.1パラメータ化型DirectoryStringの定義を検討してください。
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 {}のDirectoryString {}をColectorOfStrings型に宣言します。
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.
他の仕様は、ColectorOfStrings型であるために上記の条件を満たす他のタイプを宣言することができます。宣言は、ASN.1タイプが定義されている時点で行う必要があります。そうしないと、それ以外の場合は、LDAP属性またはアサーションの構文として導入された時点で行われるべきです。
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.
<識別子>は、ASN.1表記の識別子の定義に準拠しています（X.680 [8]の節11.3）。それは小文字で始まり、続いてゼロ以上の文字、数字、およびハイフンが続きます。ハイフンは最後の文字であることは許されません。また、それに続く別のハイフンが続くこともありません。識別子の文字の場合は常に重要です。
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 = "-"
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.
ビット文字列型の値は、<BitStringValue>ルールに従ってエンコードされます。ビット列タイプの定義が名前付きビットリストを含む場合、<bit-lingValue>の<bit-list>形式を使用することができます。ビット文字列値のビット数が4の倍数である場合、<HSTRINGVALUE>の<hstring>形式を使用することができる。それ以外の場合は、<bystringValue>の<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ビットを識別子のコンマ区切りリストとしてエンコードします。各<識別子>は、名前付きビットリストの識別子の1つでなければならず、同じ<bit-list>に複数回表示されてはいけません。<bstring>ルールは、最初のビットから最後のビットへの順に、各ビットを文字 "0"または "1"としてエンコードします。<hstring>ルールは、4ビットの各グループを16進数として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)
A value of the BOOLEAN type is encoded according to the <BooleanValue> rule.
ブール型の値は、<booleanValue>ルールに従ってエンコードされます。
BooleanValue = %x54.52.55.45 / ; "TRUE"
%x46.41.4C.53.45 ; "FALSE"
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.
列挙型の値は、<enumeratedValue>ルールに従ってエンコードされます。<識別子>は、列挙型の定義内の列挙型のもののうちの1つでなければなりません。
EnumeratedValue = identifier
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.
整数型の値は<IntegerValue>ルールに従ってエンコードされます。整数型の定義が名前付き番号リストを含む場合、<Initivier>の<識別子>形式を使用することができます。その場合、<識別子>は、名前付き番号リストの識別子の1つにする必要があります。
IntegerValue = "0" / positive-number / ("-" positive-number) / identifier
IntegerValue = "0" /正数/（ " - "正数）/識別子
positive-number = non-zero-digit *decimal-digit
non-zero-digit = %x31-39 ; "1" to "9"
A value of the NULL type is encoded according to the <NullValue> rule.
NULL型の値は<NULLVALUE>ルールに従ってエンコードされます。
NullValue = %x4E.55.4C.4C ; "NULL"
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.
オブジェクト識別子タイプの値は、<ObjectIdentifierValue>ルールに従ってエンコードされます。<objectIdentifierValue>ルールは、オブジェクト識別子値の点線10進表現またはオブジェクト記述子名、すなわち<descl>を使用可能にします。<descar>ルールは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.
Relatel-OID型の値は、<RatelyOidValue>ルールに従ってエンコードされます。
RelativeOIDValue = oid-component *( "." oid-component )
RASTRAYOIDVALUE = OIDコンポーネント*（ "。" OIDコンポーネント）
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 Typeの値は、<OctetStringValue>ルールに従ってエンコードされます。オクテットは、最初のオクテットから最後のオクテットへの順に符号化されています。各オクテットは、最初の桁がオクテットの4つの最上位ビットに対応する1つの16進数の数字として符号化される。16進数の文字列に偶数の桁数がない場合、最後のオクテットの4つの最下位ビットはゼロであると見なされます。
OctetStringValue = hstring
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.
選択型の値は、<chociveValue>ルールに従ってエンコードされます。対応する選択型がColectorOfStrings型を宣言した場合、<ChociationOfStringsValue>エンコードを使用できます。この文書はDirectoryStringをColectorOfStrings型にすることを宣言します（セクション3.3を参照）。それ以外の場合は、<choiceValue>の<識別されたChoiceValue>形式が使用されます。
ChoiceValue = IdentifiedChoiceValue / ChoiceOfStringsValue IdentifiedChoiceValue = identifier ":" Value ChoiceOfStringsValue = StringValue
ChoiceValue = InvectifiedChoiceValue / ChociedOfStringsValue IndidifiedChoiceValue =識別子 "：" value choickOfStringsValue = 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 Typeの内部構造を認識する実装（例えば、X.500ディレクトリ[16]）の場合、<StringValue>の引用符の中の文字列には、PrintableStringで許可されている文字のみが含まれている場合、DirectoryStringが想定されます。PrintableStringの代替を使用するには、そうでなければUTF8Stringの代替を使用すると想定されます。<InventifiedCoiceValue>ルールは、文字列の内容から想定されるもの以外の代替方法を示すために、DirectoryStringの値に使用できます。選択されていなくても、<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値に対して<InvidifiedCoiceValue>フォームを解析できなければなりませんが、見つかった特定の識別子は興味がありません。
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.
シーケンスタイプの値は、<sequenceValue>ルールに従ってエンコードされます。<componentList>ルールは、シーケンス値に存在する特定のコンポーネント値のカンマ区切りリストをエンコードします。ここで、各コンポーネント値はシーケンス型定義から対応する識別子によって先行されます。コンポーネントは、シーケンス型で定義の順に符号化されています。
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.
設定型の値は、<setValue>ルールに従ってエンコードされます。コンポーネントは、設定されたタイプ（すなわち、シーケンス値と同じように）で定義順に符号化される。これは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.
シーケンスとセットタイプの定義は、追加のコンポーネントタイプを含めることによって拡張されることがあるため、送信者がより最近の定義を使用していると仮定して、認識されない識別子を使用して、任意の<NamedValue>エンコーディングをスキップすることができます。シーケンスタイプまたはセットタイプの。
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.
一連のタイプの値は、<SequenceOfValue>ルールに従って、値内のインスタンスのコンマ区切りリストとしてエンコードされます。各インスタンスは、タイプのシーケンスのコンポーネントタイプに従ってエンコードされます。
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.
タイプのセットの値は、値内のインスタンスのリストとして、<setOfValue>ルールに従ってエンコードされます。各インスタンスは、タイプのセットのコンポーネントタイプに従ってエンコードされます。
SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
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).
無制限の文字列タイプの値は、X.680 [8]の40.5項に定義されている対応するシーケンスタイプに従ってエンコードされます（同等のABNFについては、[15]を参照）。
CharacterStringValue = SequenceValue
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).
埋め込まれたPDVタイプの値は、X.680 [8]の第33.5項に定義されている対応するシーケンスタイプに従って符号化されている（同等のABNFについては、[15]参照）。
EmbeddedPDVValue = SequenceValue
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).
外部タイプの値は、X.690の8.18.1で定義されている対応するシーケンスタイプに従ってエンコードされます[12]（同等のABNFについては[15]を参照）。
ExternalValue = SequenceValue
A value of the INSTANCE OF type is encoded according to the corresponding SEQUENCE type defined in Annex C of X.681 [9].
タイプのインスタンスの値は、X.681の附属書Cで定義されている対応するシーケンスタイプに従ってエンコードされています[9]。
InstanceOfValue = SequenceValue
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).
実型の値はゼロの場合は "0"としてエンコードする必要があります。それ以外の場合は、特殊値<plus-infinity>、特殊値<minus-infinity>、オプションで署名された<realNumber>、またはそのまま符号化されています。X.680の実際に定義された実数定義のための対応するシーケンスタイプの値は[8]（同等の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"
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
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型、すなわち識別名の値は、<RDNSequenceValue>ルールに従って、引用符付きのLDAPDN文字列として符号化される。文字列は、最初にRFC 2253 [5]のセクション3の<識別名>規則に従って導出され、次にそれが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値の一部ではないRelativeSistingusedName値は、<relativeSistingSnameValue>ルールに従って、引用符付き文字列としてエンコードされます。文字列は、最初に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
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:
次のオブジェクト識別子は、Adacel TechnologiesがAdacelにAdacelに割り当てられたARCの下で、汎用ストリングエンコーディング規則を識別しています。
{ 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.
このオブジェクト識別子は、例えば、GSER符号化データ値に対する転送構文を埋め込みPDV値で記述するように使用されるであろう。
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.
一般的な文字列のエンコード規則は、正規の符号化を定義しません。すなわち、GSER符号化から他の符号化（例えば、BER）への変換が必ずしも元のGSERオクテット符号化を再現するとは限らない。したがって、標準符号化が必要な場合は、GSERを使用してはいけません。
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は必ずしもテレテックスストリング、VideoTexString、GraphisStringまたはゼネラルストリングタイプの値の正確なオクテットエンコーディングを再構築することを可能にしないので、識別された符号化規則（DER）[12]からGSERへの符号化とDERに戻ることができないオリジナルのDERエンコーディングを再現します。したがって、GSERを使用して、ストレージまたは送信用にかかわらず、元のバイナリエンコーディングが回復可能な場合はASN.1抽象値を再エンコードしてください。このような回復は、デジタル署名の検証に必要です。そのような場合、プロトコルは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.
セキュリティに敏感なフィールドを解釈するとき、およびアクセスを許可または拒否するために使用されるフィールドは、使用される特定のエンコーディングに関係なく、実装が基礎となる抽象値に対していかなる比較が確実に行われている必要があります。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S.、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[2] Kille、S.、 "Mixe Internet X.400 Enhanced Relay）：1998年1月、RFC 2156、RFC 2156の間のマッピング。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D.およびP.のオーバーヘル、「SyntaxのBNFの拡張BNF：ABNF」、RFC 2234、1997年11月。
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[4] Wahl、M.、Coulbeck、A.、HOWES、T.およびS.Kille、「Lightweight Directory Access Protocol（v3）：属性構文定義」、RFC 2252、1997年12月。
[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[5] Wahl、M.、Kille S.およびT.hhowes。「軽量ディレクトリアクセスプロトコル（V3）：識別名の識別名の字句表現」、RFC 2253、1997年12月。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[6] Yelgeau、F。、「ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[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)
[12] ITU-T勧告X.690（07/02）
[13] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[13] Hovey、R.およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。
[14] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[14] HODGES、J.およびR.MORGAN、「Lightweight Directory Access Protocol（V3）：Technical Specification」、RFC 3377、2002年9月。
[15] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003.
[15] S。、「Generic Stringエンコーディングルール（GSER）エンコーディング（GSER）エンコーディングの共通要素」、RFC 3642、2003年10月。
[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
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エグゼクティブディレクターに情報を取り扱ってください。
Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA
Steven Legg Adacel Technologies Ltd. 250ベイストリートブライトン、ビクトリア3186オーストラリア
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット社会（2003）。全著作権所有。
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エディタ機能のための資金は、現在インターネット社会によって提供されています。