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