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