1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
|
<pre>Network Working Group S. Legg
Request for Comments: 4792 eB2Bcom
Updates: <a href="./rfc3641">3641</a> January 2007
Category: Standards Track
<span class="h1">Encoding Instructions for the</span>
<span class="h1">Generic String Encoding Rules (GSER)</span>
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Abstract Syntax Notation One (ASN.1) defines a general framework for
annotating types in an ASN.1 specification with encoding instructions
that alter how values of those types are encoded according to ASN.1
encoding rules. This document defines the supporting notation for
encoding instructions that apply to the Generic String Encoding Rules
(GSER) and, in particular, defines an encoding instruction to provide
a machine-processable representation for the declaration of a GSER
ChoiceOfStrings type.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Notation for GSER Encoding Instructions .........................<a href="#page-2">2</a>
<a href="#section-4">4</a>. The CHOICE-OF-STRINGS Encoding Instruction ......................<a href="#page-3">3</a>
<a href="#section-4.1">4.1</a>. Effect on GSER Encodings ...................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Replacement of Existing ChoiceOfStrings Declarations .......<a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Normative References ............................................<a href="#page-7">7</a>
<span class="grey">Legg Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Abstract Syntax Notation One (ASN.1) [<a href="#ref-X.680">X.680</a>] defines a general
framework for annotating types in an ASN.1 specification with
encoding instructions [<a href="#ref-X.680-1">X.680-1</a>] that alter how values of those types
are encoded according to ASN.1 encoding rules. This document defines
the supporting notation for encoding instructions that apply to the
Generic String Encoding Rules (GSER) [<a href="#ref-GSER" title=""Generic String Encoding Rules (GSER) for ASN.1 Types"">GSER</a>], and in particular
defines an encoding instruction, the CHOICE-OF-STRINGS encoding
instruction, to provide a machine-processable representation for the
declaration of a GSER ChoiceOfStrings type.
The CHOICE-OF-STRINGS encoding instruction SHOULD be used instead of
simply declaring a ChoiceOfStrings type.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions</span>
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
[<a href="#ref-BCP14" title=""Key words for use in RFCs to Indicate Requirement Levels"">BCP14</a>].
Throughout this document, "type" shall be taken to mean an ASN.1
type, and "value" shall be taken to mean an ASN.1 abstract value,
unless qualified otherwise.
A reference to an ASN.1 production [<a href="#ref-X.680">X.680</a>] (e.g., Type, NamedType) is
a reference to text in an ASN.1 specification corresponding to that
production.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Notation for GSER Encoding Instructions</span>
The grammar of ASN.1 permits the application of encoding instructions
[<a href="#ref-X.680-1">X.680-1</a>], through type prefixes and encoding control sections, that
modify how abstract values are encoded by nominated encoding rules.
The generic notation for type prefixes and encoding control sections
is defined by the ASN.1 basic notation [<a href="#ref-X.680">X.680</a>] [<a href="#ref-X.680-1">X.680-1</a>], and
includes an encoding reference to identify the specific encoding
rules that are affected by the encoding instruction.
The encoding reference that identifies the Generic String Encoding
Rules is literally GSER.
The specific notation for an encoding instruction for a particular
set of encoding rules is left to the specification of those encoding
rules. Consequently, this companion document to the GSER
specification [<a href="#ref-GSER" title=""Generic String Encoding Rules (GSER) for ASN.1 Types"">GSER</a>] defines the notation for GSER encoding
<span class="grey">Legg Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
instructions. Specifically, it elaborates the EncodingInstruction
and EncodingInstructionAssignmentList placeholder productions of the
ASN.1 basic notation.
In the context of the GSER encoding reference the EncodingInstruction
production is defined as follows, using the conventions of the ASN.1
basic notation:
EncodingInstruction ::=
ChoiceOfStringsInstruction
In the context of the GSER encoding reference the
EncodingInstructionAssignmentList production (which only appears in
an encoding control section) is empty:
EncodingInstructionAssignmentList ::= empty
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The CHOICE-OF-STRINGS Encoding Instruction</span>
The CHOICE-OF-STRINGS encoding instruction allows a GSER encoder to
encode the alternative of a CHOICE (of restricted string types)
without the leading identifier. The optional PrecedenceList also
allows a specification writer to alter the order in which a GSER
decoder will consider the alternatives of the CHOICE as it determines
which alternative has been encoded when the identifier is absent.
The notation for a CHOICE-OF-STRINGS encoding instruction is defined
as follows:
UnionInstruction ::= "CHOICE-OF-STRINGS" AlternativesPrecedence ?
AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList
PrecedenceList ::= identifier PrecedenceList ?
The Type in the EncodingPrefixedType for a CHOICE-OF-STRINGS encoding
instruction SHALL be:
(a) a BuiltinType that is a ChoiceType, or
(b) a ConstrainedType that is not a TypeWithConstraint where the Type
in the ConstrainedType is one of (a) to (d), or
(c) a BuiltinType that is a PrefixedType that is a TaggedType where
the Type in the TaggedType is one of (a) to (d), or
<span class="grey">Legg Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
(d) a BuiltinType that is a PrefixedType that is an
EncodingPrefixedType where the Type in the EncodingPrefixedType
is one of (a) to (d).
The effect of this condition is to force the CHOICE-OF-STRINGS
encoding instruction to be textually co-located with the CHOICE type
definition to which it applies. This makes it clear to a reader that
the encoding instruction applies to every use of the CHOICE type no
matter how it might be referenced.
The ChoiceType in case (a) is said to be "subject to" the CHOICE-OF-
STRINGS encoding instruction.
The Type of each NamedType of the ChoiceType in case (a) MUST be:
(1) the NumericString, PrintableString, TeletexString (T61String),
VideotexString, IA5String, GraphicString, VisibleString
(ISO646String), GeneralString, BMPString, UniversalString, or
UTF8String type, or
(2) a type notation that references a type that is one of (1) to (4),
or
(3) a constrained type where the type that is constrained is one of
(1) to (4), or
(4) a prefixed type where the type that is prefixed is one of (1) to
(4).
ASIDE: A tagged type is a special case of a prefixed type. An
effect of case (4) is that tagging is not significant.
The ASN.1 restricted string type in case (1) MUST be different for
each NamedType in the ChoiceType, i.e., no two alternatives have the
same restricted string type.
If case (3) applies to any NamedType, then the constraint in case (3)
MUST be the same for each NamedType, i.e., either none of the
alternatives has a constraint, or all of the alternatives have
exactly the same constraint.
Each identifier in the PrecedenceList MUST be the identifier of a
NamedType of the ChoiceType.
A particular identifier SHALL NOT appear more than once in the same
PrecedenceList.
<span class="grey">Legg Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Effect on GSER Encodings</span>
A value of a CHOICE type is encoded according to the <ChoiceValue>
[<a href="#ref-GSER" title=""Generic String Encoding Rules (GSER) for ASN.1 Types"">GSER</a>] Augmented Backus-Naur Form [<a href="#ref-ABNF" title=""Augmented BNF for Syntax Specifications: ABNF"">ABNF</a>] rule. The ABNF for
<ChoiceValue> is reproduced here for convenience:
ChoiceValue = IdentifiedChoiceValue /
ChoiceOfStringsValue
IdentifiedChoiceValue = identifier ":" Value
ChoiceOfStringsValue = StringValue
The <IdentifiedChoiceValue> rule MUST be used to encode values of a
CHOICE type where the ChoiceType is not subject to a CHOICE-OF-
STRINGS encoding instruction.
The chosen alternative of a value of a CHOICE type corresponds to
some NamedType in the definition of the type. The <identifier> in
the <IdentifiedChoiceValue> is the identifier of this NamedType.
Either the <IdentifiedChoiceValue> rule or the <ChoiceOfStringsValue>
rule is used to encode values of a CHOICE type where the ChoiceType
is subject to a CHOICE-OF-STRINGS encoding instruction.
If <ChoiceOfStringsValue> has been used, then a GSER decoder MUST
determine the chosen alternative by considering the alternatives of
the CHOICE in the order prescribed below and accepting the first
alternative that allows all of the characters in the <StringValue>.
If the CHOICE-OF-STRINGS encoding instruction has a PrecedenceList,
then the alternatives of the ChoiceType referenced by the
PrecedenceList are considered in the order identified by that
PrecedenceList, and then the remaining alternatives are considered in
the order of their definition in the ChoiceType. If the CHOICE-OF-
STRINGS encoding instruction does not have a PrecedenceList, then all
the alternatives of the ChoiceType are considered in the order of
their definition in the ChoiceType.
A GSER encoder MUST use <IdentifiedChoiceValue> if a GSER decoder
would determine the chosen alternative to be something other than the
chosen alternative of the CHOICE value being encoded; otherwise,
<ChoiceOfStringsValue> MAY be used.
<span class="grey">Legg Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
Example
Consider this type definition:
[GSER:CHOICE-OF-STRINGS PRECEDENCE basicName] CHOICE {
extendedName UTF8String,
basicName PrintableString
}
If a <ChoiceOfStringsValue> has been used, then a GSER decoder
would first consider whether the <StringValue> was a valid
basicName (a PrintableString) before considering whether it was a
valid extendedName (a UTF8String).
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Replacement of Existing ChoiceOfStrings Declarations</span>
In line with the previous declaration [<a href="#ref-GSER" title=""Generic String Encoding Rules (GSER) for ASN.1 Types"">GSER</a>] of the DirectoryString
type as a ChoiceOfStrings type, applications using GSER MUST add this
encoding instruction:
[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]
immediately before the "CHOICE" keyword in the definition of the
DirectoryString type in the third and every subsequent edition of the
SelectedAttributeTypes ASN.1 module of X.520 [<a href="#ref-X.520-3">X.520-3</a>] [<a href="#ref-X.520-4">X.520-4</a>]
[<a href="#ref-X.520-5">X.520-5</a>].
For example, this is how the DirectoryString definition would appear
in the third, fourth and fifth editions:
DirectoryString{INTEGER:maxSize} ::=
[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]
CHOICE {
teletexString TeletexString(SIZE (1..maxSize)),
printableString PrintableString(SIZE (1..maxSize)),
universalString UniversalString(SIZE (1..maxSize)),
bmpString BMPString(SIZE (1..maxSize)),
uTF8String UTF8String(SIZE (1..maxSize))
}
The uTF8String alternative did not appear in the second edition of
the SelectedAttributeTypes ASN.1 module of X.520 [<a href="#ref-X.520-2">X.520-2</a>]. For
compatibility, applications using GSER with the second edition of
X.520 MUST add this encoding instruction:
[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]
<span class="grey">Legg Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
immediately before the "CHOICE" keyword in the definition of the
DirectoryString type.
For example, this is how the DirectoryString definition would appear
in the second edition:
DirectoryString{INTEGER:maxSize} ::=
[GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]
CHOICE {
teletexString TeletexString(SIZE (1..maxSize)),
printableString PrintableString(SIZE (1..maxSize)),
universalString UniversalString(SIZE (1..maxSize))
}
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This specification changes the manner in which ChoiceOfStrings types
are declared but does not alter the existing behaviour of GSER
implementations. The security considerations for GSER are unchanged
(see [<a href="#ref-GSER" title=""Generic String Encoding Rules (GSER) for ASN.1 Types"">GSER</a>]).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Normative References</span>
[<a id="ref-BCP14">BCP14</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-GSER">GSER</a>] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", <a href="./rfc3641">RFC 3641</a>, October 2003.
[<a id="ref-ABNF">ABNF</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", <a href="./rfc4234">RFC 4234</a>, October 2005.
[<a id="ref-X.520-2">X.520-2</a>] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection -
The Directory: Selected attribute types
[<a id="ref-X.520-3">X.520-3</a>] ITU-T Recommendation X.520 (08/97) | ISO/IEC 9594-6:1998,
Information Technology - Open Systems Interconnection -
The Directory: Selected attribute types
[<a id="ref-X.520-4">X.520-4</a>] ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001,
Information technology - Open Systems Interconnection -
The Directory: Selected attribute types
[<a id="ref-X.520-5">X.520-5</a>] ITU-T Recommendation X.520 (08/05) | ISO/IEC 9594-6:2005,
Information technology - Open Systems Interconnection -
The Directory: Selected attribute types
<span class="grey">Legg Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
[<a id="ref-X.680">X.680</a>] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[<a id="ref-X.680-1">X.680-1</a>] ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) |
ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER.
Author's Address
Dr. Steven Legg
eB2Bcom
Suite 3, Woodhouse Corporate Centre
935 Station Street
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
<span class="grey">Legg Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4792">RFC 4792</a> Encoding Instructions for GSER January 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Legg Standards Track [Page 9]
</pre>
|
