crypto/heimdal-0.6.3/doc/layman.asc

   1 A Layman's Guide to a Subset of ASN.1, BER, and DER
   2
   3 An RSA Laboratories Technical Note
   4 Burton S. Kaliski Jr.
   5 Revised November 1, 1993
   6
   7
   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>.
  12
  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
  19
  20
  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.
  27
  28
  29 1. Introduction
  30
  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.
  41
  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.
  56
  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.
  71
  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.
  83
  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.
  89
  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.
  93
  94 The following meta-syntax is used for in describing ASN.1
  95 notation:
  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
 116 2. Abstract Syntax Notation One
 117
 118 Abstract Syntax Notation One, abbreviated ASN.1, is a
 119 notation for describing abstract types and values.
 120
 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.
 131
 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:
 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
 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.
 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
 183 ASN.1 types and values are expressed in a flexible,
 184 programming-language-like notation, with the following
 185 special 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
 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.
 203
 204
 205 2.1 Simple types
 206
 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:
 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
 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.
 240
 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).
 247
 248 The string types can be given size constraints limiting the
 249 length of values.
 250
 251
 252 2.2 Structured types
 253
 254 Structured types are those consisting of components. ASN.1
 255 defines four, all of which are relevant to the PKCS
 256 standards:
 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
 268 The structured types can have optional components, possibly
 269 with default values.
 270
 271
 272 2.3 Implicitly and explicitly tagged types
 273
 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.
 279
 280 There are two ways to tag a type: implicitly and explicitly.
 281
 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).
 286
 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).
 293
 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.)
 298
 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).
 307
 308
 309 2.4 Other types
 310
 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.
 316
 317
 318 3. Basic Encoding Rules
 319
 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.)
 325
 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.
 338
 339 In 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
 360 The three methods of encoding are described in the following
 361 sections.
 362
 363
 364 3.1 Primitive, definite-length method
 365
 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:
 370
 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).
 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
 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).
 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
 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.
 414
 415
 416 3.2 Constructed, definite-length method
 417
 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:
 424
 425 Identifier octets. As described in Section 3.1, except that
 426 bit 6 has value "1," indicating that the encoding is
 427 constructed.
 428
 429 Length octets. As described in Section 3.1.
 430
 431 Contents octets. The concatenation of the BER encodings of
 432 the 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
 447 Details for particular types are given in Section 5.
 448
 449
 450 3.3 Constructed, indefinite-length method
 451
 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:
 458
 459 Identifier octets. As described in Section 3.2.
 460
 461 Length octets. One octet, 80.
 462
 463 Contents octets. As described in Section 3.2.
 464
 465 End-of-contents octets. Two octets, 00 00.
 466
 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.
 473
 474
 475 4. Distinguished Encoding Rules
 476
 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.
 483
 484 DER adds the following restrictions to the rules given in
 485 Section 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
 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.
 508
 509
 510 5. Notation and encodings for some types
 511
 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.
 515
 516 The types described are those presented in Section 2. They
 517 are listed alphabetically here.
 518
 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.
 526
 527
 528 5.1 Implicitly tagged types
 529
 530 An implicitly tagged type is a type derived from another
 531 type by changing the tag of the underlying type.
 532
 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.
 537
 538 ASN.1 notation:
 539
 540 [[class] number] IMPLICIT Type
 541
 542 class = UNIVERSAL  |  APPLICATION  |  PRIVATE
 543
 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.
 547
 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.
 554
 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.
 558
 559 Example: PKCS #8's PrivateKeyInfo type has an optional
 560 attributes component with an implicit, context-specific tag:
 561
 562 PrivateKeyInfo ::= SEQUENCE {
 563   version Version,
 564   privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
 565   privateKey PrivateKey,
 566   attributes [0] IMPLICIT Attributes OPTIONAL }
 567
 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.
 571
 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.
 575
 576 Example: The BER encoding of the attributes component of a
 577 PrivateKeyInfo 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
 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.
 591
 592
 593 5.2 Explicitly tagged types
 594
 595 Explicit tagging denotes a type derived from another type by
 596 adding an outer tag to the underlying type.
 597
 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.
 601
 602 ASN.1 notation:
 603
 604 [[class] number] EXPLICIT Type
 605
 606 class = UNIVERSAL  |  APPLICATION  |  PRIVATE
 607
 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.
 611
 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.
 615
 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.
 622
 623 Example 1: PKCS #7's ContentInfo type has an optional
 624 content component with an explicit, context-specific tag:
 625
 626 ContentInfo ::= SEQUENCE {
 627   contentType ContentType,
 628   content
 629     [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
 630
 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.
 634
 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:
 638
 639 Certificate ::= ...
 640   version [0] Version DEFAULT v1988,
 641 ...
 642
 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.
 646
 647 BER encoding. Constructed. Contents octets are the BER
 648 encoding of the underlying value.
 649
 650 Example: the BER encoding of the content component of a
 651 ContentInfo 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
 662 DER encoding. Constructed. Contents octets are the DER
 663 encoding of the underlying value.
 664
 665
 666 5.3 ANY
 667
 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.
 672
 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.
 680
 681 ASN.1 notation:
 682
 683 ANY [DEFINED BY identifier]
 684
 685 where identifier is an optional identifier.
 686
 687 In the ANY form, the actual type is indeterminate.
 688
 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.
 697
 698 Example: X.509's AlgorithmIdentifier type has a component of
 699 type ANY:
 700
 701 AlgorithmIdentifier ::= SEQUENCE {
 702   algorithm OBJECT IDENTIFIER,
 703   parameters ANY DEFINED BY algorithm OPTIONAL }
 704
 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.
 709
 710 BER encoding. Same as the BER encoding of the actual value.
 711
 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.
 716
 717 DER encoding. Same as the DER encoding of the actual value.
 718
 719
 720 5.4 BIT STRING
 721
 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.
 725
 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.
 731
 732 ASN.1 notation:
 733
 734 BIT STRING
 735
 736 Example: X.509's SubjectPublicKeyInfo type has a component
 737 of type BIT STRING:
 738
 739 SubjectPublicKeyInfo ::= SEQUENCE {
 740   algorithm AlgorithmIdentifier,
 741   publicKey BIT STRING }
 742
 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:
 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
 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.
 766
 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:
 772
 773 03 04 06 6e 5d c0                               DER encoding
 774
 775 03 04 06 6e 5d e0                       padded with "100000"
 776
 777 03 81 04 06 6e 5d c0              long form of length octets
 778
 779 23 09        constructed encoding: "0110111001011101" + "11"
 780    03 03 00 6e 5d
 781    03 02 06 c0
 782
 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.
 786
 787 Example: The DER encoding of the BIT STRING value
 788 "011011100101110111" is
 789
 790 03 04 06 6e 5d c0
 791
 792
 793 5.5 CHOICE
 794
 795 The CHOICE type denotes a union of one or more alternatives.
 796
 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.
 800
 801 ASN.1 notation:
 802
 803 CHOICE {
 804   [identifier1] Type1,
 805   ...,
 806   [identifiern] Typen }
 807
 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.
 813
 814 The types must have distinct tags. This requirement is
 815 typically satisfied with explicit or implicit tagging on
 816 some of the alternatives.
 817
 818 Example: PKCS #7's ExtendedCertificateOrCertificate type is
 819 a CHOICE type:
 820
 821 ExtendedCertificateOrCertificate ::= CHOICE {
 822   certificate Certificate, -- X.509
 823   extendedCertificate [0] IMPLICIT ExtendedCertificate
 824 }
 825
 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.
 829
 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.
 834
 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.
 838
 839 DER encoding. Same as the DER encoding of the chosen
 840 alternative.
 841
 842
 843 5.6 IA5String
 844
 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.
 850
 851 The IA5String type is used in PKCS #9's electronic-mail
 852 address, unstructured-name, and unstructured-address
 853 attributes.
 854
 855 ASN.1 notation:
 856
 857 IA5String
 858
 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.
 864
 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:
 869
 870 16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d DER encoding
 871
 872 16 81 0d                       long form of length octets
 873    74 65 73 74 31 40 72 73 61 2e 63 6f 6d
 874
 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
 879
 880 DER encoding. Primitive. Contents octets are as for a
 881 primitive BER encoding.
 882
 883 Example: The DER encoding of the IA5String value
 884 "test1@rsa.com" is
 885
 886 16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
 887
 888
 889 5.7 INTEGER
 890
 891 The INTEGER type denotes an arbitrary integer. INTEGER
 892 values can be positive, negative, or zero, and can have any
 893 magnitude.
 894
 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.
 901
 902 ASN.1 notation:
 903
 904 INTEGER [{ identifier1(value1) ... identifiern(valuen) }]
 905
 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.
 910
 911 Example: X.509's Version type is an INTEGER type with
 912 identified values:
 913
 914 Version ::= INTEGER { v1988(0) }
 915
 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:
 919
 920 Certificate ::= ...
 921   version Version DEFAULT v1988,
 922 ...
 923
 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.
 928
 929 Some example BER encodings (which also happen to be DER
 930 encodings) 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
 943 DER encoding. Primitive. Contents octets are as for a
 944 primitive BER encoding.
 945
 946
 947 5.8 NULL
 948
 949 The NULL type denotes a null value.
 950
 951 The NULL type is used for algorithm parameters in several
 952 places in PKCS.
 953
 954 ASN.1 notation:
 955
 956 NULL
 957
 958 BER encoding. Primitive. Contents octets are empty.
 959
 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:
 963
 964 05 00
 965
 966 05 81 00
 967
 968 DER encoding. Primitive. Contents octets are empty; the DER
 969 encoding of a NULL value is always 05 00.
 970
 971
 972 5.9 OBJECT IDENTIFIER
 973
 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.
 981
 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.
 989
 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.
 998
 999 ASN.1 notation:
1000
1001 OBJECT IDENTIFIER
1002
1003 The ASN.1 notation for values of the OBJECT IDENTIFIER type
1004 is
1005
1006 { [identifier] component1 ... componentn }
1007
1008 componenti = identifieri | identifieri (valuei) | valuei
1009
1010 where identifier, identifier1, ..., identifiern are
1011 identifiers, and value1, ..., valuen are optional integer
1012 values.
1013
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.
1022
1023 Example: The following values both refer to the object
1024 identifier 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
1030 object identifier values are decimal, not hexadecimal.)
1031 Table 4 gives some other object identifier values and their
1032 meanings.
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
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:
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
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:
1066
1067 06 06 2a 86 48 86 f7 0d
1068
1069 DER encoding. Primitive. Contents octets are as for a
1070 primitive BER encoding.
1071
1072
1073 5.10 OCTET STRING
1074
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.
1078
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.
1083
1084 ASN.1 notation:
1085
1086 OCTET STRING [SIZE ({size | size1..size2})]
1087
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.
1094
1095 Example: PKCS #5's PBEParameter type has a component of type
1096 OCTET STRING:
1097
1098 PBEParameter ::= SEQUENCE {
1099   salt OCTET STRING SIZE(8),
1100   iterationCount INTEGER }
1101
1102 Here the size of the salt component is always eight octets.
1103
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.
1109
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:
1114
1115 04 08 01 23 45 67 89 ab cd ef                   DER encoding
1116
1117 04 81 08 01 23 45 67 89 ab cd ef  long form of length octets
1118
1119 24 0c            constructed encoding: 01 ... 67 + 89 ... ef
1120    04 04 01 23 45 67
1121    04 04 89 ab cd ef
1122
1123 DER encoding. Primitive. Contents octets are as for a
1124 primitive BER encoding.
1125
1126 Example: The BER encoding of the OCTET STRING value 01 23 45
1127 67 89 ab cd ef is
1128
1129 04 08 01 23 45 67 89 ab cd ef
1130
1131
1132 5.11 PrintableString
1133
1134 The PrintableString type denotes an arbitrary string of
1135 printable characters from the following character set:
1136
1137                          A, B, ..., Z
1138                          a, b, ..., z
1139                          0, 1, ..., 9
1140                (space) ' ( ) + , - . / : = ?
1141
1142 This type is a string type.
1143
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.
1147
1148 ASN.1 notation:
1149
1150 PrintableString
1151
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.
1157
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:
1162
1163 13 0b 54 65 73 74 20 55 73 65 72 20 31          DER encoding
1164
1165 13 81 0b                          long form of length octets
1166    54 65 73 74 20 55 73 65 72 20 31
1167
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
1171
1172 DER encoding. Primitive. Contents octets are as for a
1173 primitive BER encoding.
1174
1175 Example: The DER encoding of the PrintableString value "Test
1176 User 1" is
1177
1178 13 0b 54 65 73 74 20 55 73 65 72 20 31
1179
1180
1181 5.12 SEQUENCE
1182
1183 The SEQUENCE type denotes an ordered collection of one or
1184 more types.
1185
1186 The SEQUENCE type is used throughout PKCS and related
1187 standards.
1188
1189 ASN.1 notation:
1190
1191 SEQUENCE {
1192   [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
1193   ...,
1194   [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
1195
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.
1202
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.
1208
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.
1214
1215 Example: X.509's Validity type is a SEQUENCE type with two
1216 components:
1217
1218 Validity ::= SEQUENCE {
1219   start UTCTime,
1220   end UTCTime }
1221
1222 Here the identifiers for the components are start and end,
1223 and the types of the components are both UTCTime.
1224
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:
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
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.
1246
1247
1248 5.13 SEQUENCE OF
1249
1250 The SEQUENCE OF type denotes an ordered collection of zero
1251 or more occurrences of a given type.
1252
1253 The SEQUENCE OF type is used in X.501 distinguished names.
1254
1255 ASN.1 notation:
1256
1257 SEQUENCE OF Type
1258
1259 where Type is a type.
1260
1261 Example: X.501's RDNSequence type consists of zero or more
1262 occurences of the RelativeDistinguishedName type, most
1263 significant occurrence first:
1264
1265 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1266
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.
1270
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.
1274
1275
1276 5.14 SET
1277
1278 The SET type denotes an unordered collection of one or more
1279 types.
1280
1281 The SET type is not used in PKCS.
1282
1283 ASN.1 notation:
1284
1285 SET {
1286   [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
1287   ...,
1288   [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
1289
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.
1296
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.
1302
1303 The types must have distinct tags. This requirement is
1304 typically satisfied with explicit or implicit tagging on
1305 some of the components.
1306
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:
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
1323 DER encoding. Constructed. Contents octets are the same as
1324 for 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
1334 5.15 SET OF
1335
1336 The SET OF type denotes an unordered collection of zero or
1337 more occurrences of a given type.
1338
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.
1343
1344 ASN.1 notation:
1345
1346 SET OF Type
1347
1348 where Type is a type.
1349
1350 Example: X.501's RelativeDistinguishedName type consists of
1351 zero or more occurrences of the AttributeValueAssertion
1352 type, where the order is unimportant:
1353
1354 RelativeDistinguishedName ::=
1355   SET OF AttributeValueAssertion
1356
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.
1360
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.
1371
1372
1373 5.16 T61String
1374
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.
1386
1387 The T61String type is used in PKCS #9's unstructured-address
1388 and challenge-password attributes, and in several X.521
1389 attributes.
1390
1391 ASN.1 notation:
1392
1393 T61String
1394
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.
1400
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:
1405
1406 14 0f                                           DER encoding
1407    63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1408
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
1411
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
1416
1417 The eight-bit character c2 is a T.61 prefix that adds an
1418 acute accent (') to the next character.
1419
1420 DER encoding. Primitive. Contents octets are as for a
1421 primitive BER encoding.
1422
1423 Example: The DER encoding of the T61String value "cl'es
1424 publiques" is
1425
1426 14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
1427
1428
1429 5.17 UTCTime
1430
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:
1436
1437 YYMMDDhhmmZ
1438 YYMMDDhhmm+hh'mm'
1439 YYMMDDhhmm-hh'mm'
1440 YYMMDDhhmmssZ
1441 YYMMDDhhmmss+hh'mm'
1442 YYMMDDhhmmss-hh'mm'
1443
1444 where:
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
1468 This type is a string type.
1469
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.
1473
1474 ASN.1 notation:
1475
1476 UTCTime
1477
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.)
1486
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:
1491
1492 "910506164540-0700"
1493
1494 "910506234540Z"
1495
1496 These values have the following BER encodings, among others:
1497
1498 17 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a
1499
1500 17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30
1501       30
1502
1503 DER encoding. Primitive. Contents octets are as for a
1504 primitive BER encoding.
1505
1506
1507 6. An example
1508
1509 This section gives an example of ASN.1 notation and DER
1510 encoding: the X.501 type Name.
1511
1512
1513 6.1 Abstract notation
1514
1515 This section gives the ASN.1 notation for the X.501 type
1516 Name.
1517
1518 Name ::= CHOICE {
1519   RDNSequence }
1520
1521 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1522
1523 RelativeDistinguishedName ::=
1524   SET OF AttributeValueAssertion
1525
1526 AttributeValueAssertion ::= SEQUENCE {
1527    AttributeType,
1528    AttributeValue }
1529
1530 AttributeType ::= OBJECT IDENTIFIER
1531
1532 AttributeValue ::= ANY
1533
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.)
1538
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.
1543
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.
1549
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.
1555
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.
1560
1561
1562 6.2 DER encoding
1563
1564 This section gives an example of a DER encoding of a value
1565 of type Name, working from the bottom up.
1566
1567 The 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
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.
1584
1585 The countryName, organizationName, and commonUnitName are
1586 attribute types defined in X.520 as:
1587
1588 attributeType OBJECT IDENTIFIER ::=
1589   { joint-iso-ccitt(2) ds(5) 4 }
1590
1591 countryName OBJECT IDENTIFIER ::= { attributeType 6 }
1592 organizationName OBJECT IDENTIFIER ::=
1593   { attributeType 10 }
1594 commonUnitName OBJECT IDENTIFIER ::=
1595   { attributeType 3 }
1596
1597
1598 6.2.1 AttributeType
1599
1600 The three AttributeType values are OCTET STRING values, so
1601 their DER encoding follows the primitive, definite-length
1602 method:
1603
1604 06 03 55 04 06                                   countryName
1605
1606 06 03 55 04 0a                              organizationName
1607
1608 06 03 55 04 03                                    commonName
1609
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.
1618
1619
1620 6.2.2 AttributeValue
1621
1622 The three AttributeValue values are PrintableString values,
1623 so their encodings follow the primitive, definite-length
1624 method:
1625
1626 13 02 55 53                                             "US"
1627
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
1631
1632 13 0b                                          "Test User 1"
1633    54 65 73 74 20 55 73 65 72 20 31
1634
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.
1642
1643
1644 6.2.3 AttributeValueAssertion
1645
1646 The three AttributeValueAssertion values are SEQUENCE
1647 values, so their DER encodings follow the constructed,
1648 definite-length method:
1649
1650 30 09                                     countryName = "US"
1651    06 03 55 04 06
1652    13 02 55 53
1653
1654 30 1b              organizationName = "Example Organizaiton"
1655    06 03 55 04 0a
1656    13 14 ... 6f 6e
1657
1658 30 12                             commonName = "Test User 1"
1659    06 03 55 04 0b
1660    13 0b ... 20 31
1661
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.
1670
1671
1672 6.2.4 RelativeDistinguishedName
1673
1674 The three RelativeDistinguishedName values are SET OF
1675 values, so their DER encodings follow the constructed,
1676 definite-length method:
1677
1678 31 0b
1679    30 09 ... 55 53
1680
1681 31 1d
1682    30 1b ... 6f 6e
1683
1684 31 14
1685    30 12 ... 20 31
1686
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.
1695
1696
1697 6.2.5 RDNSequence
1698
1699 The RDNSequence value is a SEQUENCE OF value, so its DER
1700 encoding follows the constructed, definite-length method:
1701
1702 30 42
1703    31 0b ... 55 53
1704    31 1d ... 6f 6e
1705    31 14 ... 20 31
1706
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.
1715
1716
1717 6.2.6 Name
1718
1719 The Name value is a CHOICE value, so its DER encoding is the
1720 same as that of the RDNSequence value:
1721
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
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
1741 References
1742
1743 PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption
1744           Standard. Version 1.5, November 1993.
1745
1746 PKCS #3   RSA Laboratories. PKCS #3: Diffie-Hellman Key-
1747           Agreement Standard. Version 1.4, November 1993.
1748
1749 PKCS #5   RSA Laboratories. PKCS #5: Password-Based
1750           Encryption Standard. Version 1.5, November 1993.
1751
1752 PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
1753           Syntax Standard. Version 1.5, November 1993.
1754
1755 PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
1756           Syntax Standard. Version 1.5, November 1993.
1757
1758 PKCS #8   RSA Laboratories. PKCS #8: Private-Key Information
1759           Syntax Standard. Version 1.2, November 1993.
1760
1761 PKCS #9   RSA Laboratories. PKCS #9: Selected Attribute
1762           Types. Version 1.1, November 1993.
1763
1764 PKCS #10  RSA Laboratories. PKCS #10: Certification Request
1765           Syntax Standard. Version 1.0, November 1993.
1766
1767 X.200     CCITT. Recommendation X.200: Reference Model of
1768           Open Systems Interconnection for CCITT
1769           Applications. 1984.
1770
1771 X.208     CCITT. Recommendation X.208: Specification of
1772           Abstract Syntax Notation One (ASN.1). 1988.
1773
1774 X.209     CCITT. Recommendation X.209: Specification of
1775           Basic Encoding Rules for Abstract Syntax Notation
1776           One (ASN.1). 1988.
1777
1778 X.500     CCITT. Recommendation X.500: The
1779           Directory--Overview of Concepts, Models and
1780           Services. 1988.
1781
1782 X.501     CCITT. Recommendation X.501: The Directory--
1783           Models. 1988.
1784
1785 X.509     CCITT. Recommendation X.509: The Directory--
1786           Authentication Framework. 1988.
1787
1788 X.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
1800 Revision history
1801
1802
1803 June 3, 1991 version
1804
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.
1808
1809
1810 November 1, 1993 version
1811
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:
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
1841 The 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
1849 Author's address
1850
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