| blob | d4fbe64be99d4f06200c4a4aeacb12248a9529ce |
1 A Layman's Guide to a Subset of ASN.1, BER, and DER
3 An RSA Laboratories Technical Note
4 Burton S. Kaliski Jr.
5 Revised November 1, 1993
8 Supersedes June 3, 1991 version, which was also published as
9 NIST/OSI Implementors' Workshop document SEC-SIG-91-17.
10 PKCS documents are available by electronic mail to
11 <pkcs@rsa.com>.
13 Copyright (C) 1991-1993 RSA Laboratories, a division of RSA
14 Data Security, Inc. License to copy this document is granted
15 provided that it is identified as "RSA Data Security, Inc.
16 Public-Key Cryptography Standards (PKCS)" in all material
17 mentioning or referencing this document.
18 003-903015-110-000-000
21 Abstract. This note gives a layman's introduction to a
22 subset of OSI's Abstract Syntax Notation One (ASN.1), Basic
23 Encoding Rules (BER), and Distinguished Encoding Rules
24 (DER). The particular purpose of this note is to provide
25 background material sufficient for understanding and
26 implementing the PKCS family of standards.
29 1. Introduction
31 It is a generally accepted design principle that abstraction
32 is a key to managing software development. With abstraction,
33 a designer can specify a part of a system without concern
34 for how the part is actually implemented or represented.
35 Such a practice leaves the implementation open; it
36 simplifies the specification; and it makes it possible to
37 state "axioms" about the part that can be proved when the
38 part is implemented, and assumed when the part is employed
39 in another, higher-level part. Abstraction is the hallmark
40 of most modern software specifications.
42 One of the most complex systems today, and one that also
43 involves a great deal of abstraction, is Open Systems
44 Interconnection (OSI, described in X.200). OSI is an
45 internationally standardized architecture that governs the
46 interconnection of computers from the physical layer up to
47 the user application layer. Objects at higher layers are
48 defined abstractly and intended to be implemented with
49 objects at lower layers. For instance, a service at one
50 layer may require transfer of certain abstract objects
51 between computers; a lower layer may provide transfer
52 services for strings of ones and zeroes, using encoding
53 rules to transform the abstract objects into such strings.
54 OSI is called an open system because it supports many
55 different implementations of the services at each layer.
57 OSI's method of specifying abstract objects is called ASN.1
58 (Abstract Syntax Notation One, defined in X.208), and one
59 set of rules for representing such objects as strings of
60 ones and zeros is called the BER (Basic Encoding Rules,
61 defined in X.209). ASN.1 is a flexible notation that allows
62 one to define a variety data types, from simple types such
63 as integers and bit strings to structured types such as sets
64 and sequences, as well as complex types defined in terms of
65 others. BER describes how to represent or encode values of
66 each ASN.1 type as a string of eight-bit octets. There is
67 generally more than one way to BER-encode a given value.
68 Another set of rules, called the Distinguished Encoding
69 Rules (DER), which is a subset of BER, gives a unique
70 encoding to each ASN.1 value.
72 The purpose of this note is to describe a subset of ASN.1,
73 BER and DER sufficient to understand and implement one OSI-
74 based application, RSA Data Security, Inc.'s Public-Key
75 Cryptography Standards. The features described include an
76 overview of ASN.1, BER, and DER and an abridged list of
77 ASN.1 types and their BER and DER encodings. Sections 2-4
78 give an overview of ASN.1, BER, and DER, in that order.
79 Section 5 lists some ASN.1 types, giving their notation,
80 specific encoding rules, examples, and comments about their
81 application to PKCS. Section 6 concludes with an example,
82 X.500 distinguished names.
84 Advanced features of ASN.1, such as macros, are not
85 described in this note, as they are not needed to implement
86 PKCS. For information on the other features, and for more
87 detail generally, the reader is referred to CCITT
88 Recommendations X.208 and X.209, which define ASN.1 and BER.
90 Terminology and notation. In this note, an octet is an eight-
91 bit unsigned integer. Bit 8 of the octet is the most
92 significant and bit 1 is the least significant.
94 The following meta-syntax is used for in describing ASN.1
95 notation:
97 BIT monospace denotes literal characters in the type
98 and value notation; in examples, it generally
99 denotes an octet value in hexadecimal
101 n1 bold italics denotes a variable
103 [] bold square brackets indicate that a term is
104 optional
106 {} bold braces group related terms
108 | bold vertical bar delimits alternatives with a
109 group
111 ... bold ellipsis indicates repeated occurrences
113 = bold equals sign expresses terms as subterms
116 2. Abstract Syntax Notation One
118 Abstract Syntax Notation One, abbreviated ASN.1, is a
119 notation for describing abstract types and values.
121 In ASN.1, a type is a set of values. For some types, there
122 are a finite number of values, and for other types there are
123 an infinite number. A value of a given ASN.1 type is an
124 element of the type's set. ASN.1 has four kinds of type:
125 simple types, which are "atomic" and have no components;
126 structured types, which have components; tagged types, which
127 are derived from other types; and other types, which include
128 the CHOICE type and the ANY type. Types and values can be
129 given names with the ASN.1 assignment operator (::=) , and
130 those names can be used in defining other types and values.
132 Every ASN.1 type other than CHOICE and ANY has a tag, which
133 consists of a class and a nonnegative tag number. ASN.1
134 types are abstractly the same if and only if their tag
135 numbers are the same. In other words, the name of an ASN.1
136 type does not affect its abstract meaning, only the tag
137 does. There are four classes of tag:
139 Universal, for types whose meaning is the same in all
140 applications; these types are only defined in
141 X.208.
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.
149 Private, for types whose meaning is specific to a given
150 enterprise.
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.
160 The types with universal tags are defined in X.208, which
161 also gives the types' universal tag numbers. Types with
162 other tags are defined in many places, and are always
163 obtained by implicit or explicit tagging (see Section 2.3).
164 Table 1 lists some ASN.1 types and their universal-class
165 tags.
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
181 Table 1. Some types and their universal-class tags.
183 ASN.1 types and values are expressed in a flexible,
184 programming-language-like notation, with the following
185 special rules:
187 o Layout is not significant; multiple spaces and
188 line breaks can be considered as a single space.
190 o Comments are delimited by pairs of hyphens (--),
191 or a pair of hyphens and a line break.
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.
199 The following four subsections give an overview of simple
200 types, structured types, implicitly and explicitly tagged
201 types, and other types. Section 5 describes specific types
202 in more detail.
205 2.1 Simple types
207 Simple types are those not consisting of components; they
208 are the "atomic" types. ASN.1 defines several; the types
209 that are relevant to the PKCS standards are the following:
211 BIT STRING, an arbitrary string of bits (ones and
212 zeroes).
214 IA5String, an arbitrary string of IA5 (ASCII)
215 characters.
217 INTEGER, an arbitrary integer.
219 NULL, a null value.
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.
225 OCTET STRING, an arbitrary string of octets (eight-bit
226 values).
228 PrintableString, an arbitrary string of printable
229 characters.
231 T61String, an arbitrary string of T.61 (eight-bit)
232 characters.
234 UTCTime, a "coordinated universal time" or Greenwich
235 Mean Time (GMT) value.
237 Simple types fall into two categories: string types and non-
238 string types. BIT STRING, IA5String, OCTET STRING,
239 PrintableString, T61String, and UTCTime are string types.
241 String types can be viewed, for the purposes of encoding, as
242 consisting of components, where the components are
243 substrings. This view allows one to encode a value whose
244 length is not known in advance (e.g., an octet string value
245 input from a file stream) with a constructed, indefinite-
246 length encoding (see Section 3).
248 The string types can be given size constraints limiting the
249 length of values.
252 2.2 Structured types
254 Structured types are those consisting of components. ASN.1
255 defines four, all of which are relevant to the PKCS
256 standards:
258 SEQUENCE, an ordered collection of one or more types.
260 SEQUENCE OF, an ordered collection of zero or more
261 occurrences of a given type.
263 SET, an unordered collection of one or more types.
265 SET OF, an unordered collection of zero or more
266 occurrences of a given type.
268 The structured types can have optional components, possibly
269 with default values.
272 2.3 Implicitly and explicitly tagged types
274 Tagging is useful to distinguish types within an
275 application; it is also commonly used to distinguish
276 component types within a structured type. For instance,
277 optional components of a SET or SEQUENCE type are typically
278 given distinct context-specific tags to avoid ambiguity.
280 There are two ways to tag a type: implicitly and explicitly.
282 Implicitly tagged types are derived from other types by
283 changing the tag of the underlying type. Implicit tagging is
284 denoted by the ASN.1 keywords [class number] IMPLICIT (see
285 Section 5.1).
287 Explicitly tagged types are derived from other types by
288 adding an outer tag to the underlying type. In effect,
289 explicitly tagged types are structured types consisting of
290 one component, the underlying type. Explicit tagging is
291 denoted by the ASN.1 keywords [class number] EXPLICIT (see
292 Section 5.2).
294 The keyword [class number] alone is the same as explicit
295 tagging, except when the "module" in which the ASN.1 type is
296 defined has implicit tagging by default. ("Modules" are
297 among the advanced features not described in this note.)
299 For purposes of encoding, an implicitly tagged type is
300 considered the same as the underlying type, except that the
301 tag is different. An explicitly tagged type is considered
302 like a structured type with one component, the underlying
303 type. Implicit tags result in shorter encodings, but
304 explicit tags may be necessary to avoid ambiguity if the tag
305 of the underlying type is indeterminate (e.g., the
306 underlying type is CHOICE or ANY).
309 2.4 Other types
311 Other types in ASN.1 include the CHOICE and ANY types. The
312 CHOICE type denotes a union of one or more alternatives; the
313 ANY type denotes an arbitrary value of an arbitrary type,
314 where the arbitrary type is possibly defined in the
315 registration of an object identifier or integer value.
318 3. Basic Encoding Rules
320 The Basic Encoding Rules for ASN.1, abbreviated BER, give
321 one or more ways to represent any ASN.1 value as an octet
322 string. (There are certainly other ways to represent ASN.1
323 values, but BER is the standard for interchanging such
324 values in OSI.)
326 There are three methods to encode an ASN.1 value under BER,
327 the choice of which depends on the type of value and whether
328 the length of the value is known. The three methods are
329 primitive, definite-length encoding; constructed, definite-
330 length encoding; and constructed, indefinite-length
331 encoding. Simple non-string types employ the primitive,
332 definite-length method; structured types employ either of
333 the constructed methods; and simple string types employ any
334 of the methods, depending on whether the length of the value
335 is known. Types derived by implicit tagging employ the
336 method of the underlying type and types derived by explicit
337 tagging employ the constructed methods.
339 In each method, the BER encoding has three or four parts:
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.
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.
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.
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.
360 The three methods of encoding are described in the following
361 sections.
364 3.1 Primitive, definite-length method
366 This method applies to simple types and types derived from
367 simple types by implicit tagging. It requires that the
368 length of the value be known in advance. The parts of the
369 BER encoding are as follows:
371 Identifier octets. There are two forms: low tag number (for
372 tag numbers between 0 and 30) and high tag number (for tag
373 numbers 31 and greater).
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.
380 Class Bit Bit
381 8 7
382 universal 0 0
383 application 0 1
384 context-specific 1 0
385 private 1 1
387 Table 2. Class encoding in identifier octets.
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."
397 Length octets. There are two forms: short (for lengths
398 between 0 and 127), and long definite (for lengths between 0
399 and 21008-1).
401 Short form. One octet. Bit 8 has value "0" and bits 7-1
402 give the length.
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.
410 Contents octets. These give a concrete representation of the
411 value (or the value of the underlying type, if the type is
412 derived by implicit tagging). Details for particular types
413 are given in Section 5.
416 3.2 Constructed, definite-length method
418 This method applies to simple string types, structured
419 types, types derived simple string types and structured
420 types by implicit tagging, and types derived from anything
421 by explicit tagging. It requires that the length of the
422 value be known in advance. The parts of the BER encoding are
423 as follows:
425 Identifier octets. As described in Section 3.1, except that
426 bit 6 has value "1," indicating that the encoding is
427 constructed.
429 Length octets. As described in Section 3.1.
431 Contents octets. The concatenation of the BER encodings of
432 the components of the value:
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).
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).
444 o For types derived from anything by explicit
445 tagging, the BER encoding of the underlying value.
447 Details for particular types are given in Section 5.
450 3.3 Constructed, indefinite-length method
452 This method applies to simple string types, structured
453 types, types derived simple string types and structured
454 types by implicit tagging, and types derived from anything
455 by explicit tagging. It does not require that the length of
456 the value be known in advance. The parts of the BER encoding
457 are as follows:
459 Identifier octets. As described in Section 3.2.
461 Length octets. One octet, 80.
463 Contents octets. As described in Section 3.2.
465 End-of-contents octets. Two octets, 00 00.
467 Since the end-of-contents octets appear where an ordinary
468 BER encoding might be expected (e.g., in the contents octets
469 of a sequence value), the 00 and 00 appear as identifier and
470 length octets, respectively. Thus the end-of-contents octets
471 is really the primitive, definite-length encoding of a value
472 with universal class, tag number 0, and length 0.
475 4. Distinguished Encoding Rules
477 The Distinguished Encoding Rules for ASN.1, abbreviated DER,
478 are a subset of BER, and give exactly one way to represent
479 any ASN.1 value as an octet string. DER is intended for
480 applications in which a unique octet string encoding is
481 needed, as is the case when a digital signature is computed
482 on an ASN.1 value. DER is defined in Section 8.7 of X.509.
484 DER adds the following restrictions to the rules given in
485 Section 3:
487 1. When the length is between 0 and 127, the short
488 form of length must be used
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.
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.
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.
505 Other restrictions are defined for particular types (such as
506 BIT STRING, SEQUENCE, SET, and SET OF), and can be found in
507 Section 5.
510 5. Notation and encodings for some types
512 This section gives the notation for some ASN.1 types and
513 describes how to encode values of those types under both BER
514 and DER.
516 The types described are those presented in Section 2. They
517 are listed alphabetically here.
519 Each description includes ASN.1 notation, BER encoding, and
520 DER encoding. The focus of the encodings is primarily on the
521 contents octets; the tag and length octets follow Sections 3
522 and 4. The descriptions also explain where each type is used
523 in PKCS and related standards. ASN.1 notation is generally
524 only for types, although for the type OBJECT IDENTIFIER,
525 value notation is given as well.
528 5.1 Implicitly tagged types
530 An implicitly tagged type is a type derived from another
531 type by changing the tag of the underlying type.
533 Implicit tagging is used for optional SEQUENCE components
534 with underlying type other than ANY throughout PKCS, and for
535 the extendedCertificate alternative of PKCS #7's
536 ExtendedCertificateOrCertificate type.
538 ASN.1 notation:
540 [[class] number] IMPLICIT Type
542 class = UNIVERSAL | APPLICATION | PRIVATE
544 where Type is a type, class is an optional class name, and
545 number is the tag number within the class, a nonnegative
546 integer.
548 In ASN.1 "modules" whose default tagging method is implicit
549 tagging, the notation [[class] number] Type is also
550 acceptable, and the keyword IMPLICIT is implied. (See
551 Section 2.3.) For definitions stated outside a module, the
552 explicit inclusion of the keyword IMPLICIT is preferable to
553 prevent ambiguity.
555 If the class name is absent, then the tag is context-
556 specific. Context-specific tags can only appear in a
557 component of a structured or CHOICE type.
559 Example: PKCS #8's PrivateKeyInfo type has an optional
560 attributes component with an implicit, context-specific tag:
562 PrivateKeyInfo ::= SEQUENCE {
563 version Version,
564 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
565 privateKey PrivateKey,
566 attributes [0] IMPLICIT Attributes OPTIONAL }
568 Here the underlying type is Attributes, the class is absent
569 (i.e., context-specific), and the tag number within the
570 class is 0.
572 BER encoding. Primitive or constructed, depending on the
573 underlying type. Contents octets are as for the BER encoding
574 of the underlying value.
576 Example: The BER encoding of the attributes component of a
577 PrivateKeyInfo value is as follows:
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
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
588 DER encoding. Primitive or constructed, depending on the
589 underlying type. Contents octets are as for the DER encoding
590 of the underlying value.
593 5.2 Explicitly tagged types
595 Explicit tagging denotes a type derived from another type by
596 adding an outer tag to the underlying type.
598 Explicit tagging is used for optional SEQUENCE components
599 with underlying type ANY throughout PKCS, and for the
600 version component of X.509's Certificate type.
602 ASN.1 notation:
604 [[class] number] EXPLICIT Type
606 class = UNIVERSAL | APPLICATION | PRIVATE
608 where Type is a type, class is an optional class name, and
609 number is the tag number within the class, a nonnegative
610 integer.
612 If the class name is absent, then the tag is context-
613 specific. Context-specific tags can only appear in a
614 component of a SEQUENCE, SET or CHOICE type.
616 In ASN.1 "modules" whose default tagging method is explicit
617 tagging, the notation [[class] number] Type is also
618 acceptable, and the keyword EXPLICIT is implied. (See
619 Section 2.3.) For definitions stated outside a module, the
620 explicit inclusion of the keyword EXPLICIT is preferable to
621 prevent ambiguity.
623 Example 1: PKCS #7's ContentInfo type has an optional
624 content component with an explicit, context-specific tag:
626 ContentInfo ::= SEQUENCE {
627 contentType ContentType,
628 content
629 [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
631 Here the underlying type is ANY DEFINED BY contentType, the
632 class is absent (i.e., context-specific), and the tag number
633 within the class is 0.
635 Example 2: X.509's Certificate type has a version component
636 with an explicit, context-specific tag, where the EXPLICIT
637 keyword is omitted:
639 Certificate ::= ...
640 version [0] Version DEFAULT v1988,
641 ...
643 The tag is explicit because the default tagging method for
644 the ASN.1 "module" in X.509 that defines the Certificate
645 type is explicit tagging.
647 BER encoding. Constructed. Contents octets are the BER
648 encoding of the underlying value.
650 Example: the BER encoding of the content component of a
651 ContentInfo value is as follows:
653 o identifier octets are a0
655 o length octets represent the length of the BER
656 encoding of the underlying ANY DEFINED BY
657 contentType value
659 o contents octets are the BER encoding of the
660 underlying ANY DEFINED BY contentType value
662 DER encoding. Constructed. Contents octets are the DER
663 encoding of the underlying value.
666 5.3 ANY
668 The ANY type denotes an arbitrary value of an arbitrary
669 type, where the arbitrary type is possibly defined in the
670 registration of an object identifier or associated with an
671 integer index.
673 The ANY type is used for content of a particular content
674 type in PKCS #7's ContentInfo type, for parameters of a
675 particular algorithm in X.509's AlgorithmIdentifier type,
676 and for attribute values in X.501's Attribute and
677 AttributeValueAssertion types. The Attribute type is used by
678 PKCS #6, #7, #8, #9 and #10, and the AttributeValueAssertion
679 type is used in X.501 distinguished names.
681 ASN.1 notation:
683 ANY [DEFINED BY identifier]
685 where identifier is an optional identifier.
687 In the ANY form, the actual type is indeterminate.
689 The ANY DEFINED BY identifier form can only appear in a
690 component of a SEQUENCE or SET type for which identifier
691 identifies some other component, and that other component
692 has type INTEGER or OBJECT IDENTIFIER (or a type derived
693 from either of those by tagging). In that form, the actual
694 type is determined by the value of the other component,
695 either in the registration of the object identifier value,
696 or in a table of integer values.
698 Example: X.509's AlgorithmIdentifier type has a component of
699 type ANY:
701 AlgorithmIdentifier ::= SEQUENCE {
702 algorithm OBJECT IDENTIFIER,
703 parameters ANY DEFINED BY algorithm OPTIONAL }
705 Here the actual type of the parameter component depends on
706 the value of the algorithm component. The actual type would
707 be defined in the registration of object identifier values
708 for the algorithm component.
710 BER encoding. Same as the BER encoding of the actual value.
712 Example: The BER encoding of the value of the parameter
713 component is the BER encoding of the value of the actual
714 type as defined in the registration of object identifier
715 values for the algorithm component.
717 DER encoding. Same as the DER encoding of the actual value.
720 5.4 BIT STRING
722 The BIT STRING type denotes an arbitrary string of bits
723 (ones and zeroes). A BIT STRING value can have any length,
724 including zero. This type is a string type.
726 The BIT STRING type is used for digital signatures on
727 extended certificates in PKCS #6's ExtendedCertificate type,
728 for digital signatures on certificates in X.509's
729 Certificate type, and for public keys in certificates in
730 X.509's SubjectPublicKeyInfo type.
732 ASN.1 notation:
734 BIT STRING
736 Example: X.509's SubjectPublicKeyInfo type has a component
737 of type BIT STRING:
739 SubjectPublicKeyInfo ::= SEQUENCE {
740 algorithm AlgorithmIdentifier,
741 publicKey BIT STRING }
743 BER encoding. Primitive or constructed. In a primitive
744 encoding, the first contents octet gives the number of bits
745 by which the length of the bit string is less than the next
746 multiple of eight (this is called the "number of unused
747 bits"). The second and following contents octets give the
748 value of the bit string, converted to an octet string. The
749 conversion process is as follows:
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.
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.
762 In a constructed encoding, the contents octets give the
763 concatenation of the BER encodings of consecutive substrings
764 of the bit string, where each substring except the last has
765 a length that is a multiple of eight bits.
767 Example: The BER encoding of the BIT STRING value
768 "011011100101110111" can be any of the following, among
769 others, depending on the choice of padding bits, the form of
770 length octets, and whether the encoding is primitive or
771 constructed:
773 03 04 06 6e 5d c0 DER encoding
775 03 04 06 6e 5d e0 padded with "100000"
777 03 81 04 06 6e 5d c0 long form of length octets
779 23 09 constructed encoding: "0110111001011101" + "11"
780 03 03 00 6e 5d
781 03 02 06 c0
783 DER encoding. Primitive. The contents octects are as for a
784 primitive BER encoding, except that the bit string is padded
785 with zero-valued bits.
787 Example: The DER encoding of the BIT STRING value
788 "011011100101110111" is
790 03 04 06 6e 5d c0
793 5.5 CHOICE
795 The CHOICE type denotes a union of one or more alternatives.
797 The CHOICE type is used to represent the union of an
798 extended certificate and an X.509 certificate in PKCS #7's
799 ExtendedCertificateOrCertificate type.
801 ASN.1 notation:
803 CHOICE {
804 [identifier1] Type1,
805 ...,
806 [identifiern] Typen }
808 where identifier1 , ..., identifiern are optional, distinct
809 identifiers for the alternatives, and Type1, ..., Typen are
810 the types of the alternatives. The identifiers are primarily
811 for documentation; they do not affect values of the type or
812 their encodings in any way.
814 The types must have distinct tags. This requirement is
815 typically satisfied with explicit or implicit tagging on
816 some of the alternatives.
818 Example: PKCS #7's ExtendedCertificateOrCertificate type is
819 a CHOICE type:
821 ExtendedCertificateOrCertificate ::= CHOICE {
822 certificate Certificate, -- X.509
823 extendedCertificate [0] IMPLICIT ExtendedCertificate
824 }
826 Here the identifiers for the alternatives are certificate
827 and extendedCertificate, and the types of the alternatives
828 are Certificate and [0] IMPLICIT ExtendedCertificate.
830 BER encoding. Same as the BER encoding of the chosen
831 alternative. The fact that the alternatives have distinct
832 tags makes it possible to distinguish between their BER
833 encodings.
835 Example: The identifier octets for the BER encoding are 30
836 if the chosen alternative is certificate, and a0 if the
837 chosen alternative is extendedCertificate.
839 DER encoding. Same as the DER encoding of the chosen
840 alternative.
843 5.6 IA5String
845 The IA5String type denotes an arbtrary string of IA5
846 characters. IA5 stands for International Alphabet 5, which
847 is the same as ASCII. The character set includes non-
848 printing control characters. An IA5String value can have any
849 length, including zero. This type is a string type.
851 The IA5String type is used in PKCS #9's electronic-mail
852 address, unstructured-name, and unstructured-address
853 attributes.
855 ASN.1 notation:
857 IA5String
859 BER encoding. Primitive or constructed. In a primitive
860 encoding, the contents octets give the characters in the IA5
861 string, encoded in ASCII. In a constructed encoding, the
862 contents octets give the concatenation of the BER encodings
863 of consecutive substrings of the IA5 string.
865 Example: The BER encoding of the IA5String value
866 "test1@rsa.com" can be any of the following, among others,
867 depending on the form of length octets and whether the
868 encoding is primitive or constructed:
870 16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d DER encoding
872 16 81 0d long form of length octets
873 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
875 36 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
880 DER encoding. Primitive. Contents octets are as for a
881 primitive BER encoding.
883 Example: The DER encoding of the IA5String value
884 "test1@rsa.com" is
886 16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
889 5.7 INTEGER
891 The INTEGER type denotes an arbitrary integer. INTEGER
892 values can be positive, negative, or zero, and can have any
893 magnitude.
895 The INTEGER type is used for version numbers throughout
896 PKCS, cryptographic values such as modulus, exponent, and
897 primes in PKCS #1's RSAPublicKey and RSAPrivateKey types and
898 PKCS #3's DHParameter type, a message-digest iteration count
899 in PKCS #5's PBEParameter type, and version numbers and
900 serial numbers in X.509's Certificate type.
902 ASN.1 notation:
904 INTEGER [{ identifier1(value1) ... identifiern(valuen) }]
906 where identifier1, ..., identifiern are optional distinct
907 identifiers and value1, ..., valuen are optional integer
908 values. The identifiers, when present, are associated with
909 values of the type.
911 Example: X.509's Version type is an INTEGER type with
912 identified values:
914 Version ::= INTEGER { v1988(0) }
916 The identifier v1988 is associated with the value 0. X.509's
917 Certificate type uses the identifier v1988 to give a default
918 value of 0 for the version component:
920 Certificate ::= ...
921 version Version DEFAULT v1988,
922 ...
924 BER encoding. Primitive. Contents octets give the value of
925 the integer, base 256, in two's complement form, most
926 significant digit first, with the minimum number of octets.
927 The value 0 is encoded as a single 00 octet.
929 Some example BER encodings (which also happen to be DER
930 encodings) are given in Table 3.
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
941 Table 3. Example BER encodings of INTEGER values.
943 DER encoding. Primitive. Contents octets are as for a
944 primitive BER encoding.
947 5.8 NULL
949 The NULL type denotes a null value.
951 The NULL type is used for algorithm parameters in several
952 places in PKCS.
954 ASN.1 notation:
956 NULL
958 BER encoding. Primitive. Contents octets are empty.
960 Example: The BER encoding of a NULL value can be either of
961 the following, as well as others, depending on the form of
962 the length octets:
964 05 00
966 05 81 00
968 DER encoding. Primitive. Contents octets are empty; the DER
969 encoding of a NULL value is always 05 00.
972 5.9 OBJECT IDENTIFIER
974 The OBJECT IDENTIFIER type denotes an object identifier, a
975 sequence of integer components that identifies an object
976 such as an algorithm, an attribute type, or perhaps a
977 registration authority that defines other object
978 identifiers. An OBJECT IDENTIFIER value can have any number
979 of components, and components can generally have any
980 nonnegative value. This type is a non-string type.
982 OBJECT IDENTIFIER values are given meanings by registration
983 authorities. Each registration authority is responsible for
984 all sequences of components beginning with a given sequence.
985 A registration authority typically delegates responsibility
986 for subsets of the sequences in its domain to other
987 registration authorities, or for particular types of object.
988 There are always at least two components.
990 The OBJECT IDENTIFIER type is used to identify content in
991 PKCS #7's ContentInfo type, to identify algorithms in
992 X.509's AlgorithmIdentifier type, and to identify attributes
993 in X.501's Attribute and AttributeValueAssertion types. The
994 Attribute type is used by PKCS #6, #7, #8, #9, and #10, and
995 the AttributeValueAssertion type is used in X.501
996 distinguished names. OBJECT IDENTIFIER values are defined
997 throughout PKCS.
999 ASN.1 notation:
1001 OBJECT IDENTIFIER
1003 The ASN.1 notation for values of the OBJECT IDENTIFIER type
1004 is
1006 { [identifier] component1 ... componentn }
1008 componenti = identifieri | identifieri (valuei) | valuei
1010 where identifier, identifier1, ..., identifiern are
1011 identifiers, and value1, ..., valuen are optional integer
1012 values.
1014 The form without identifier is the "complete" value with all
1015 its components; the form with identifier abbreviates the
1016 beginning components with another object identifier value.
1017 The identifiers identifier1, ..., identifiern are intended
1018 primarily for documentation, but they must correspond to the
1019 integer value when both are present. These identifiers can
1020 appear without integer values only if they are among a small
1021 set of identifiers defined in X.208.
1023 Example: The following values both refer to the object
1024 identifier assigned to RSA Data Security, Inc.:
1026 { iso(1) member-body(2) 840 113549 }
1027 { 1 2 840 113549 }
1029 (In this example, which gives ASN.1 value notation, the
1030 object identifier values are decimal, not hexadecimal.)
1031 Table 4 gives some other object identifier values and their
1032 meanings.
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
1042 Table 4. Some object identifier values and their meanings.
1044 BER encoding. Primitive. Contents octets are as follows,
1045 where value1, ..., valuen denote the integer values of the
1046 components in the complete object identifier:
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.)
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."
1061 Example: The first octet of the BER encoding of RSA Data
1062 Security, Inc.'s object identifier is 40 * 1 + 2 = 42 =
1063 2a16. The encoding of 840 = 6 * 128 + 4816 is 86 48 and the
1064 encoding of 113549 = 6 * 1282 + 7716 * 128 + d16 is 86 f7
1065 0d. This leads to the following BER encoding:
1067 06 06 2a 86 48 86 f7 0d
1069 DER encoding. Primitive. Contents octets are as for a
1070 primitive BER encoding.
1073 5.10 OCTET STRING
1075 The OCTET STRING type denotes an arbitrary string of octets
1076 (eight-bit values). An OCTET STRING value can have any
1077 length, including zero. This type is a string type.
1079 The OCTET STRING type is used for salt values in PKCS #5's
1080 PBEParameter type, for message digests, encrypted message
1081 digests, and encrypted content in PKCS #7, and for private
1082 keys and encrypted private keys in PKCS #8.
1084 ASN.1 notation:
1086 OCTET STRING [SIZE ({size | size1..size2})]
1088 where size, size1, and size2 are optional size constraints.
1089 In the OCTET STRING SIZE (size) form, the octet string must
1090 have size octets. In the OCTET STRING SIZE (size1..size2)
1091 form, the octet string must have between size1 and size2
1092 octets. In the OCTET STRING form, the octet string can have
1093 any size.
1095 Example: PKCS #5's PBEParameter type has a component of type
1096 OCTET STRING:
1098 PBEParameter ::= SEQUENCE {
1099 salt OCTET STRING SIZE(8),
1100 iterationCount INTEGER }
1102 Here the size of the salt component is always eight octets.
1104 BER encoding. Primitive or constructed. In a primitive
1105 encoding, the contents octets give the value of the octet
1106 string, first octet to last octet. In a constructed
1107 encoding, the contents octets give the concatenation of the
1108 BER encodings of substrings of the OCTET STRING value.
1110 Example: The BER encoding of the OCTET STRING value 01 23 45
1111 67 89 ab cd ef can be any of the following, among others,
1112 depending on the form of length octets and whether the
1113 encoding is primitive or constructed:
1115 04 08 01 23 45 67 89 ab cd ef DER encoding
1117 04 81 08 01 23 45 67 89 ab cd ef long form of length octets
1119 24 0c constructed encoding: 01 ... 67 + 89 ... ef
1120 04 04 01 23 45 67
1121 04 04 89 ab cd ef
1123 DER encoding. Primitive. Contents octets are as for a
1124 primitive BER encoding.
1126 Example: The BER encoding of the OCTET STRING value 01 23 45
1127 67 89 ab cd ef is
1129 04 08 01 23 45 67 89 ab cd ef
1132 5.11 PrintableString
1134 The PrintableString type denotes an arbitrary string of
1135 printable characters from the following character set:
1137 A, B, ..., Z
1138 a, b, ..., z
1139 0, 1, ..., 9
1140 (space) ' ( ) + , - . / : = ?
1142 This type is a string type.
1144 The PrintableString type is used in PKCS #9's challenge-
1145 password and unstructuerd-address attributes, and in several
1146 X.521 distinguished names attributes.
1148 ASN.1 notation:
1150 PrintableString
1152 BER encoding. Primitive or constructed. In a primitive
1153 encoding, the contents octets give the characters in the
1154 printable string, encoded in ASCII. In a constructed
1155 encoding, the contents octets give the concatenation of the
1156 BER encodings of consecutive substrings of the string.
1158 Example: The BER encoding of the PrintableString value "Test
1159 User 1" can be any of the following, among others, depending
1160 on the form of length octets and whether the encoding is
1161 primitive or constructed:
1163 13 0b 54 65 73 74 20 55 73 65 72 20 31 DER encoding
1165 13 81 0b long form of length octets
1166 54 65 73 74 20 55 73 65 72 20 31
1168 33 0f constructed encoding: "Test " + "User 1"
1169 13 05 54 65 73 74 20
1170 13 06 55 73 65 72 20 31
1172 DER encoding. Primitive. Contents octets are as for a
1173 primitive BER encoding.
1175 Example: The DER encoding of the PrintableString value "Test
1176 User 1" is
1178 13 0b 54 65 73 74 20 55 73 65 72 20 31
1181 5.12 SEQUENCE
1183 The SEQUENCE type denotes an ordered collection of one or
1184 more types.
1186 The SEQUENCE type is used throughout PKCS and related
1187 standards.
1189 ASN.1 notation:
1191 SEQUENCE {
1192 [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
1193 ...,
1194 [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
1196 where identifier1 , ..., identifiern are optional, distinct
1197 identifiers for the components, Type1, ..., Typen are the
1198 types of the components, and value1, ..., valuen are optional
1199 default values for the components. The identifiers are
1200 primarily for documentation; they do not affect values of
1201 the type or their encodings in any way.
1203 The OPTIONAL qualifier indicates that the value of a
1204 component is optional and need not be present in the
1205 sequence. The DEFAULT qualifier also indicates that the
1206 value of a component is optional, and assigns a default
1207 value to the component when the component is absent.
1209 The types of any consecutive series of components with the
1210 OPTIONAL or DEFAULT qualifier, as well as of any component
1211 immediately following that series, must have distinct tags.
1212 This requirement is typically satisfied with explicit or
1213 implicit tagging on some of the components.
1215 Example: X.509's Validity type is a SEQUENCE type with two
1216 components:
1218 Validity ::= SEQUENCE {
1219 start UTCTime,
1220 end UTCTime }
1222 Here the identifiers for the components are start and end,
1223 and the types of the components are both UTCTime.
1225 BER encoding. Constructed. Contents octets are the
1226 concatenation of the BER encodings of the values of the
1227 components of the sequence, in order of definition, with the
1228 following rules for components with the OPTIONAL and DEFAULT
1229 qualifiers:
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
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
1241 DER encoding. Constructed. Contents octets are the same as
1242 the BER encoding, except that if the value of a component
1243 with the DEFAULT qualifier is the default value, the
1244 encoding of that component is not included in the contents
1245 octets.
1248 5.13 SEQUENCE OF
1250 The SEQUENCE OF type denotes an ordered collection of zero
1251 or more occurrences of a given type.
1253 The SEQUENCE OF type is used in X.501 distinguished names.
1255 ASN.1 notation:
1257 SEQUENCE OF Type
1259 where Type is a type.
1261 Example: X.501's RDNSequence type consists of zero or more
1262 occurences of the RelativeDistinguishedName type, most
1263 significant occurrence first:
1265 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1267 BER encoding. Constructed. Contents octets are the
1268 concatenation of the BER encodings of the values of the
1269 occurrences in the collection, in order of occurence.
1271 DER encoding. Constructed. Contents octets are the
1272 concatenation of the DER encodings of the values of the
1273 occurrences in the collection, in order of occurence.
1276 5.14 SET
1278 The SET type denotes an unordered collection of one or more
1279 types.
1281 The SET type is not used in PKCS.
1283 ASN.1 notation:
1285 SET {
1286 [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
1287 ...,
1288 [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
1290 where identifier1, ..., identifiern are optional, distinct
1291 identifiers for the components, Type1, ..., Typen are the
1292 types of the components, and value1, ..., valuen are
1293 optional default values for the components. The identifiers
1294 are primarily for documentation; they do not affect values
1295 of the type or their encodings in any way.
1297 The OPTIONAL qualifier indicates that the value of a
1298 component is optional and need not be present in the set.
1299 The DEFAULT qualifier also indicates that the value of a
1300 component is optional, and assigns a default value to the
1301 component when the component is absent.
1303 The types must have distinct tags. This requirement is
1304 typically satisfied with explicit or implicit tagging on
1305 some of the components.
1307 BER encoding. Constructed. Contents octets are the
1308 concatenation of the BER encodings of the values of the
1309 components of the set, in any order, with the following
1310 rules for components with the OPTIONAL and DEFAULT
1311 qualifiers:
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
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
1323 DER encoding. Constructed. Contents octets are the same as
1324 for the BER encoding, except that:
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.
1330 2. There is an order to the components, namely
1331 ascending order by tag.
1334 5.15 SET OF
1336 The SET OF type denotes an unordered collection of zero or
1337 more occurrences of a given type.
1339 The SET OF type is used for sets of attributes in PKCS #6,
1340 #7, #8, #9 and #10, for sets of message-digest algorithm
1341 identifiers, signer information, and recipient information
1342 in PKCS #7, and in X.501 distinguished names.
1344 ASN.1 notation:
1346 SET OF Type
1348 where Type is a type.
1350 Example: X.501's RelativeDistinguishedName type consists of
1351 zero or more occurrences of the AttributeValueAssertion
1352 type, where the order is unimportant:
1354 RelativeDistinguishedName ::=
1355 SET OF AttributeValueAssertion
1357 BER encoding. Constructed. Contents octets are the
1358 concatenation of the BER encodings of the values of the
1359 occurrences in the collection, in any order.
1361 DER encoding. Constructed. Contents octets are the same as
1362 for the BER encoding, except that there is an order, namely
1363 ascending lexicographic order of BER encoding. Lexicographic
1364 comparison of two different BER encodings is done as
1365 follows: Logically pad the shorter BER encoding after the
1366 last octet with dummy octets that are smaller in value than
1367 any normal octet. Scan the BER encodings from left to right
1368 until a difference is found. The smaller-valued BER encoding
1369 is the one with the smaller-valued octet at the point of
1370 difference.
1373 5.16 T61String
1375 The T61String type denotes an arbtrary string of T.61
1376 characters. T.61 is an eight-bit extension to the ASCII
1377 character set. Special "escape" sequences specify the
1378 interpretation of subsequent character values as, for
1379 example, Japanese; the initial interpretation is Latin. The
1380 character set includes non-printing control characters. The
1381 T61String type allows only the Latin and Japanese character
1382 interepretations, and implementors' agreements for directory
1383 names exclude control characters [NIST92]. A T61String value
1384 can have any length, including zero. This type is a string
1385 type.
1387 The T61String type is used in PKCS #9's unstructured-address
1388 and challenge-password attributes, and in several X.521
1389 attributes.
1391 ASN.1 notation:
1393 T61String
1395 BER encoding. Primitive or constructed. In a primitive
1396 encoding, the contents octets give the characters in the
1397 T.61 string, encoded in ASCII. In a constructed encoding,
1398 the contents octets give the concatenation of the BER
1399 encodings of consecutive substrings of the T.61 string.
1401 Example: The BER encoding of the T61String value "cl'es
1402 publiques" (French for "public keys") can be any of the
1403 following, among others, depending on the form of length
1404 octets and whether the encoding is primitive or constructed:
1406 14 0f DER encoding
1407 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1409 14 81 0f long form of length octets
1410 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1412 34 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
1417 The eight-bit character c2 is a T.61 prefix that adds an
1418 acute accent (') to the next character.
1420 DER encoding. Primitive. Contents octets are as for a
1421 primitive BER encoding.
1423 Example: The DER encoding of the T61String value "cl'es
1424 publiques" is
1426 14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1429 5.17 UTCTime
1431 The UTCTime type denotes a "coordinated universal time" or
1432 Greenwich Mean Time (GMT) value. A UTCTime value includes
1433 the local time precise to either minutes or seconds, and an
1434 offset from GMT in hours and minutes. It takes any of the
1435 following forms:
1437 YYMMDDhhmmZ
1438 YYMMDDhhmm+hh'mm'
1439 YYMMDDhhmm-hh'mm'
1440 YYMMDDhhmmssZ
1441 YYMMDDhhmmss+hh'mm'
1442 YYMMDDhhmmss-hh'mm'
1444 where:
1446 YY is the least significant two digits of the year
1448 MM is the month (01 to 12)
1450 DD is the day (01 to 31)
1452 hh is the hour (00 to 23)
1454 mm are the minutes (00 to 59)
1456 ss are the seconds (00 to 59)
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
1462 hh' is the absolute value of the offset from GMT in
1463 hours
1465 mm' is the absolute value of the offset from GMT in
1466 minutes
1468 This type is a string type.
1470 The UTCTime type is used for signing times in PKCS #9's
1471 signing-time attribute and for certificate validity periods
1472 in X.509's Validity type.
1474 ASN.1 notation:
1476 UTCTime
1478 BER encoding. Primitive or constructed. In a primitive
1479 encoding, the contents octets give the characters in the
1480 string, encoded in ASCII. In a constructed encoding, the
1481 contents octets give the concatenation of the BER encodings
1482 of consecutive substrings of the string. (The constructed
1483 encoding is not particularly interesting, since UTCTime
1484 values are so short, but the constructed encoding is
1485 permitted.)
1487 Example: The time this sentence was originally written was
1488 4:45:40 p.m. Pacific Daylight Time on May 6, 1991, which can
1489 be represented with either of the following UTCTime values,
1490 among others:
1492 "910506164540-0700"
1494 "910506234540Z"
1496 These values have the following BER encodings, among others:
1498 17 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a
1500 17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30
1501 30
1503 DER encoding. Primitive. Contents octets are as for a
1504 primitive BER encoding.
1507 6. An example
1509 This section gives an example of ASN.1 notation and DER
1510 encoding: the X.501 type Name.
1513 6.1 Abstract notation
1515 This section gives the ASN.1 notation for the X.501 type
1516 Name.
1518 Name ::= CHOICE {
1519 RDNSequence }
1521 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1523 RelativeDistinguishedName ::=
1524 SET OF AttributeValueAssertion
1526 AttributeValueAssertion ::= SEQUENCE {
1527 AttributeType,
1528 AttributeValue }
1530 AttributeType ::= OBJECT IDENTIFIER
1532 AttributeValue ::= ANY
1534 The Name type identifies an object in an X.500 directory.
1535 Name is a CHOICE type consisting of one alternative:
1536 RDNSequence. (Future revisions of X.500 may have other
1537 alternatives.)
1539 The RDNSequence type gives a path through an X.500 directory
1540 tree starting at the root. RDNSequence is a SEQUENCE OF type
1541 consisting of zero or more occurences of
1542 RelativeDistinguishedName.
1544 The RelativeDistinguishedName type gives a unique name to an
1545 object relative to the object superior to it in the
1546 directory tree. RelativeDistinguishedName is a SET OF type
1547 consisting of zero or more occurrences of
1548 AttributeValueAssertion.
1550 The AttributeValueAssertion type assigns a value to some
1551 attribute of a relative distinguished name, such as country
1552 name or common name. AttributeValueAssertion is a SEQUENCE
1553 type consisting of two components, an AttributeType type and
1554 an AttributeValue type.
1556 The AttributeType type identifies an attribute by object
1557 identifier. The AttributeValue type gives an arbitrary
1558 attribute value. The actual type of the attribute value is
1559 determined by the attribute type.
1562 6.2 DER encoding
1564 This section gives an example of a DER encoding of a value
1565 of type Name, working from the bottom up.
1567 The name is that of the Test User 1 from the PKCS examples
1568 [Kal93]. The name is represented by the following path:
1570 (root)
1571 |
1572 countryName = "US"
1573 |
1574 organizationName = "Example Organization"
1575 |
1576 commonName = "Test User 1"
1578 Each level corresponds to one RelativeDistinguishedName
1579 value, each of which happens for this name to consist of one
1580 AttributeValueAssertion value. The AttributeType value is
1581 before the equals sign, and the AttributeValue value (a
1582 printable string for the given attribute types) is after the
1583 equals sign.
1585 The countryName, organizationName, and commonUnitName are
1586 attribute types defined in X.520 as:
1588 attributeType OBJECT IDENTIFIER ::=
1589 { joint-iso-ccitt(2) ds(5) 4 }
1591 countryName OBJECT IDENTIFIER ::= { attributeType 6 }
1592 organizationName OBJECT IDENTIFIER ::=
1593 { attributeType 10 }
1594 commonUnitName OBJECT IDENTIFIER ::=
1595 { attributeType 3 }
1598 6.2.1 AttributeType
1600 The three AttributeType values are OCTET STRING values, so
1601 their DER encoding follows the primitive, definite-length
1602 method:
1604 06 03 55 04 06 countryName
1606 06 03 55 04 0a organizationName
1608 06 03 55 04 03 commonName
1610 The identifier octets follow the low-tag form, since the tag
1611 is 6 for OBJECT IDENTIFIER. Bits 8 and 7 have value "0,"
1612 indicating universal class, and bit 6 has value "0,"
1613 indicating that the encoding is primitive. The length octets
1614 follow the short form. The contents octets are the
1615 concatenation of three octet strings derived from
1616 subidentifiers (in decimal): 40 * 2 + 5 = 85 = 5516; 4; and
1617 6, 10, or 3.
1620 6.2.2 AttributeValue
1622 The three AttributeValue values are PrintableString values,
1623 so their encodings follow the primitive, definite-length
1624 method:
1626 13 02 55 53 "US"
1628 13 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
1632 13 0b "Test User 1"
1633 54 65 73 74 20 55 73 65 72 20 31
1635 The identifier octets follow the low-tag-number form, since
1636 the tag for PrintableString, 19 (decimal), is between 0 and
1637 30. Bits 8 and 7 have value "0" since PrintableString is in
1638 the universal class. Bit 6 has value "0" since the encoding
1639 is primitive. The length octets follow the short form, and
1640 the contents octets are the ASCII representation of the
1641 attribute value.
1644 6.2.3 AttributeValueAssertion
1646 The three AttributeValueAssertion values are SEQUENCE
1647 values, so their DER encodings follow the constructed,
1648 definite-length method:
1650 30 09 countryName = "US"
1651 06 03 55 04 06
1652 13 02 55 53
1654 30 1b organizationName = "Example Organizaiton"
1655 06 03 55 04 0a
1656 13 14 ... 6f 6e
1658 30 12 commonName = "Test User 1"
1659 06 03 55 04 0b
1660 13 0b ... 20 31
1662 The identifier octets follow the low-tag-number form, since
1663 the tag for SEQUENCE, 16 (decimal), is between 0 and 30.
1664 Bits 8 and 7 have value "0" since SEQUENCE is in the
1665 universal class. Bit 6 has value "1" since the encoding is
1666 constructed. The length octets follow the short form, and
1667 the contents octets are the concatenation of the DER
1668 encodings of the attributeType and attributeValue
1669 components.
1672 6.2.4 RelativeDistinguishedName
1674 The three RelativeDistinguishedName values are SET OF
1675 values, so their DER encodings follow the constructed,
1676 definite-length method:
1678 31 0b
1679 30 09 ... 55 53
1681 31 1d
1682 30 1b ... 6f 6e
1684 31 14
1685 30 12 ... 20 31
1687 The identifier octets follow the low-tag-number form, since
1688 the tag for SET OF, 17 (decimal), is between 0 and 30. Bits
1689 8 and 7 have value "0" since SET OF is in the universal
1690 class Bit 6 has value "1" since the encoding is constructed.
1691 The lengths octets follow the short form, and the contents
1692 octets are the DER encodings of the respective
1693 AttributeValueAssertion values, since there is only one
1694 value in each set.
1697 6.2.5 RDNSequence
1699 The RDNSequence value is a SEQUENCE OF value, so its DER
1700 encoding follows the constructed, definite-length method:
1702 30 42
1703 31 0b ... 55 53
1704 31 1d ... 6f 6e
1705 31 14 ... 20 31
1707 The identifier octets follow the low-tag-number form, since
1708 the tag for SEQUENCE OF, 16 (decimal), is between 0 and 30.
1709 Bits 8 and 7 have value "0" since SEQUENCE OF is in the
1710 universal class. Bit 6 has value "1" since the encoding is
1711 constructed. The lengths octets follow the short form, and
1712 the contents octets are the concatenation of the DER
1713 encodings of the three RelativeDistinguishedName values, in
1714 order of occurrence.
1717 6.2.6 Name
1719 The Name value is a CHOICE value, so its DER encoding is the
1720 same as that of the RDNSequence value:
1722 30 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
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
1741 References
1743 PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption
1744 Standard. Version 1.5, November 1993.
1746 PKCS #3 RSA Laboratories. PKCS #3: Diffie-Hellman Key-
1747 Agreement Standard. Version 1.4, November 1993.
1749 PKCS #5 RSA Laboratories. PKCS #5: Password-Based
1750 Encryption Standard. Version 1.5, November 1993.
1752 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
1753 Syntax Standard. Version 1.5, November 1993.
1755 PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message
1756 Syntax Standard. Version 1.5, November 1993.
1758 PKCS #8 RSA Laboratories. PKCS #8: Private-Key Information
1759 Syntax Standard. Version 1.2, November 1993.
1761 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
1762 Types. Version 1.1, November 1993.
1764 PKCS #10 RSA Laboratories. PKCS #10: Certification Request
1765 Syntax Standard. Version 1.0, November 1993.
1767 X.200 CCITT. Recommendation X.200: Reference Model of
1768 Open Systems Interconnection for CCITT
1769 Applications. 1984.
1771 X.208 CCITT. Recommendation X.208: Specification of
1772 Abstract Syntax Notation One (ASN.1). 1988.
1774 X.209 CCITT. Recommendation X.209: Specification of
1775 Basic Encoding Rules for Abstract Syntax Notation
1776 One (ASN.1). 1988.
1778 X.500 CCITT. Recommendation X.500: The
1779 Directory--Overview of Concepts, Models and
1780 Services. 1988.
1782 X.501 CCITT. Recommendation X.501: The Directory--
1783 Models. 1988.
1785 X.509 CCITT. Recommendation X.509: The Directory--
1786 Authentication Framework. 1988.
1788 X.520 CCITT. Recommendation X.520: The Directory--
1789 Selected Attribute Types. 1988.
1791 [Kal93] Burton S. Kaliski Jr. Some Examples of the PKCS
1792 Standards. RSA Laboratories, November 1993.
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.
1800 Revision history
1803 June 3, 1991 version
1805 The June 3, 1991 version is part of the initial public
1806 release of PKCS. It was published as NIST/OSI Implementors'
1807 Workshop document SEC-SIG-91-17.
1810 November 1, 1993 version
1812 The November 1, 1993 version incorporates several editorial
1813 changes, including the addition of a revision history. It is
1814 updated to be consistent with the following versions of the
1815 PKCS documents:
1817 PKCS #1: RSA Encryption Standard. Version 1.5, November
1818 1993.
1820 PKCS #3: Diffie-Hellman Key-Agreement Standard. Version
1821 1.4, November 1993.
1823 PKCS #5: Password-Based Encryption Standard. Version
1824 1.5, November 1993.
1826 PKCS #6: Extended-Certificate Syntax Standard. Version
1827 1.5, November 1993.
1829 PKCS #7: Cryptographic Message Syntax Standard. Version
1830 1.5, November 1993.
1832 PKCS #8: Private-Key Information Syntax Standard.
1833 Version 1.2, November 1993.
1835 PKCS #9: Selected Attribute Types. Version 1.1,
1836 November 1993.
1838 PKCS #10: Certification Request Syntax Standard.
1839 Version 1.0, November 1993.
1841 The following substantive changes were made:
1843 Section 5: Description of T61String type is added.
1845 Section 6: Names are changed, consistent with other
1846 PKCS examples.
1849 Author's address
1851 Burton S. Kaliski Jr., Ph.D.
1852 Chief Scientist
1853 RSA Laboratories (415) 595-7703
1854 100 Marine Parkway (415) 595-4126 (fax)
1855 Redwood City, CA 94065 USA burt@rsa.com