xref: /freebsd/crypto/heimdal/doc/layman.asc (revision 5ca8e32633c4ffbbcd6762e5888b6a4ba0708c6c)
1A Layman's Guide to a Subset of ASN.1, BER, and DER
2
3An RSA Laboratories Technical Note
4Burton S. Kaliski Jr.
5Revised November 1, 1993
6
7
8Supersedes June 3, 1991 version, which was also published as
9NIST/OSI Implementors' Workshop document SEC-SIG-91-17.
10PKCS documents are available by electronic mail to
11<pkcs@rsa.com>.
12
13Copyright (C) 1991-1993 RSA Laboratories, a division of RSA
14Data Security, Inc. License to copy this document is granted
15provided that it is identified as "RSA Data Security, Inc.
16Public-Key Cryptography Standards (PKCS)" in all material
17mentioning or referencing this document.
18003-903015-110-000-000
19
20
21Abstract. This note gives a layman's introduction to a
22subset of OSI's Abstract Syntax Notation One (ASN.1), Basic
23Encoding Rules (BER), and Distinguished Encoding Rules
24(DER). The particular purpose of this note is to provide
25background material sufficient for understanding and
26implementing the PKCS family of standards.
27
28
291. Introduction
30
31It is a generally accepted design principle that abstraction
32is a key to managing software development. With abstraction,
33a designer can specify a part of a system without concern
34for how the part is actually implemented or represented.
35Such a practice leaves the implementation open; it
36simplifies the specification; and it makes it possible to
37state "axioms" about the part that can be proved when the
38part is implemented, and assumed when the part is employed
39in another, higher-level part. Abstraction is the hallmark
40of most modern software specifications.
41
42One of the most complex systems today, and one that also
43involves a great deal of abstraction, is Open Systems
44Interconnection (OSI, described in X.200). OSI is an
45internationally standardized architecture that governs the
46interconnection of computers from the physical layer up to
47the user application layer. Objects at higher layers are
48defined abstractly and intended to be implemented with
49objects at lower layers. For instance, a service at one
50layer may require transfer of certain abstract objects
51between computers; a lower layer may provide transfer
52services for strings of ones and zeroes, using encoding
53rules to transform the abstract objects into such strings.
54OSI is called an open system because it supports many
55different implementations of the services at each layer.
56
57OSI's method of specifying abstract objects is called ASN.1
58(Abstract Syntax Notation One, defined in X.208), and one
59set of rules for representing such objects as strings of
60ones and zeros is called the BER (Basic Encoding Rules,
61defined in X.209). ASN.1 is a flexible notation that allows
62one to define a variety data types, from simple types such
63as integers and bit strings to structured types such as sets
64and sequences, as well as complex types defined in terms of
65others. BER describes how to represent or encode values of
66each ASN.1 type as a string of eight-bit octets. There is
67generally more than one way to BER-encode a given value.
68Another set of rules, called the Distinguished Encoding
69Rules (DER), which is a subset of BER, gives a unique
70encoding to each ASN.1 value.
71
72The purpose of this note is to describe a subset of ASN.1,
73BER and DER sufficient to understand and implement one OSI-
74based application, RSA Data Security, Inc.'s Public-Key
75Cryptography Standards. The features described include an
76overview of ASN.1, BER, and DER and an abridged list of
77ASN.1 types and their BER and DER encodings. Sections 2-4
78give an overview of ASN.1, BER, and DER, in that order.
79Section 5 lists some ASN.1 types, giving their notation,
80specific encoding rules, examples, and comments about their
81application to PKCS. Section 6 concludes with an example,
82X.500 distinguished names.
83
84Advanced features of ASN.1, such as macros, are not
85described in this note, as they are not needed to implement
86PKCS. For information on the other features, and for more
87detail generally, the reader is referred to CCITT
88Recommendations X.208 and X.209, which define ASN.1 and BER.
89
90Terminology and notation. In this note, an octet is an eight-
91bit unsigned integer. Bit 8 of the octet is the most
92significant and bit 1 is the least significant.
93
94The following meta-syntax is used for in describing ASN.1
95notation:
96
97     BIT  monospace denotes literal characters in the type
98          and value notation; in examples, it generally
99          denotes an octet value in hexadecimal
100
101     n1   bold italics denotes a variable
102
103     []   bold square brackets indicate that a term is
104          optional
105
106     {}   bold braces group related terms
107
108     |    bold vertical bar delimits alternatives with a
109          group
110
111     ...  bold ellipsis indicates repeated occurrences
112
113     =    bold equals sign expresses terms as subterms
114
115
1162. Abstract Syntax Notation One
117
118Abstract Syntax Notation One, abbreviated ASN.1, is a
119notation for describing abstract types and values.
120
121In ASN.1, a type is a set of values. For some types, there
122are a finite number of values, and for other types there are
123an infinite number. A value of a given ASN.1 type is an
124element of the type's set. ASN.1 has four kinds of type:
125simple types, which are "atomic" and have no components;
126structured types, which have components; tagged types, which
127are derived from other types; and other types, which include
128the CHOICE type and the ANY type. Types and values can be
129given names with the ASN.1 assignment operator (::=) , and
130those names can be used in defining other types and values.
131
132Every ASN.1 type other than CHOICE and ANY has a tag, which
133consists of a class and a nonnegative tag number. ASN.1
134types are abstractly the same if and only if their tag
135numbers are the same. In other words, the name of an ASN.1
136type does not affect its abstract meaning, only the tag
137does. There are four classes of tag:
138
139     Universal, for types whose meaning is the same in all
140          applications; these types are only defined in
141          X.208.
142
143     Application, for types whose meaning is specific to an
144          application, such as X.500 directory services;
145          types in two different applications may have the
146          same application-specific tag and different
147          meanings.
148
149     Private, for types whose meaning is specific to a given
150          enterprise.
151
152     Context-specific, for types whose meaning is specific
153          to a given structured type; context-specific tags
154          are used to distinguish between component types
155          with the same underlying tag within the context of
156          a given structured type, and component types in
157          two different structured types may have the same
158          tag and different meanings.
159
160The types with universal tags are defined in X.208, which
161also gives the types' universal tag numbers. Types with
162other tags are defined in many places, and are always
163obtained by implicit or explicit tagging (see Section 2.3).
164Table 1 lists some ASN.1 types and their universal-class
165tags.
166
167    Type                     Tag number     Tag number
168                             (decimal)      (hexadecimal)
169    INTEGER                  2              02
170    BIT STRING               3              03
171    OCTET STRING             4              04
172    NULL                     5              05
173    OBJECT IDENTIFIER        6              06
174    SEQUENCE and SEQUENCE OF 16             10
175    SET and SET OF           17             11
176    PrintableString          19             13
177    T61String                20             14
178    IA5String                22             16
179    UTCTime                  23             17
180
181     Table 1. Some types and their universal-class tags.
182
183ASN.1 types and values are expressed in a flexible,
184programming-language-like notation, with the following
185special rules:
186
187     o    Layout is not significant; multiple spaces and
188          line breaks can be considered as a single space.
189
190     o    Comments are delimited by pairs of hyphens (--),
191          or a pair of hyphens and a line break.
192
193     o    Identifiers (names of values and fields) and type
194          references (names of types) consist of upper- and
195          lower-case letters, digits, hyphens, and spaces;
196          identifiers begin with lower-case letters; type
197          references begin with upper-case letters.
198
199The following four subsections give an overview of simple
200types, structured types, implicitly and explicitly tagged
201types, and other types. Section 5 describes specific types
202in more detail.
203
204
2052.1 Simple types
206
207Simple types are those not consisting of components; they
208are the "atomic" types. ASN.1 defines several; the types
209that are relevant to the PKCS standards are the following:
210
211     BIT STRING, an arbitrary string of bits (ones and
212          zeroes).
213
214     IA5String, an arbitrary string of IA5 (ASCII)
215          characters.
216
217     INTEGER, an arbitrary integer.
218
219     NULL, a null value.
220
221     OBJECT IDENTIFIER, an object identifier, which is a
222          sequence of integer components that identify an
223          object such as an algorithm or attribute type.
224
225     OCTET STRING, an arbitrary string of octets (eight-bit
226          values).
227
228     PrintableString, an arbitrary string of printable
229          characters.
230
231     T61String, an arbitrary string of T.61 (eight-bit)
232          characters.
233
234     UTCTime, a "coordinated universal time" or Greenwich
235          Mean Time (GMT) value.
236
237Simple types fall into two categories: string types and non-
238string types. BIT STRING, IA5String, OCTET STRING,
239PrintableString, T61String, and UTCTime are string types.
240
241String types can be viewed, for the purposes of encoding, as
242consisting of components, where the components are
243substrings. This view allows one to encode a value whose
244length is not known in advance (e.g., an octet string value
245input from a file stream) with a constructed, indefinite-
246length encoding (see Section 3).
247
248The string types can be given size constraints limiting the
249length of values.
250
251
2522.2 Structured types
253
254Structured types are those consisting of components. ASN.1
255defines four, all of which are relevant to the PKCS
256standards:
257
258     SEQUENCE, an ordered collection of one or more types.
259
260     SEQUENCE OF, an ordered collection of zero or more
261          occurrences of a given type.
262
263     SET, an unordered collection of one or more types.
264
265     SET OF, an unordered collection of zero or more
266          occurrences of a given type.
267
268The structured types can have optional components, possibly
269with default values.
270
271
2722.3 Implicitly and explicitly tagged types
273
274Tagging is useful to distinguish types within an
275application; it is also commonly used to distinguish
276component types within a structured type. For instance,
277optional components of a SET or SEQUENCE type are typically
278given distinct context-specific tags to avoid ambiguity.
279
280There are two ways to tag a type: implicitly and explicitly.
281
282Implicitly tagged types are derived from other types by
283changing the tag of the underlying type. Implicit tagging is
284denoted by the ASN.1 keywords [class number] IMPLICIT (see
285Section 5.1).
286
287Explicitly tagged types are derived from other types by
288adding an outer tag to the underlying type. In effect,
289explicitly tagged types are structured types consisting of
290one component, the underlying type. Explicit tagging is
291denoted by the ASN.1 keywords [class number] EXPLICIT (see
292Section 5.2).
293
294The keyword [class number] alone is the same as explicit
295tagging, except when the "module" in which the ASN.1 type is
296defined has implicit tagging by default. ("Modules" are
297among the advanced features not described in this note.)
298
299For purposes of encoding, an implicitly tagged type is
300considered the same as the underlying type, except that the
301tag is different. An explicitly tagged type is considered
302like a structured type with one component, the underlying
303type. Implicit tags result in shorter encodings, but
304explicit tags may be necessary to avoid ambiguity if the tag
305of the underlying type is indeterminate (e.g., the
306underlying type is CHOICE or ANY).
307
308
3092.4 Other types
310
311Other types in ASN.1 include the CHOICE and ANY types. The
312CHOICE type denotes a union of one or more alternatives; the
313ANY type denotes an arbitrary value of an arbitrary type,
314where the arbitrary type is possibly defined in the
315registration of an object identifier or integer value.
316
317
3183. Basic Encoding Rules
319
320The Basic Encoding Rules for ASN.1, abbreviated BER, give
321one or more ways to represent any ASN.1 value as an octet
322string. (There are certainly other ways to represent ASN.1
323values, but BER is the standard for interchanging such
324values in OSI.)
325
326There are three methods to encode an ASN.1 value under BER,
327the choice of which depends on the type of value and whether
328the length of the value is known. The three methods are
329primitive, definite-length encoding; constructed, definite-
330length encoding; and constructed, indefinite-length
331encoding. Simple non-string types employ the primitive,
332definite-length method; structured types employ either of
333the constructed methods; and simple string types employ any
334of the methods, depending on whether the length of the value
335is known. Types derived by implicit tagging employ the
336method of the underlying type and types derived by explicit
337tagging employ the constructed methods.
338
339In each method, the BER encoding has three or four parts:
340
341     Identifier octets. These identify the class and tag
342          number of the ASN.1 value, and indicate whether
343          the method is primitive or constructed.
344
345     Length octets. For the definite-length methods, these
346          give the number of contents octets. For the
347          constructed, indefinite-length method, these
348          indicate that the length is indefinite.
349
350     Contents octets. For the primitive, definite-length
351          method, these give a concrete representation of
352          the  value. For the constructed methods, these
353          give the concatenation of the BER encodings of the
354          components of the value.
355
356     End-of-contents octets. For the constructed, indefinite-
357          length method, these denote the end of the
358          contents. For the other methods, these are absent.
359
360The three methods of encoding are described in the following
361sections.
362
363
3643.1 Primitive, definite-length method
365
366This method applies to simple types and types derived from
367simple types by implicit tagging. It requires that the
368length of the value be known in advance. The parts of the
369BER encoding are as follows:
370
371Identifier octets. There are two forms: low tag number (for
372tag numbers between 0 and 30) and high tag number (for tag
373numbers 31 and greater).
374
375     Low-tag-number form. One octet. Bits 8 and 7 specify
376          the class (see Table 2), bit 6 has value "0,"
377          indicating that the encoding is primitive, and
378          bits 5-1 give the tag number.
379
380                  Class            Bit  Bit
381                                   8    7
382                  universal        0    0
383                  application      0    1
384                  context-specific 1    0
385                  private          1    1
386
387        Table 2. Class encoding in identifier octets.
388
389     High-tag-number form. Two or more octets. First octet
390          is as in low-tag-number form, except that bits 5-1
391          all have value "1." Second and following octets
392          give the tag number, base 128, most significant
393          digit first, with as few digits as possible, and
394          with the bit 8 of each octet except the last set
395          to "1."
396
397Length octets. There are two forms: short (for lengths
398between 0 and 127), and long definite (for lengths between 0
399and 21008-1).
400
401     Short form. One octet. Bit 8 has value "0" and bits 7-1
402          give the length.
403
404     Long form. Two to 127 octets. Bit 8 of first octet has
405          value "1" and bits 7-1 give the number of
406          additional length octets. Second and following
407          octets give the length, base 256, most significant
408          digit first.
409
410Contents octets. These give a concrete representation of the
411value (or the value of the underlying type, if the type is
412derived by implicit tagging). Details for particular types
413are given in Section 5.
414
415
4163.2 Constructed, definite-length method
417
418This method applies to simple string types, structured
419types, types derived simple string types and structured
420types by implicit tagging, and types derived from anything
421by explicit tagging. It requires that the length of the
422value be known in advance. The parts of the BER encoding are
423as follows:
424
425Identifier octets. As described in Section 3.1, except that
426bit 6 has value "1," indicating that the encoding is
427constructed.
428
429Length octets. As described in Section 3.1.
430
431Contents octets. The concatenation of the BER encodings of
432the components of the value:
433
434     o    For simple string types and types derived from
435          them by implicit tagging, the concatenation of the
436          BER encodings of consecutive substrings of the
437          value (underlying value for implicit tagging).
438
439     o    For structured types and types derived from them
440          by implicit tagging, the concatenation of the BER
441          encodings of components of the value (underlying
442          value for implicit tagging).
443
444     o    For types derived from anything by explicit
445          tagging, the BER encoding of the underlying value.
446
447Details for particular types are given in Section 5.
448
449
4503.3 Constructed, indefinite-length method
451
452This method applies to simple string types, structured
453types, types derived simple string types and structured
454types by implicit tagging, and types derived from anything
455by explicit tagging. It does not require that the length of
456the value be known in advance. The parts of the BER encoding
457are as follows:
458
459Identifier octets. As described in Section 3.2.
460
461Length octets. One octet, 80.
462
463Contents octets. As described in Section 3.2.
464
465End-of-contents octets. Two octets, 00 00.
466
467Since the end-of-contents octets appear where an ordinary
468BER encoding might be expected (e.g., in the contents octets
469of a sequence value), the 00 and 00 appear as identifier and
470length octets, respectively. Thus the end-of-contents octets
471is really the primitive, definite-length encoding of a value
472with universal class, tag number 0, and length 0.
473
474
4754. Distinguished Encoding Rules
476
477The Distinguished Encoding Rules for ASN.1, abbreviated DER,
478are a subset of BER, and give exactly one way to represent
479any ASN.1 value as an octet string. DER is intended for
480applications in which a unique octet string encoding is
481needed, as is the case when a digital signature is computed
482on an ASN.1 value. DER is defined in Section 8.7 of X.509.
483
484DER adds the following restrictions to the rules given in
485Section 3:
486
487     1.   When the length is between 0 and 127, the short
488          form of length must be used
489
490     2.   When the length is 128 or greater, the long form
491          of length must be used, and the length must be
492          encoded in the minimum number of octets.
493
494     3.   For simple string types and implicitly tagged
495          types derived from simple string types, the
496          primitive, definite-length method must be
497          employed.
498
499     4.   For structured types, implicitly tagged types
500          derived from structured types, and explicitly
501          tagged types derived from anything, the
502          constructed, definite-length method must be
503          employed.
504
505Other restrictions are defined for particular types (such as
506BIT STRING, SEQUENCE, SET, and SET OF), and can be found in
507Section 5.
508
509
5105. Notation and encodings for some types
511
512This section gives the notation for some ASN.1 types and
513describes how to encode values of those types under both BER
514and DER.
515
516The types described are those presented in Section 2. They
517are listed alphabetically here.
518
519Each description includes ASN.1 notation, BER encoding, and
520DER encoding. The focus of the encodings is primarily on the
521contents octets; the tag and length octets follow Sections 3
522and 4. The descriptions also explain where each type is used
523in PKCS and related standards. ASN.1 notation is generally
524only for types, although for the type OBJECT IDENTIFIER,
525value notation is given as well.
526
527
5285.1 Implicitly tagged types
529
530An implicitly tagged type is a type derived from another
531type by changing the tag of the underlying type.
532
533Implicit tagging is used for optional SEQUENCE components
534with underlying type other than ANY throughout PKCS, and for
535the extendedCertificate alternative of PKCS #7's
536ExtendedCertificateOrCertificate type.
537
538ASN.1 notation:
539
540[[class] number] IMPLICIT Type
541
542class = UNIVERSAL  |  APPLICATION  |  PRIVATE
543
544where Type is a type, class is an optional class name, and
545number is the tag number within the class, a nonnegative
546integer.
547
548In ASN.1 "modules" whose default tagging method is implicit
549tagging, the notation [[class] number] Type is also
550acceptable, and the keyword IMPLICIT is implied. (See
551Section 2.3.) For definitions stated outside a module, the
552explicit inclusion of the keyword IMPLICIT is preferable to
553prevent ambiguity.
554
555If the class name is absent, then the tag is context-
556specific. Context-specific tags can only appear in a
557component of a structured or CHOICE type.
558
559Example: PKCS #8's PrivateKeyInfo type has an optional
560attributes component with an implicit, context-specific tag:
561
562PrivateKeyInfo ::= SEQUENCE {
563  version Version,
564  privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
565  privateKey PrivateKey,
566  attributes [0] IMPLICIT Attributes OPTIONAL }
567
568Here the underlying type is Attributes, the class is absent
569(i.e., context-specific), and the tag number within the
570class is 0.
571
572BER encoding. Primitive or constructed, depending on the
573underlying type. Contents octets are as for the BER encoding
574of the underlying value.
575
576Example: The BER encoding of the attributes component of a
577PrivateKeyInfo value is as follows:
578
579     o    the identifier octets are 80 if the underlying
580          Attributes value has a primitive BER encoding and
581          a0 if the underlying Attributes value has a
582          constructed BER encoding
583
584     o    the length and contents octets are the same as the
585          length and contents octets of the BER encoding of
586          the underlying Attributes value
587
588DER encoding. Primitive or constructed, depending on the
589underlying type. Contents octets are as for the DER encoding
590of the underlying value.
591
592
5935.2 Explicitly tagged types
594
595Explicit tagging denotes a type derived from another type by
596adding an outer tag to the underlying type.
597
598Explicit tagging is used for optional SEQUENCE components
599with underlying type ANY throughout PKCS, and for the
600version component of X.509's Certificate type.
601
602ASN.1 notation:
603
604[[class] number] EXPLICIT Type
605
606class = UNIVERSAL  |  APPLICATION  |  PRIVATE
607
608where Type is a type, class is an optional class name, and
609number is the tag number within the class, a nonnegative
610integer.
611
612If the class name is absent, then the tag is context-
613specific. Context-specific tags can only appear in a
614component of a SEQUENCE, SET or CHOICE type.
615
616In ASN.1 "modules" whose default tagging method is explicit
617tagging, the notation [[class] number] Type is also
618acceptable, and the keyword EXPLICIT is implied. (See
619Section 2.3.) For definitions stated outside a module, the
620explicit inclusion of the keyword EXPLICIT is preferable to
621prevent ambiguity.
622
623Example 1: PKCS #7's ContentInfo type has an optional
624content component with an explicit, context-specific tag:
625
626ContentInfo ::= SEQUENCE {
627  contentType ContentType,
628  content
629    [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
630
631Here the underlying type is ANY DEFINED BY contentType, the
632class is absent (i.e., context-specific), and the tag number
633within the class is 0.
634
635Example 2: X.509's Certificate type has a version component
636with an explicit, context-specific tag, where the EXPLICIT
637keyword is omitted:
638
639Certificate ::= ...
640  version [0] Version DEFAULT v1988,
641...
642
643The tag is explicit because the default tagging method for
644the ASN.1 "module" in X.509 that defines the Certificate
645type is explicit tagging.
646
647BER encoding. Constructed. Contents octets are the BER
648encoding of the underlying value.
649
650Example: the BER encoding of the content component of a
651ContentInfo value is as follows:
652
653     o    identifier octets are a0
654
655     o    length octets represent the length of the BER
656          encoding of the underlying ANY DEFINED BY
657          contentType value
658
659     o    contents octets are the BER encoding of the
660          underlying ANY DEFINED BY contentType value
661
662DER encoding. Constructed. Contents octets are the DER
663encoding of the underlying value.
664
665
6665.3 ANY
667
668The ANY type denotes an arbitrary value of an arbitrary
669type, where the arbitrary type is possibly defined in the
670registration of an object identifier or associated with an
671integer index.
672
673The ANY type is used for content of a particular content
674type in PKCS #7's ContentInfo type, for parameters of a
675particular algorithm in X.509's AlgorithmIdentifier type,
676and for attribute values in X.501's Attribute and
677AttributeValueAssertion types. The Attribute type is used by
678PKCS #6, #7, #8, #9 and #10, and the AttributeValueAssertion
679type is used in X.501 distinguished names.
680
681ASN.1 notation:
682
683ANY [DEFINED BY identifier]
684
685where identifier is an optional identifier.
686
687In the ANY form, the actual type is indeterminate.
688
689The ANY DEFINED BY identifier form can only appear in a
690component of a SEQUENCE or SET type for which identifier
691identifies some other component, and that other component
692has type INTEGER or OBJECT IDENTIFIER (or a type derived
693from either of those by tagging). In that form, the actual
694type is determined by the value of the other component,
695either in the registration of the object identifier value,
696or in a table of integer values.
697
698Example: X.509's AlgorithmIdentifier type has a component of
699type ANY:
700
701AlgorithmIdentifier ::= SEQUENCE {
702  algorithm OBJECT IDENTIFIER,
703  parameters ANY DEFINED BY algorithm OPTIONAL }
704
705Here the actual type of the parameter component depends on
706the value of the algorithm component. The actual type would
707be defined in the registration of object identifier values
708for the algorithm component.
709
710BER encoding. Same as the BER encoding of the actual value.
711
712Example: The BER encoding of the value of the parameter
713component is the BER encoding of the value of the actual
714type as defined in the registration of object identifier
715values for the algorithm component.
716
717DER encoding. Same as the DER encoding of the actual value.
718
719
7205.4 BIT STRING
721
722The BIT STRING type denotes an arbitrary string of bits
723(ones and zeroes). A BIT STRING value can have any length,
724including zero. This type is a string type.
725
726The BIT STRING type is used for digital signatures on
727extended certificates in PKCS #6's ExtendedCertificate type,
728for digital signatures on certificates in X.509's
729Certificate type, and for public keys in certificates in
730X.509's SubjectPublicKeyInfo type.
731
732ASN.1 notation:
733
734BIT STRING
735
736Example: X.509's SubjectPublicKeyInfo type has a component
737of type BIT STRING:
738
739SubjectPublicKeyInfo ::= SEQUENCE {
740  algorithm AlgorithmIdentifier,
741  publicKey BIT STRING }
742
743BER encoding. Primitive or constructed. In a primitive
744encoding, the first contents octet gives the number of bits
745by which the length of the bit string is less than the next
746multiple of eight (this is called the "number of unused
747bits"). The second and following contents octets give the
748value of the bit string, converted to an octet string. The
749conversion process is as follows:
750
751     1.   The bit string is padded after the last bit with
752          zero to seven bits of any value to make the length
753          of the bit string a multiple of eight. If the
754          length of the bit string is a multiple of eight
755          already, no padding is done.
756
757     2.   The padded bit string is divided into octets. The
758          first eight bits of the padded bit string become
759          the first octet, bit 8 to bit 1, and so on through
760          the last eight bits of the padded bit string.
761
762In a constructed encoding, the contents octets give the
763concatenation of the BER encodings of consecutive substrings
764of the bit string, where each substring except the last has
765a length that is a multiple of eight bits.
766
767Example: The BER encoding of the BIT STRING value
768"011011100101110111" can be any of the following, among
769others, depending on the choice of padding bits, the form of
770length octets, and whether the encoding is primitive or
771constructed:
772
77303 04 06 6e 5d c0                               DER encoding
774
77503 04 06 6e 5d e0                       padded with "100000"
776
77703 81 04 06 6e 5d c0              long form of length octets
778
77923 09        constructed encoding: "0110111001011101" + "11"
780   03 03 00 6e 5d
781   03 02 06 c0
782
783DER encoding. Primitive. The contents octects are as for a
784primitive BER encoding, except that the bit string is padded
785with zero-valued bits.
786
787Example: The DER encoding of the BIT STRING value
788"011011100101110111" is
789
79003 04 06 6e 5d c0
791
792
7935.5 CHOICE
794
795The CHOICE type denotes a union of one or more alternatives.
796
797The CHOICE type is used to represent the union of an
798extended certificate and an X.509 certificate in PKCS #7's
799ExtendedCertificateOrCertificate type.
800
801ASN.1 notation:
802
803CHOICE {
804  [identifier1] Type1,
805  ...,
806  [identifiern] Typen }
807
808where identifier1 , ..., identifiern are optional, distinct
809identifiers for the alternatives, and Type1, ..., Typen are
810the types of the alternatives. The identifiers are primarily
811for documentation; they do not affect values of the type or
812their encodings in any way.
813
814The types must have distinct tags. This requirement is
815typically satisfied with explicit or implicit tagging on
816some of the alternatives.
817
818Example: PKCS #7's ExtendedCertificateOrCertificate type is
819a CHOICE type:
820
821ExtendedCertificateOrCertificate ::= CHOICE {
822  certificate Certificate, -- X.509
823  extendedCertificate [0] IMPLICIT ExtendedCertificate
824}
825
826Here the identifiers for the alternatives are certificate
827and extendedCertificate, and the types of the alternatives
828are Certificate and [0] IMPLICIT ExtendedCertificate.
829
830BER encoding. Same as the BER encoding of the chosen
831alternative. The fact that the alternatives have distinct
832tags makes it possible to distinguish between their BER
833encodings.
834
835Example: The identifier octets for the BER encoding are 30
836if the chosen alternative is certificate, and a0 if the
837chosen alternative is extendedCertificate.
838
839DER encoding. Same as the DER encoding of the chosen
840alternative.
841
842
8435.6 IA5String
844
845The IA5String type denotes an arbtrary string of IA5
846characters. IA5 stands for International Alphabet 5, which
847is the same as ASCII. The character set includes non-
848printing control characters. An IA5String value can have any
849length, including zero. This type is a string type.
850
851The IA5String type is used in PKCS #9's electronic-mail
852address, unstructured-name, and unstructured-address
853attributes.
854
855ASN.1 notation:
856
857IA5String
858
859BER encoding. Primitive or constructed. In a primitive
860encoding, the contents octets give the characters in the IA5
861string, encoded in ASCII. In a constructed encoding, the
862contents octets give the concatenation of the BER encodings
863of consecutive substrings of the IA5 string.
864
865Example: The BER encoding of the IA5String value
866"test1@rsa.com" can be any of the following, among others,
867depending on the form of length octets and whether the
868encoding is primitive or constructed:
869
87016 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d DER encoding
871
87216 81 0d                       long form of length octets
873   74 65 73 74 31 40 72 73 61 2e 63 6f 6d
874
87536 13     constructed encoding: "test1" + "@" + "rsa.com"
876   16 05 74 65 73 74 31
877   16 01 40
878   16 07 72 73 61 2e 63 6f 6d
879
880DER encoding. Primitive. Contents octets are as for a
881primitive BER encoding.
882
883Example: The DER encoding of the IA5String value
884"test1@rsa.com" is
885
88616 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
887
888
8895.7 INTEGER
890
891The INTEGER type denotes an arbitrary integer. INTEGER
892values can be positive, negative, or zero, and can have any
893magnitude.
894
895The INTEGER type is used for version numbers throughout
896PKCS, cryptographic values such as modulus, exponent, and
897primes in PKCS #1's RSAPublicKey and RSAPrivateKey types and
898PKCS #3's DHParameter type, a message-digest iteration count
899in PKCS #5's PBEParameter type, and version numbers and
900serial numbers in X.509's Certificate type.
901
902ASN.1 notation:
903
904INTEGER [{ identifier1(value1) ... identifiern(valuen) }]
905
906where identifier1, ..., identifiern are optional distinct
907identifiers and value1, ..., valuen are optional integer
908values. The identifiers, when present, are associated with
909values of the type.
910
911Example: X.509's Version type is an INTEGER type with
912identified values:
913
914Version ::= INTEGER { v1988(0) }
915
916The identifier v1988 is associated with the value 0. X.509's
917Certificate type uses the identifier v1988 to give a default
918value of 0 for the version component:
919
920Certificate ::= ...
921  version Version DEFAULT v1988,
922...
923
924BER encoding. Primitive. Contents octets give the value of
925the integer, base 256, in two's complement form, most
926significant digit first, with the minimum number of octets.
927The value 0 is encoded as a single 00 octet.
928
929Some example BER encodings (which also happen to be DER
930encodings) are given in Table 3.
931
932                    Integer   BER encoding
933                    value
934                    0         02 01 00
935                    127       02 01 7F
936                    128       02 02 00 80
937                    256       02 02 01 00
938                    -128      02 01 80
939                    -129      02 02 FF 7F
940
941      Table 3. Example BER encodings of INTEGER values.
942
943DER encoding. Primitive. Contents octets are as for a
944primitive BER encoding.
945
946
9475.8 NULL
948
949The NULL type denotes a null value.
950
951The NULL type is used for algorithm parameters in several
952places in PKCS.
953
954ASN.1 notation:
955
956NULL
957
958BER encoding. Primitive. Contents octets are empty.
959
960Example: The BER encoding of a NULL value can be either of
961the following, as well as others, depending on the form of
962the length octets:
963
96405 00
965
96605 81 00
967
968DER encoding. Primitive. Contents octets are empty; the DER
969encoding of a NULL value is always 05 00.
970
971
9725.9 OBJECT IDENTIFIER
973
974The OBJECT IDENTIFIER type denotes an object identifier, a
975sequence of integer components that identifies an object
976such as an algorithm, an attribute type, or perhaps a
977registration authority that defines other object
978identifiers. An OBJECT IDENTIFIER value can have any number
979of components, and components can generally have any
980nonnegative value. This type is a non-string type.
981
982OBJECT IDENTIFIER values are given meanings by registration
983authorities. Each registration authority is responsible for
984all sequences of components beginning with a given sequence.
985A registration authority typically delegates responsibility
986for subsets of the sequences in its domain to other
987registration authorities, or for particular types of object.
988There are always at least two components.
989
990The OBJECT IDENTIFIER type is used to identify content in
991PKCS #7's ContentInfo type, to identify algorithms in
992X.509's AlgorithmIdentifier type, and to identify attributes
993in X.501's Attribute and AttributeValueAssertion types. The
994Attribute type is used by PKCS #6, #7, #8, #9, and #10, and
995the AttributeValueAssertion type is used in X.501
996distinguished names. OBJECT IDENTIFIER values are defined
997throughout PKCS.
998
999ASN.1 notation:
1000
1001OBJECT IDENTIFIER
1002
1003The ASN.1 notation for values of the OBJECT IDENTIFIER type
1004is
1005
1006{ [identifier] component1 ... componentn }
1007
1008componenti = identifieri | identifieri (valuei) | valuei
1009
1010where identifier, identifier1, ..., identifiern are
1011identifiers, and value1, ..., valuen are optional integer
1012values.
1013
1014The form without identifier is the "complete" value with all
1015its components; the form with identifier abbreviates the
1016beginning components with another object identifier value.
1017The identifiers identifier1, ..., identifiern are intended
1018primarily for documentation, but they must correspond to the
1019integer value when both are present. These identifiers can
1020appear without integer values only if they are among a small
1021set of identifiers defined in X.208.
1022
1023Example: The following values both refer to the object
1024identifier assigned to RSA Data Security, Inc.:
1025
1026{ iso(1) member-body(2) 840 113549 }
1027{ 1 2 840 113549 }
1028
1029(In this example, which gives ASN.1 value notation, the
1030object identifier values are decimal, not hexadecimal.)
1031Table 4 gives some other object identifier values and their
1032meanings.
1033
1034 Object identifier value       Meaning
1035 { 1 2 }                       ISO member bodies
1036 { 1 2 840 }                   US (ANSI)
1037 { 1 2 840 113549 }            RSA Data Security, Inc.
1038 { 1 2 840 113549 1 }          RSA Data Security, Inc. PKCS
1039 { 2 5 }                       directory services (X.500)
1040 { 2 5 8 }                     directory services-algorithms
1041
1042 Table 4. Some object identifier values and their meanings.
1043
1044BER encoding. Primitive. Contents octets are as follows,
1045where value1, ..., valuen denote the integer values of the
1046components in the complete object identifier:
1047
1048     1.   The first octet has value 40 * value1 + value2.
1049          (This is unambiguous, since value1 is limited to
1050          values 0, 1, and 2; value2 is limited to the range
1051          0 to 39 when value1 is 0 or 1; and, according to
1052          X.208, n is always at least 2.)
1053
1054     2.   The following octets, if any, encode value3, ...,
1055          valuen. Each value is encoded base 128, most
1056          significant digit first, with as few digits as
1057          possible, and the most significant bit of each
1058          octet except the last in the value's encoding set
1059          to "1."
1060
1061Example: The first octet of the BER encoding of RSA Data
1062Security, Inc.'s object identifier is 40 * 1 + 2 = 42 =
10632a16. The encoding of 840 = 6 * 128 + 4816 is 86 48 and the
1064encoding of 113549 = 6 * 1282 + 7716 * 128 + d16 is 86 f7
10650d. This leads to the following BER encoding:
1066
106706 06 2a 86 48 86 f7 0d
1068
1069DER encoding. Primitive. Contents octets are as for a
1070primitive BER encoding.
1071
1072
10735.10 OCTET STRING
1074
1075The OCTET STRING type denotes an arbitrary string of octets
1076(eight-bit values). An OCTET STRING value can have any
1077length, including zero. This type is a string type.
1078
1079The OCTET STRING type is used for salt values in PKCS #5's
1080PBEParameter type, for message digests, encrypted message
1081digests, and encrypted content in PKCS #7, and for private
1082keys and encrypted private keys in PKCS #8.
1083
1084ASN.1 notation:
1085
1086OCTET STRING [SIZE ({size | size1..size2})]
1087
1088where size, size1, and size2 are optional size constraints.
1089In the OCTET STRING SIZE (size) form, the octet string must
1090have size octets. In the OCTET STRING SIZE (size1..size2)
1091form, the octet string must have between size1 and size2
1092octets. In the OCTET STRING form, the octet string can have
1093any size.
1094
1095Example: PKCS #5's PBEParameter type has a component of type
1096OCTET STRING:
1097
1098PBEParameter ::= SEQUENCE {
1099  salt OCTET STRING SIZE(8),
1100  iterationCount INTEGER }
1101
1102Here the size of the salt component is always eight octets.
1103
1104BER encoding. Primitive or constructed. In a primitive
1105encoding, the contents octets give the value of the octet
1106string, first octet to last octet. In a constructed
1107encoding, the contents octets give the concatenation of the
1108BER encodings of substrings of the OCTET STRING value.
1109
1110Example: The BER encoding of the OCTET STRING value 01 23 45
111167 89 ab cd ef can be any of the following, among others,
1112depending on the form of length octets and whether the
1113encoding is primitive or constructed:
1114
111504 08 01 23 45 67 89 ab cd ef                   DER encoding
1116
111704 81 08 01 23 45 67 89 ab cd ef  long form of length octets
1118
111924 0c            constructed encoding: 01 ... 67 + 89 ... ef
1120   04 04 01 23 45 67
1121   04 04 89 ab cd ef
1122
1123DER encoding. Primitive. Contents octets are as for a
1124primitive BER encoding.
1125
1126Example: The BER encoding of the OCTET STRING value 01 23 45
112767 89 ab cd ef is
1128
112904 08 01 23 45 67 89 ab cd ef
1130
1131
11325.11 PrintableString
1133
1134The PrintableString type denotes an arbitrary string of
1135printable characters from the following character set:
1136
1137                         A, B, ..., Z
1138                         a, b, ..., z
1139                         0, 1, ..., 9
1140               (space) ' ( ) + , - . / : = ?
1141
1142This type is a string type.
1143
1144The PrintableString type is used in PKCS #9's challenge-
1145password and unstructuerd-address attributes, and in several
1146X.521 distinguished names attributes.
1147
1148ASN.1 notation:
1149
1150PrintableString
1151
1152BER encoding. Primitive or constructed. In a primitive
1153encoding, the contents octets give the characters in the
1154printable string, encoded in ASCII. In a constructed
1155encoding, the contents octets give the concatenation of the
1156BER encodings of consecutive substrings of the string.
1157
1158Example: The BER encoding of the PrintableString value "Test
1159User 1" can be any of the following, among others, depending
1160on the form of length octets and whether the encoding is
1161primitive or constructed:
1162
116313 0b 54 65 73 74 20 55 73 65 72 20 31          DER encoding
1164
116513 81 0b                          long form of length octets
1166   54 65 73 74 20 55 73 65 72 20 31
1167
116833 0f               constructed encoding: "Test " + "User 1"
1169   13 05 54 65 73 74 20
1170   13 06 55 73 65 72 20 31
1171
1172DER encoding. Primitive. Contents octets are as for a
1173primitive BER encoding.
1174
1175Example: The DER encoding of the PrintableString value "Test
1176User 1" is
1177
117813 0b 54 65 73 74 20 55 73 65 72 20 31
1179
1180
11815.12 SEQUENCE
1182
1183The SEQUENCE type denotes an ordered collection of one or
1184more types.
1185
1186The SEQUENCE type is used throughout PKCS and related
1187standards.
1188
1189ASN.1 notation:
1190
1191SEQUENCE {
1192  [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
1193  ...,
1194  [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
1195
1196where identifier1 , ..., identifiern are optional, distinct
1197identifiers for the components, Type1, ..., Typen are the
1198types of the components, and value1, ..., valuen are optional
1199default values for the components. The identifiers are
1200primarily for documentation; they do not affect values of
1201the type or their encodings in any way.
1202
1203The OPTIONAL qualifier indicates that the value of a
1204component is optional and need not be present in the
1205sequence. The DEFAULT qualifier also indicates that the
1206value of a component is optional, and assigns a default
1207value to the component when the component is absent.
1208
1209The types of any consecutive series of components with the
1210OPTIONAL or DEFAULT qualifier, as well as of any component
1211immediately following that series, must have distinct tags.
1212This requirement is typically satisfied with explicit or
1213implicit tagging on some of the components.
1214
1215Example: X.509's Validity type is a SEQUENCE type with two
1216components:
1217
1218Validity ::= SEQUENCE {
1219  start UTCTime,
1220  end UTCTime }
1221
1222Here the identifiers for the components are start and end,
1223and the types of the components are both UTCTime.
1224
1225BER encoding. Constructed. Contents octets are the
1226concatenation of the BER encodings of the values of the
1227components of the sequence, in order of definition, with the
1228following rules for components with the OPTIONAL and DEFAULT
1229qualifiers:
1230
1231     o    if the value of a component with the OPTIONAL or
1232          DEFAULT qualifier is absent from the sequence,
1233          then the encoding of that component is not
1234          included in the contents octets
1235
1236     o    if the value of a component with the DEFAULT
1237          qualifier is the default value, then the encoding
1238          of that component may or may not be included in
1239          the contents octets
1240
1241DER encoding. Constructed. Contents octets are the same as
1242the BER encoding, except that if the value of a component
1243with the DEFAULT qualifier is the default value, the
1244encoding of that component is not included in the contents
1245octets.
1246
1247
12485.13 SEQUENCE OF
1249
1250The SEQUENCE OF type denotes an ordered collection of zero
1251or more occurrences of a given type.
1252
1253The SEQUENCE OF type is used in X.501 distinguished names.
1254
1255ASN.1 notation:
1256
1257SEQUENCE OF Type
1258
1259where Type is a type.
1260
1261Example: X.501's RDNSequence type consists of zero or more
1262occurences of the RelativeDistinguishedName type, most
1263significant occurrence first:
1264
1265RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1266
1267BER encoding. Constructed. Contents octets are the
1268concatenation of the BER encodings of the values of the
1269occurrences in the collection, in order of occurence.
1270
1271DER encoding. Constructed. Contents octets are the
1272concatenation of the DER encodings of the values of the
1273occurrences in the collection, in order of occurence.
1274
1275
12765.14 SET
1277
1278The SET type denotes an unordered collection of one or more
1279types.
1280
1281The SET type is not used in PKCS.
1282
1283ASN.1 notation:
1284
1285SET {
1286  [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
1287  ...,
1288  [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
1289
1290where identifier1, ..., identifiern are optional, distinct
1291identifiers for the components, Type1, ..., Typen are the
1292types of the components, and value1, ..., valuen are
1293optional default values for the components. The identifiers
1294are primarily for documentation; they do not affect values
1295of the type or their encodings in any way.
1296
1297The OPTIONAL qualifier indicates that the value of a
1298component is optional and need not be present in the set.
1299The DEFAULT qualifier also indicates that the value of a
1300component is optional, and assigns a default value to the
1301component when the component is absent.
1302
1303The types must have distinct tags. This requirement is
1304typically satisfied with explicit or implicit tagging on
1305some of the components.
1306
1307BER encoding. Constructed. Contents octets are the
1308concatenation of the BER encodings of the values of the
1309components of the set, in any order, with the following
1310rules for components with the OPTIONAL and DEFAULT
1311qualifiers:
1312
1313     o    if the value of a component with the OPTIONAL or
1314          DEFAULT qualifier is absent from the set, then the
1315          encoding of that component is not included in the
1316          contents octets
1317
1318     o    if the value of a component with the DEFAULT
1319          qualifier is the default value, then the encoding
1320          of that component may or may not be included in
1321          the contents octets
1322
1323DER encoding. Constructed. Contents octets are the same as
1324for the BER encoding, except that:
1325
1326     1.   If the value of a component with the DEFAULT
1327          qualifier is the default value, the encoding of
1328          that component is not included.
1329
1330     2.   There is an order to the components, namely
1331          ascending order by tag.
1332
1333
13345.15 SET OF
1335
1336The SET OF type denotes an unordered collection of zero or
1337more occurrences of a given type.
1338
1339The SET OF type is used for sets of attributes in PKCS #6,
1340#7, #8, #9 and #10, for sets of message-digest algorithm
1341identifiers, signer information, and recipient information
1342in PKCS #7, and in X.501 distinguished names.
1343
1344ASN.1 notation:
1345
1346SET OF Type
1347
1348where Type is a type.
1349
1350Example: X.501's RelativeDistinguishedName type consists of
1351zero or more occurrences of the AttributeValueAssertion
1352type, where the order is unimportant:
1353
1354RelativeDistinguishedName ::=
1355  SET OF AttributeValueAssertion
1356
1357BER encoding. Constructed. Contents octets are the
1358concatenation of the BER encodings of the values of the
1359occurrences in the collection, in any order.
1360
1361DER encoding. Constructed. Contents octets are the same as
1362for the BER encoding, except that there is an order, namely
1363ascending lexicographic order of BER encoding. Lexicographic
1364comparison of two different BER encodings is done as
1365follows: Logically pad the shorter BER encoding after the
1366last octet with dummy octets that are smaller in value than
1367any normal octet. Scan the BER encodings from left to right
1368until a difference is found. The smaller-valued BER encoding
1369is the one with the smaller-valued octet at the point of
1370difference.
1371
1372
13735.16 T61String
1374
1375The T61String type denotes an arbtrary string of T.61
1376characters. T.61 is an eight-bit extension to the ASCII
1377character set. Special "escape" sequences specify the
1378interpretation of subsequent character values as, for
1379example, Japanese; the initial interpretation is Latin. The
1380character set includes non-printing control characters. The
1381T61String type allows only the Latin and Japanese character
1382interepretations, and implementors' agreements for directory
1383names exclude control characters [NIST92]. A T61String value
1384can have any length, including zero. This type is a string
1385type.
1386
1387The T61String type is used in PKCS #9's unstructured-address
1388and challenge-password attributes, and in several X.521
1389attributes.
1390
1391ASN.1 notation:
1392
1393T61String
1394
1395BER encoding. Primitive or constructed. In a primitive
1396encoding, the contents octets give the characters in the
1397T.61 string, encoded in ASCII. In a constructed encoding,
1398the contents octets give the concatenation of the BER
1399encodings of consecutive substrings of the T.61 string.
1400
1401Example: The BER encoding of the T61String value "cl'es
1402publiques" (French for "public keys") can be any of the
1403following, among others, depending on the form of length
1404octets and whether the encoding is primitive or constructed:
1405
140614 0f                                           DER encoding
1407   63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1408
140914 81 0f                          long form of length octets
1410   63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1411
141234 15      constructed encoding: "cl'es" + " " + "publiques"
1413   14 05 63 6c c2 65 73
1414   14 01 20
1415   14 09 70 75 62 6c 69 71 75 65 73
1416
1417The eight-bit character c2 is a T.61 prefix that adds an
1418acute accent (') to the next character.
1419
1420DER encoding. Primitive. Contents octets are as for a
1421primitive BER encoding.
1422
1423Example: The DER encoding of the T61String value "cl'es
1424publiques" is
1425
142614 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1427
1428
14295.17 UTCTime
1430
1431The UTCTime type denotes a "coordinated universal time" or
1432Greenwich Mean Time (GMT) value. A UTCTime value includes
1433the local time precise to either minutes or seconds, and an
1434offset from GMT in hours and minutes. It takes any of the
1435following forms:
1436
1437YYMMDDhhmmZ
1438YYMMDDhhmm+hh'mm'
1439YYMMDDhhmm-hh'mm'
1440YYMMDDhhmmssZ
1441YYMMDDhhmmss+hh'mm'
1442YYMMDDhhmmss-hh'mm'
1443
1444where:
1445
1446     YY is the least significant two digits of the year
1447
1448     MM is the month (01 to 12)
1449
1450     DD is the day (01 to 31)
1451
1452     hh is the hour (00 to 23)
1453
1454     mm are the minutes (00 to 59)
1455
1456     ss are the seconds (00 to 59)
1457
1458     Z indicates that local time is GMT, + indicates that
1459          local time is later than GMT, and - indicates that
1460          local time is earlier than GMT
1461
1462     hh' is the absolute value of the offset from GMT in
1463          hours
1464
1465     mm' is the absolute value of the offset from GMT in
1466          minutes
1467
1468This type is a string type.
1469
1470The UTCTime type is used for signing times in PKCS #9's
1471signing-time attribute and for certificate validity periods
1472in X.509's Validity type.
1473
1474ASN.1 notation:
1475
1476UTCTime
1477
1478BER encoding. Primitive or constructed. In a primitive
1479encoding, the contents octets give the characters in the
1480string, encoded in ASCII. In a constructed encoding, the
1481contents octets give the concatenation of the BER encodings
1482of consecutive substrings of the string. (The constructed
1483encoding is not particularly interesting, since UTCTime
1484values are so short, but the constructed encoding is
1485permitted.)
1486
1487Example: The time this sentence was originally written was
14884:45:40 p.m. Pacific Daylight Time on May 6, 1991, which can
1489be represented with either of the following UTCTime values,
1490among others:
1491
1492"910506164540-0700"
1493
1494"910506234540Z"
1495
1496These values have the following BER encodings, among others:
1497
149817 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a
1499
150017 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30
1501      30
1502
1503DER encoding. Primitive. Contents octets are as for a
1504primitive BER encoding.
1505
1506
15076. An example
1508
1509This section gives an example of ASN.1 notation and DER
1510encoding: the X.501 type Name.
1511
1512
15136.1 Abstract notation
1514
1515This section gives the ASN.1 notation for the X.501 type
1516Name.
1517
1518Name ::= CHOICE {
1519  RDNSequence }
1520
1521RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1522
1523RelativeDistinguishedName ::=
1524  SET OF AttributeValueAssertion
1525
1526AttributeValueAssertion ::= SEQUENCE {
1527   AttributeType,
1528   AttributeValue }
1529
1530AttributeType ::= OBJECT IDENTIFIER
1531
1532AttributeValue ::= ANY
1533
1534The Name type identifies an object in an X.500 directory.
1535Name is a CHOICE type consisting of one alternative:
1536RDNSequence. (Future revisions of X.500 may have other
1537alternatives.)
1538
1539The RDNSequence type gives a path through an X.500 directory
1540tree starting at the root. RDNSequence is a SEQUENCE OF type
1541consisting of zero or more occurences of
1542RelativeDistinguishedName.
1543
1544The RelativeDistinguishedName type gives a unique name to an
1545object relative to the object superior to it in the
1546directory tree. RelativeDistinguishedName is a SET OF type
1547consisting of zero or more occurrences of
1548AttributeValueAssertion.
1549
1550The AttributeValueAssertion type assigns a value to some
1551attribute of a relative distinguished name, such as country
1552name or common name. AttributeValueAssertion is a SEQUENCE
1553type consisting of two components, an AttributeType type and
1554an AttributeValue type.
1555
1556The AttributeType type identifies an attribute by object
1557identifier. The AttributeValue type gives an arbitrary
1558attribute value. The actual type of the attribute value is
1559determined by the attribute type.
1560
1561
15626.2 DER encoding
1563
1564This section gives an example of a DER encoding of a value
1565of type Name, working from the bottom up.
1566
1567The name is that of the Test User 1 from the PKCS examples
1568[Kal93]. The name is represented by the following path:
1569
1570                           (root)
1571                              |
1572                     countryName = "US"
1573                              |
1574          organizationName = "Example Organization"
1575                              |
1576                 commonName = "Test User 1"
1577
1578Each level corresponds to one RelativeDistinguishedName
1579value, each of which happens for this name to consist of one
1580AttributeValueAssertion value. The AttributeType value is
1581before the equals sign, and the AttributeValue value (a
1582printable string for the given attribute types) is after the
1583equals sign.
1584
1585The countryName, organizationName, and commonUnitName are
1586attribute types defined in X.520 as:
1587
1588attributeType OBJECT IDENTIFIER ::=
1589  { joint-iso-ccitt(2) ds(5) 4 }
1590
1591countryName OBJECT IDENTIFIER ::= { attributeType 6 }
1592organizationName OBJECT IDENTIFIER ::=
1593  { attributeType 10 }
1594commonUnitName OBJECT IDENTIFIER ::=
1595  { attributeType 3 }
1596
1597
15986.2.1 AttributeType
1599
1600The three AttributeType values are OCTET STRING values, so
1601their DER encoding follows the primitive, definite-length
1602method:
1603
160406 03 55 04 06                                   countryName
1605
160606 03 55 04 0a                              organizationName
1607
160806 03 55 04 03                                    commonName
1609
1610The identifier octets follow the low-tag form, since the tag
1611is 6 for OBJECT IDENTIFIER. Bits 8 and 7 have value "0,"
1612indicating universal class, and bit 6 has value "0,"
1613indicating that the encoding is primitive. The length octets
1614follow the short form. The contents octets are the
1615concatenation of three octet strings derived from
1616subidentifiers (in decimal): 40 * 2 + 5 = 85 = 5516; 4; and
16176, 10, or 3.
1618
1619
16206.2.2 AttributeValue
1621
1622The three AttributeValue values are PrintableString values,
1623so their encodings follow the primitive, definite-length
1624method:
1625
162613 02 55 53                                             "US"
1627
162813 14                                 "Example Organization"
1629   45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
1630   74 69 6f 6e
1631
163213 0b                                          "Test User 1"
1633   54 65 73 74 20 55 73 65 72 20 31
1634
1635The identifier octets follow the low-tag-number form, since
1636the tag for PrintableString, 19 (decimal), is between 0 and
163730. Bits 8 and 7 have value "0" since PrintableString is in
1638the universal class. Bit 6 has value "0" since the encoding
1639is primitive. The length octets follow the short form, and
1640the contents octets are the ASCII representation of the
1641attribute value.
1642
1643
16446.2.3 AttributeValueAssertion
1645
1646The three AttributeValueAssertion values are SEQUENCE
1647values, so their DER encodings follow the constructed,
1648definite-length method:
1649
165030 09                                     countryName = "US"
1651   06 03 55 04 06
1652   13 02 55 53
1653
165430 1b              organizationName = "Example Organizaiton"
1655   06 03 55 04 0a
1656   13 14 ... 6f 6e
1657
165830 12                             commonName = "Test User 1"
1659   06 03 55 04 0b
1660   13 0b ... 20 31
1661
1662The identifier octets follow the low-tag-number form, since
1663the tag for SEQUENCE, 16 (decimal), is between 0 and 30.
1664Bits 8 and 7 have value "0" since SEQUENCE is in the
1665universal class. Bit 6 has value "1" since the encoding is
1666constructed. The length octets follow the short form, and
1667the contents octets are the concatenation of the DER
1668encodings of the attributeType and attributeValue
1669components.
1670
1671
16726.2.4 RelativeDistinguishedName
1673
1674The three RelativeDistinguishedName values are SET OF
1675values, so their DER encodings follow the constructed,
1676definite-length method:
1677
167831 0b
1679   30 09 ... 55 53
1680
168131 1d
1682   30 1b ... 6f 6e
1683
168431 14
1685   30 12 ... 20 31
1686
1687The identifier octets follow the low-tag-number form, since
1688the tag for SET OF, 17 (decimal), is between 0 and 30. Bits
16898 and 7 have value "0" since SET OF is in the universal
1690class Bit 6 has value "1" since the encoding is constructed.
1691The lengths octets follow the short form, and the contents
1692octets are the DER encodings of the respective
1693AttributeValueAssertion values, since there is only one
1694value in each set.
1695
1696
16976.2.5 RDNSequence
1698
1699The RDNSequence value is a SEQUENCE OF value, so its DER
1700encoding follows the constructed, definite-length method:
1701
170230 42
1703   31 0b ... 55 53
1704   31 1d ... 6f 6e
1705   31 14 ... 20 31
1706
1707The identifier octets follow the low-tag-number form, since
1708the tag for SEQUENCE OF, 16 (decimal), is between 0 and 30.
1709Bits 8 and 7 have value "0" since SEQUENCE OF is in the
1710universal class. Bit 6 has value "1" since the encoding is
1711constructed. The lengths octets follow the short form, and
1712the contents octets are the concatenation of the DER
1713encodings of the three RelativeDistinguishedName values, in
1714order of occurrence.
1715
1716
17176.2.6 Name
1718
1719The Name value is a CHOICE value, so its DER encoding is the
1720same as that of the RDNSequence value:
1721
172230 42
1723   31 0b
1724      30 09
1725         06 03 55 04 06          attributeType = countryName
1726         13 02 55 53                   attributeValue = "US"
1727   31 1d
1728      30 1b
1729         06 03 55 04 0a     attributeType = organizationName
1730         13 14       attributeValue = "Example Organization"
1731            45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
1732            74 69 6f 6e
1733
1734   31 14
1735      30 12
1736         06 03 55 04 03           attributeType = commonName
1737         13 0b                attributeValue = "Test User 1"
1738            54 65 73 74 20 55 73 65 72 20 31
1739
1740
1741References
1742
1743PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption
1744          Standard. Version 1.5, November 1993.
1745
1746PKCS #3   RSA Laboratories. PKCS #3: Diffie-Hellman Key-
1747          Agreement Standard. Version 1.4, November 1993.
1748
1749PKCS #5   RSA Laboratories. PKCS #5: Password-Based
1750          Encryption Standard. Version 1.5, November 1993.
1751
1752PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
1753          Syntax Standard. Version 1.5, November 1993.
1754
1755PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
1756          Syntax Standard. Version 1.5, November 1993.
1757
1758PKCS #8   RSA Laboratories. PKCS #8: Private-Key Information
1759          Syntax Standard. Version 1.2, November 1993.
1760
1761PKCS #9   RSA Laboratories. PKCS #9: Selected Attribute
1762          Types. Version 1.1, November 1993.
1763
1764PKCS #10  RSA Laboratories. PKCS #10: Certification Request
1765          Syntax Standard. Version 1.0, November 1993.
1766
1767X.200     CCITT. Recommendation X.200: Reference Model of
1768          Open Systems Interconnection for CCITT
1769          Applications. 1984.
1770
1771X.208     CCITT. Recommendation X.208: Specification of
1772          Abstract Syntax Notation One (ASN.1). 1988.
1773
1774X.209     CCITT. Recommendation X.209: Specification of
1775          Basic Encoding Rules for Abstract Syntax Notation
1776          One (ASN.1). 1988.
1777
1778X.500     CCITT. Recommendation X.500: The
1779          Directory--Overview of Concepts, Models and
1780          Services. 1988.
1781
1782X.501     CCITT. Recommendation X.501: The Directory--
1783          Models. 1988.
1784
1785X.509     CCITT. Recommendation X.509: The Directory--
1786          Authentication Framework. 1988.
1787
1788X.520     CCITT. Recommendation X.520: The Directory--
1789          Selected Attribute Types. 1988.
1790
1791[Kal93]   Burton S. Kaliski Jr. Some Examples of the PKCS
1792          Standards. RSA Laboratories, November 1993.
1793
1794[NIST92]  NIST. Special Publication 500-202: Stable
1795          Implementation Agreements for Open Systems
1796          Interconnection Protocols. Part 11 (Directory
1797          Services Protocols). December 1992.
1798
1799
1800Revision history
1801
1802
1803June 3, 1991 version
1804
1805The June 3, 1991 version is part of the initial public
1806release of PKCS. It was published as NIST/OSI Implementors'
1807Workshop document SEC-SIG-91-17.
1808
1809
1810November 1, 1993 version
1811
1812The November 1, 1993 version incorporates several editorial
1813changes, including the addition of a revision history. It is
1814updated to be consistent with the following versions of the
1815PKCS documents:
1816
1817     PKCS #1: RSA Encryption Standard. Version 1.5, November
1818          1993.
1819
1820     PKCS #3: Diffie-Hellman Key-Agreement Standard. Version
1821          1.4, November 1993.
1822
1823     PKCS #5: Password-Based Encryption Standard. Version
1824          1.5, November 1993.
1825
1826     PKCS #6: Extended-Certificate Syntax Standard. Version
1827          1.5, November 1993.
1828
1829     PKCS #7: Cryptographic Message Syntax Standard. Version
1830          1.5, November 1993.
1831
1832     PKCS #8: Private-Key Information Syntax Standard.
1833          Version 1.2, November 1993.
1834
1835     PKCS #9: Selected Attribute Types. Version 1.1,
1836          November 1993.
1837
1838     PKCS #10: Certification Request Syntax Standard.
1839          Version 1.0, November 1993.
1840
1841The following substantive changes were made:
1842
1843     Section 5: Description of T61String type is added.
1844
1845     Section 6: Names are changed, consistent with other
1846          PKCS examples.
1847
1848
1849Author's address
1850
1851Burton S. Kaliski Jr., Ph.D.
1852Chief Scientist
1853RSA Laboratories              (415) 595-7703
1854100 Marine Parkway            (415) 595-4126 (fax)
1855Redwood City, CA  94065  USA  burt@rsa.com
1856