PageRenderTime 63ms CodeModel.GetById 15ms app.highlight 23ms RepoModel.GetById 1ms app.codeStats 1ms

/crypto/heimdal/doc/layman.asc

https://bitbucket.org/freebsd/freebsd-head/
Unknown | 1855 lines | 1342 code | 513 blank | 0 comment | 0 complexity | dbe47a235c7b1da117037a3c7882669b MD5 | raw file

Large files files are truncated, but you can click here to view the full file

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

Large files files are truncated, but you can click here to view the full file