+++ /dev/null
-A Layman's Guide to a Subset of ASN.1, BER, and DER
-
-An RSA Laboratories Technical Note
-Burton S. Kaliski Jr.
-Revised November 1, 1993
-
-
-Supersedes June 3, 1991 version, which was also published as
-NIST/OSI Implementors' Workshop document SEC-SIG-91-17.
-PKCS documents are available by electronic mail to
-<pkcs@rsa.com>.
-
-Copyright (C) 1991-1993 RSA Laboratories, a division of RSA
-Data Security, Inc. License to copy this document is granted
-provided that it is identified as "RSA Data Security, Inc.
-Public-Key Cryptography Standards (PKCS)" in all material
-mentioning or referencing this document.
-003-903015-110-000-000
-
-
-Abstract. This note gives a layman's introduction to a
-subset of OSI's Abstract Syntax Notation One (ASN.1), Basic
-Encoding Rules (BER), and Distinguished Encoding Rules
-(DER). The particular purpose of this note is to provide
-background material sufficient for understanding and
-implementing the PKCS family of standards.
-
-
-1. Introduction
-
-It is a generally accepted design principle that abstraction
-is a key to managing software development. With abstraction,
-a designer can specify a part of a system without concern
-for how the part is actually implemented or represented.
-Such a practice leaves the implementation open; it
-simplifies the specification; and it makes it possible to
-state "axioms" about the part that can be proved when the
-part is implemented, and assumed when the part is employed
-in another, higher-level part. Abstraction is the hallmark
-of most modern software specifications.
-
-One of the most complex systems today, and one that also
-involves a great deal of abstraction, is Open Systems
-Interconnection (OSI, described in X.200). OSI is an
-internationally standardized architecture that governs the
-interconnection of computers from the physical layer up to
-the user application layer. Objects at higher layers are
-defined abstractly and intended to be implemented with
-objects at lower layers. For instance, a service at one
-layer may require transfer of certain abstract objects
-between computers; a lower layer may provide transfer
-services for strings of ones and zeroes, using encoding
-rules to transform the abstract objects into such strings.
-OSI is called an open system because it supports many
-different implementations of the services at each layer.
-
-OSI's method of specifying abstract objects is called ASN.1
-(Abstract Syntax Notation One, defined in X.208), and one
-set of rules for representing such objects as strings of
-ones and zeros is called the BER (Basic Encoding Rules,
-defined in X.209). ASN.1 is a flexible notation that allows
-one to define a variety data types, from simple types such
-as integers and bit strings to structured types such as sets
-and sequences, as well as complex types defined in terms of
-others. BER describes how to represent or encode values of
-each ASN.1 type as a string of eight-bit octets. There is
-generally more than one way to BER-encode a given value.
-Another set of rules, called the Distinguished Encoding
-Rules (DER), which is a subset of BER, gives a unique
-encoding to each ASN.1 value.
-
-The purpose of this note is to describe a subset of ASN.1,
-BER and DER sufficient to understand and implement one OSI-
-based application, RSA Data Security, Inc.'s Public-Key
-Cryptography Standards. The features described include an
-overview of ASN.1, BER, and DER and an abridged list of
-ASN.1 types and their BER and DER encodings. Sections 2-4
-give an overview of ASN.1, BER, and DER, in that order.
-Section 5 lists some ASN.1 types, giving their notation,
-specific encoding rules, examples, and comments about their
-application to PKCS. Section 6 concludes with an example,
-X.500 distinguished names.
-
-Advanced features of ASN.1, such as macros, are not
-described in this note, as they are not needed to implement
-PKCS. For information on the other features, and for more
-detail generally, the reader is referred to CCITT
-Recommendations X.208 and X.209, which define ASN.1 and BER.
-
-Terminology and notation. In this note, an octet is an eight-
-bit unsigned integer. Bit 8 of the octet is the most
-significant and bit 1 is the least significant.
-
-The following meta-syntax is used for in describing ASN.1
-notation:
-
- BIT monospace denotes literal characters in the type
- and value notation; in examples, it generally
- denotes an octet value in hexadecimal
-
- n1 bold italics denotes a variable
-
- [] bold square brackets indicate that a term is
- optional
-
- {} bold braces group related terms
-
- | bold vertical bar delimits alternatives with a
- group
-
- ... bold ellipsis indicates repeated occurrences
-
- = bold equals sign expresses terms as subterms
-
-
-2. Abstract Syntax Notation One
-
-Abstract Syntax Notation One, abbreviated ASN.1, is a
-notation for describing abstract types and values.
-
-In ASN.1, a type is a set of values. For some types, there
-are a finite number of values, and for other types there are
-an infinite number. A value of a given ASN.1 type is an
-element of the type's set. ASN.1 has four kinds of type:
-simple types, which are "atomic" and have no components;
-structured types, which have components; tagged types, which
-are derived from other types; and other types, which include
-the CHOICE type and the ANY type. Types and values can be
-given names with the ASN.1 assignment operator (::=) , and
-those names can be used in defining other types and values.
-
-Every ASN.1 type other than CHOICE and ANY has a tag, which
-consists of a class and a nonnegative tag number. ASN.1
-types are abstractly the same if and only if their tag
-numbers are the same. In other words, the name of an ASN.1
-type does not affect its abstract meaning, only the tag
-does. There are four classes of tag:
-
- Universal, for types whose meaning is the same in all
- applications; these types are only defined in
- X.208.
-
- Application, for types whose meaning is specific to an
- application, such as X.500 directory services;
- types in two different applications may have the
- same application-specific tag and different
- meanings.
-
- Private, for types whose meaning is specific to a given
- enterprise.
-
- Context-specific, for types whose meaning is specific
- to a given structured type; context-specific tags
- are used to distinguish between component types
- with the same underlying tag within the context of
- a given structured type, and component types in
- two different structured types may have the same
- tag and different meanings.
-
-The types with universal tags are defined in X.208, which
-also gives the types' universal tag numbers. Types with
-other tags are defined in many places, and are always
-obtained by implicit or explicit tagging (see Section 2.3).
-Table 1 lists some ASN.1 types and their universal-class
-tags.
-
- Type Tag number Tag number
- (decimal) (hexadecimal)
- INTEGER 2 02
- BIT STRING 3 03
- OCTET STRING 4 04
- NULL 5 05
- OBJECT IDENTIFIER 6 06
- SEQUENCE and SEQUENCE OF 16 10
- SET and SET OF 17 11
- PrintableString 19 13
- T61String 20 14
- IA5String 22 16
- UTCTime 23 17
-
- Table 1. Some types and their universal-class tags.
-
-ASN.1 types and values are expressed in a flexible,
-programming-language-like notation, with the following
-special rules:
-
- o Layout is not significant; multiple spaces and
- line breaks can be considered as a single space.
-
- o Comments are delimited by pairs of hyphens (--),
- or a pair of hyphens and a line break.
-
- o Identifiers (names of values and fields) and type
- references (names of types) consist of upper- and
- lower-case letters, digits, hyphens, and spaces;
- identifiers begin with lower-case letters; type
- references begin with upper-case letters.
-
-The following four subsections give an overview of simple
-types, structured types, implicitly and explicitly tagged
-types, and other types. Section 5 describes specific types
-in more detail.
-
-
-2.1 Simple types
-
-Simple types are those not consisting of components; they
-are the "atomic" types. ASN.1 defines several; the types
-that are relevant to the PKCS standards are the following:
-
- BIT STRING, an arbitrary string of bits (ones and
- zeroes).
-
- IA5String, an arbitrary string of IA5 (ASCII)
- characters.
-
- INTEGER, an arbitrary integer.
-
- NULL, a null value.
-
- OBJECT IDENTIFIER, an object identifier, which is a
- sequence of integer components that identify an
- object such as an algorithm or attribute type.
-
- OCTET STRING, an arbitrary string of octets (eight-bit
- values).
-
- PrintableString, an arbitrary string of printable
- characters.
-
- T61String, an arbitrary string of T.61 (eight-bit)
- characters.
-
- UTCTime, a "coordinated universal time" or Greenwich
- Mean Time (GMT) value.
-
-Simple types fall into two categories: string types and non-
-string types. BIT STRING, IA5String, OCTET STRING,
-PrintableString, T61String, and UTCTime are string types.
-
-String types can be viewed, for the purposes of encoding, as
-consisting of components, where the components are
-substrings. This view allows one to encode a value whose
-length is not known in advance (e.g., an octet string value
-input from a file stream) with a constructed, indefinite-
-length encoding (see Section 3).
-
-The string types can be given size constraints limiting the
-length of values.
-
-
-2.2 Structured types
-
-Structured types are those consisting of components. ASN.1
-defines four, all of which are relevant to the PKCS
-standards:
-
- SEQUENCE, an ordered collection of one or more types.
-
- SEQUENCE OF, an ordered collection of zero or more
- occurrences of a given type.
-
- SET, an unordered collection of one or more types.
-
- SET OF, an unordered collection of zero or more
- occurrences of a given type.
-
-The structured types can have optional components, possibly
-with default values.
-
-
-2.3 Implicitly and explicitly tagged types
-
-Tagging is useful to distinguish types within an
-application; it is also commonly used to distinguish
-component types within a structured type. For instance,
-optional components of a SET or SEQUENCE type are typically
-given distinct context-specific tags to avoid ambiguity.
-
-There are two ways to tag a type: implicitly and explicitly.
-
-Implicitly tagged types are derived from other types by
-changing the tag of the underlying type. Implicit tagging is
-denoted by the ASN.1 keywords [class number] IMPLICIT (see
-Section 5.1).
-
-Explicitly tagged types are derived from other types by
-adding an outer tag to the underlying type. In effect,
-explicitly tagged types are structured types consisting of
-one component, the underlying type. Explicit tagging is
-denoted by the ASN.1 keywords [class number] EXPLICIT (see
-Section 5.2).
-
-The keyword [class number] alone is the same as explicit
-tagging, except when the "module" in which the ASN.1 type is
-defined has implicit tagging by default. ("Modules" are
-among the advanced features not described in this note.)
-
-For purposes of encoding, an implicitly tagged type is
-considered the same as the underlying type, except that the
-tag is different. An explicitly tagged type is considered
-like a structured type with one component, the underlying
-type. Implicit tags result in shorter encodings, but
-explicit tags may be necessary to avoid ambiguity if the tag
-of the underlying type is indeterminate (e.g., the
-underlying type is CHOICE or ANY).
-
-
-2.4 Other types
-
-Other types in ASN.1 include the CHOICE and ANY types. The
-CHOICE type denotes a union of one or more alternatives; the
-ANY type denotes an arbitrary value of an arbitrary type,
-where the arbitrary type is possibly defined in the
-registration of an object identifier or integer value.
-
-
-3. Basic Encoding Rules
-
-The Basic Encoding Rules for ASN.1, abbreviated BER, give
-one or more ways to represent any ASN.1 value as an octet
-string. (There are certainly other ways to represent ASN.1
-values, but BER is the standard for interchanging such
-values in OSI.)
-
-There are three methods to encode an ASN.1 value under BER,
-the choice of which depends on the type of value and whether
-the length of the value is known. The three methods are
-primitive, definite-length encoding; constructed, definite-
-length encoding; and constructed, indefinite-length
-encoding. Simple non-string types employ the primitive,
-definite-length method; structured types employ either of
-the constructed methods; and simple string types employ any
-of the methods, depending on whether the length of the value
-is known. Types derived by implicit tagging employ the
-method of the underlying type and types derived by explicit
-tagging employ the constructed methods.
-
-In each method, the BER encoding has three or four parts:
-
- Identifier octets. These identify the class and tag
- number of the ASN.1 value, and indicate whether
- the method is primitive or constructed.
-
- Length octets. For the definite-length methods, these
- give the number of contents octets. For the
- constructed, indefinite-length method, these
- indicate that the length is indefinite.
-
- Contents octets. For the primitive, definite-length
- method, these give a concrete representation of
- the value. For the constructed methods, these
- give the concatenation of the BER encodings of the
- components of the value.
-
- End-of-contents octets. For the constructed, indefinite-
- length method, these denote the end of the
- contents. For the other methods, these are absent.
-
-The three methods of encoding are described in the following
-sections.
-
-
-3.1 Primitive, definite-length method
-
-This method applies to simple types and types derived from
-simple types by implicit tagging. It requires that the
-length of the value be known in advance. The parts of the
-BER encoding are as follows:
-
-Identifier octets. There are two forms: low tag number (for
-tag numbers between 0 and 30) and high tag number (for tag
-numbers 31 and greater).
-
- Low-tag-number form. One octet. Bits 8 and 7 specify
- the class (see Table 2), bit 6 has value "0,"
- indicating that the encoding is primitive, and
- bits 5-1 give the tag number.
-
- Class Bit Bit
- 8 7
- universal 0 0
- application 0 1
- context-specific 1 0
- private 1 1
-
- Table 2. Class encoding in identifier octets.
-
- High-tag-number form. Two or more octets. First octet
- is as in low-tag-number form, except that bits 5-1
- all have value "1." Second and following octets
- give the tag number, base 128, most significant
- digit first, with as few digits as possible, and
- with the bit 8 of each octet except the last set
- to "1."
-
-Length octets. There are two forms: short (for lengths
-between 0 and 127), and long definite (for lengths between 0
-and 21008-1).
-
- Short form. One octet. Bit 8 has value "0" and bits 7-1
- give the length.
-
- Long form. Two to 127 octets. Bit 8 of first octet has
- value "1" and bits 7-1 give the number of
- additional length octets. Second and following
- octets give the length, base 256, most significant
- digit first.
-
-Contents octets. These give a concrete representation of the
-value (or the value of the underlying type, if the type is
-derived by implicit tagging). Details for particular types
-are given in Section 5.
-
-
-3.2 Constructed, definite-length method
-
-This method applies to simple string types, structured
-types, types derived simple string types and structured
-types by implicit tagging, and types derived from anything
-by explicit tagging. It requires that the length of the
-value be known in advance. The parts of the BER encoding are
-as follows:
-
-Identifier octets. As described in Section 3.1, except that
-bit 6 has value "1," indicating that the encoding is
-constructed.
-
-Length octets. As described in Section 3.1.
-
-Contents octets. The concatenation of the BER encodings of
-the components of the value:
-
- o For simple string types and types derived from
- them by implicit tagging, the concatenation of the
- BER encodings of consecutive substrings of the
- value (underlying value for implicit tagging).
-
- o For structured types and types derived from them
- by implicit tagging, the concatenation of the BER
- encodings of components of the value (underlying
- value for implicit tagging).
-
- o For types derived from anything by explicit
- tagging, the BER encoding of the underlying value.
-
-Details for particular types are given in Section 5.
-
-
-3.3 Constructed, indefinite-length method
-
-This method applies to simple string types, structured
-types, types derived simple string types and structured
-types by implicit tagging, and types derived from anything
-by explicit tagging. It does not require that the length of
-the value be known in advance. The parts of the BER encoding
-are as follows:
-
-Identifier octets. As described in Section 3.2.
-
-Length octets. One octet, 80.
-
-Contents octets. As described in Section 3.2.
-
-End-of-contents octets. Two octets, 00 00.
-
-Since the end-of-contents octets appear where an ordinary
-BER encoding might be expected (e.g., in the contents octets
-of a sequence value), the 00 and 00 appear as identifier and
-length octets, respectively. Thus the end-of-contents octets
-is really the primitive, definite-length encoding of a value
-with universal class, tag number 0, and length 0.
-
-
-4. Distinguished Encoding Rules
-
-The Distinguished Encoding Rules for ASN.1, abbreviated DER,
-are a subset of BER, and give exactly one way to represent
-any ASN.1 value as an octet string. DER is intended for
-applications in which a unique octet string encoding is
-needed, as is the case when a digital signature is computed
-on an ASN.1 value. DER is defined in Section 8.7 of X.509.
-
-DER adds the following restrictions to the rules given in
-Section 3:
-
- 1. When the length is between 0 and 127, the short
- form of length must be used
-
- 2. When the length is 128 or greater, the long form
- of length must be used, and the length must be
- encoded in the minimum number of octets.
-
- 3. For simple string types and implicitly tagged
- types derived from simple string types, the
- primitive, definite-length method must be
- employed.
-
- 4. For structured types, implicitly tagged types
- derived from structured types, and explicitly
- tagged types derived from anything, the
- constructed, definite-length method must be
- employed.
-
-Other restrictions are defined for particular types (such as
-BIT STRING, SEQUENCE, SET, and SET OF), and can be found in
-Section 5.
-
-
-5. Notation and encodings for some types
-
-This section gives the notation for some ASN.1 types and
-describes how to encode values of those types under both BER
-and DER.
-
-The types described are those presented in Section 2. They
-are listed alphabetically here.
-
-Each description includes ASN.1 notation, BER encoding, and
-DER encoding. The focus of the encodings is primarily on the
-contents octets; the tag and length octets follow Sections 3
-and 4. The descriptions also explain where each type is used
-in PKCS and related standards. ASN.1 notation is generally
-only for types, although for the type OBJECT IDENTIFIER,
-value notation is given as well.
-
-
-5.1 Implicitly tagged types
-
-An implicitly tagged type is a type derived from another
-type by changing the tag of the underlying type.
-
-Implicit tagging is used for optional SEQUENCE components
-with underlying type other than ANY throughout PKCS, and for
-the extendedCertificate alternative of PKCS #7's
-ExtendedCertificateOrCertificate type.
-
-ASN.1 notation:
-
-[[class] number] IMPLICIT Type
-
-class = UNIVERSAL | APPLICATION | PRIVATE
-
-where Type is a type, class is an optional class name, and
-number is the tag number within the class, a nonnegative
-integer.
-
-In ASN.1 "modules" whose default tagging method is implicit
-tagging, the notation [[class] number] Type is also
-acceptable, and the keyword IMPLICIT is implied. (See
-Section 2.3.) For definitions stated outside a module, the
-explicit inclusion of the keyword IMPLICIT is preferable to
-prevent ambiguity.
-
-If the class name is absent, then the tag is context-
-specific. Context-specific tags can only appear in a
-component of a structured or CHOICE type.
-
-Example: PKCS #8's PrivateKeyInfo type has an optional
-attributes component with an implicit, context-specific tag:
-
-PrivateKeyInfo ::= SEQUENCE {
- version Version,
- privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
- privateKey PrivateKey,
- attributes [0] IMPLICIT Attributes OPTIONAL }
-
-Here the underlying type is Attributes, the class is absent
-(i.e., context-specific), and the tag number within the
-class is 0.
-
-BER encoding. Primitive or constructed, depending on the
-underlying type. Contents octets are as for the BER encoding
-of the underlying value.
-
-Example: The BER encoding of the attributes component of a
-PrivateKeyInfo value is as follows:
-
- o the identifier octets are 80 if the underlying
- Attributes value has a primitive BER encoding and
- a0 if the underlying Attributes value has a
- constructed BER encoding
-
- o the length and contents octets are the same as the
- length and contents octets of the BER encoding of
- the underlying Attributes value
-
-DER encoding. Primitive or constructed, depending on the
-underlying type. Contents octets are as for the DER encoding
-of the underlying value.
-
-
-5.2 Explicitly tagged types
-
-Explicit tagging denotes a type derived from another type by
-adding an outer tag to the underlying type.
-
-Explicit tagging is used for optional SEQUENCE components
-with underlying type ANY throughout PKCS, and for the
-version component of X.509's Certificate type.
-
-ASN.1 notation:
-
-[[class] number] EXPLICIT Type
-
-class = UNIVERSAL | APPLICATION | PRIVATE
-
-where Type is a type, class is an optional class name, and
-number is the tag number within the class, a nonnegative
-integer.
-
-If the class name is absent, then the tag is context-
-specific. Context-specific tags can only appear in a
-component of a SEQUENCE, SET or CHOICE type.
-
-In ASN.1 "modules" whose default tagging method is explicit
-tagging, the notation [[class] number] Type is also
-acceptable, and the keyword EXPLICIT is implied. (See
-Section 2.3.) For definitions stated outside a module, the
-explicit inclusion of the keyword EXPLICIT is preferable to
-prevent ambiguity.
-
-Example 1: PKCS #7's ContentInfo type has an optional
-content component with an explicit, context-specific tag:
-
-ContentInfo ::= SEQUENCE {
- contentType ContentType,
- content
- [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
-
-Here the underlying type is ANY DEFINED BY contentType, the
-class is absent (i.e., context-specific), and the tag number
-within the class is 0.
-
-Example 2: X.509's Certificate type has a version component
-with an explicit, context-specific tag, where the EXPLICIT
-keyword is omitted:
-
-Certificate ::= ...
- version [0] Version DEFAULT v1988,
-...
-
-The tag is explicit because the default tagging method for
-the ASN.1 "module" in X.509 that defines the Certificate
-type is explicit tagging.
-
-BER encoding. Constructed. Contents octets are the BER
-encoding of the underlying value.
-
-Example: the BER encoding of the content component of a
-ContentInfo value is as follows:
-
- o identifier octets are a0
-
- o length octets represent the length of the BER
- encoding of the underlying ANY DEFINED BY
- contentType value
-
- o contents octets are the BER encoding of the
- underlying ANY DEFINED BY contentType value
-
-DER encoding. Constructed. Contents octets are the DER
-encoding of the underlying value.
-
-
-5.3 ANY
-
-The ANY type denotes an arbitrary value of an arbitrary
-type, where the arbitrary type is possibly defined in the
-registration of an object identifier or associated with an
-integer index.
-
-The ANY type is used for content of a particular content
-type in PKCS #7's ContentInfo type, for parameters of a
-particular algorithm in X.509's AlgorithmIdentifier type,
-and for attribute values in X.501's Attribute and
-AttributeValueAssertion types. The Attribute type is used by
-PKCS #6, #7, #8, #9 and #10, and the AttributeValueAssertion
-type is used in X.501 distinguished names.
-
-ASN.1 notation:
-
-ANY [DEFINED BY identifier]
-
-where identifier is an optional identifier.
-
-In the ANY form, the actual type is indeterminate.
-
-The ANY DEFINED BY identifier form can only appear in a
-component of a SEQUENCE or SET type for which identifier
-identifies some other component, and that other component
-has type INTEGER or OBJECT IDENTIFIER (or a type derived
-from either of those by tagging). In that form, the actual
-type is determined by the value of the other component,
-either in the registration of the object identifier value,
-or in a table of integer values.
-
-Example: X.509's AlgorithmIdentifier type has a component of
-type ANY:
-
-AlgorithmIdentifier ::= SEQUENCE {
- algorithm OBJECT IDENTIFIER,
- parameters ANY DEFINED BY algorithm OPTIONAL }
-
-Here the actual type of the parameter component depends on
-the value of the algorithm component. The actual type would
-be defined in the registration of object identifier values
-for the algorithm component.
-
-BER encoding. Same as the BER encoding of the actual value.
-
-Example: The BER encoding of the value of the parameter
-component is the BER encoding of the value of the actual
-type as defined in the registration of object identifier
-values for the algorithm component.
-
-DER encoding. Same as the DER encoding of the actual value.
-
-
-5.4 BIT STRING
-
-The BIT STRING type denotes an arbitrary string of bits
-(ones and zeroes). A BIT STRING value can have any length,
-including zero. This type is a string type.
-
-The BIT STRING type is used for digital signatures on
-extended certificates in PKCS #6's ExtendedCertificate type,
-for digital signatures on certificates in X.509's
-Certificate type, and for public keys in certificates in
-X.509's SubjectPublicKeyInfo type.
-
-ASN.1 notation:
-
-BIT STRING
-
-Example: X.509's SubjectPublicKeyInfo type has a component
-of type BIT STRING:
-
-SubjectPublicKeyInfo ::= SEQUENCE {
- algorithm AlgorithmIdentifier,
- publicKey BIT STRING }
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the first contents octet gives the number of bits
-by which the length of the bit string is less than the next
-multiple of eight (this is called the "number of unused
-bits"). The second and following contents octets give the
-value of the bit string, converted to an octet string. The
-conversion process is as follows:
-
- 1. The bit string is padded after the last bit with
- zero to seven bits of any value to make the length
- of the bit string a multiple of eight. If the
- length of the bit string is a multiple of eight
- already, no padding is done.
-
- 2. The padded bit string is divided into octets. The
- first eight bits of the padded bit string become
- the first octet, bit 8 to bit 1, and so on through
- the last eight bits of the padded bit string.
-
-In a constructed encoding, the contents octets give the
-concatenation of the BER encodings of consecutive substrings
-of the bit string, where each substring except the last has
-a length that is a multiple of eight bits.
-
-Example: The BER encoding of the BIT STRING value
-"011011100101110111" can be any of the following, among
-others, depending on the choice of padding bits, the form of
-length octets, and whether the encoding is primitive or
-constructed:
-
-03 04 06 6e 5d c0 DER encoding
-
-03 04 06 6e 5d e0 padded with "100000"
-
-03 81 04 06 6e 5d c0 long form of length octets
-
-23 09 constructed encoding: "0110111001011101" + "11"
- 03 03 00 6e 5d
- 03 02 06 c0
-
-DER encoding. Primitive. The contents octects are as for a
-primitive BER encoding, except that the bit string is padded
-with zero-valued bits.
-
-Example: The DER encoding of the BIT STRING value
-"011011100101110111" is
-
-03 04 06 6e 5d c0
-
-
-5.5 CHOICE
-
-The CHOICE type denotes a union of one or more alternatives.
-
-The CHOICE type is used to represent the union of an
-extended certificate and an X.509 certificate in PKCS #7's
-ExtendedCertificateOrCertificate type.
-
-ASN.1 notation:
-
-CHOICE {
- [identifier1] Type1,
- ...,
- [identifiern] Typen }
-
-where identifier1 , ..., identifiern are optional, distinct
-identifiers for the alternatives, and Type1, ..., Typen are
-the types of the alternatives. The identifiers are primarily
-for documentation; they do not affect values of the type or
-their encodings in any way.
-
-The types must have distinct tags. This requirement is
-typically satisfied with explicit or implicit tagging on
-some of the alternatives.
-
-Example: PKCS #7's ExtendedCertificateOrCertificate type is
-a CHOICE type:
-
-ExtendedCertificateOrCertificate ::= CHOICE {
- certificate Certificate, -- X.509
- extendedCertificate [0] IMPLICIT ExtendedCertificate
-}
-
-Here the identifiers for the alternatives are certificate
-and extendedCertificate, and the types of the alternatives
-are Certificate and [0] IMPLICIT ExtendedCertificate.
-
-BER encoding. Same as the BER encoding of the chosen
-alternative. The fact that the alternatives have distinct
-tags makes it possible to distinguish between their BER
-encodings.
-
-Example: The identifier octets for the BER encoding are 30
-if the chosen alternative is certificate, and a0 if the
-chosen alternative is extendedCertificate.
-
-DER encoding. Same as the DER encoding of the chosen
-alternative.
-
-
-5.6 IA5String
-
-The IA5String type denotes an arbtrary string of IA5
-characters. IA5 stands for International Alphabet 5, which
-is the same as ASCII. The character set includes non-
-printing control characters. An IA5String value can have any
-length, including zero. This type is a string type.
-
-The IA5String type is used in PKCS #9's electronic-mail
-address, unstructured-name, and unstructured-address
-attributes.
-
-ASN.1 notation:
-
-IA5String
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the IA5
-string, encoded in ASCII. In a constructed encoding, the
-contents octets give the concatenation of the BER encodings
-of consecutive substrings of the IA5 string.
-
-Example: The BER encoding of the IA5String value
-"test1@rsa.com" can be any of the following, among others,
-depending on the form of length octets and whether the
-encoding is primitive or constructed:
-
-16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d DER encoding
-
-16 81 0d long form of length octets
- 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
-
-36 13 constructed encoding: "test1" + "@" + "rsa.com"
- 16 05 74 65 73 74 31
- 16 01 40
- 16 07 72 73 61 2e 63 6f 6d
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The DER encoding of the IA5String value
-"test1@rsa.com" is
-
-16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
-
-
-5.7 INTEGER
-
-The INTEGER type denotes an arbitrary integer. INTEGER
-values can be positive, negative, or zero, and can have any
-magnitude.
-
-The INTEGER type is used for version numbers throughout
-PKCS, cryptographic values such as modulus, exponent, and
-primes in PKCS #1's RSAPublicKey and RSAPrivateKey types and
-PKCS #3's DHParameter type, a message-digest iteration count
-in PKCS #5's PBEParameter type, and version numbers and
-serial numbers in X.509's Certificate type.
-
-ASN.1 notation:
-
-INTEGER [{ identifier1(value1) ... identifiern(valuen) }]
-
-where identifier1, ..., identifiern are optional distinct
-identifiers and value1, ..., valuen are optional integer
-values. The identifiers, when present, are associated with
-values of the type.
-
-Example: X.509's Version type is an INTEGER type with
-identified values:
-
-Version ::= INTEGER { v1988(0) }
-
-The identifier v1988 is associated with the value 0. X.509's
-Certificate type uses the identifier v1988 to give a default
-value of 0 for the version component:
-
-Certificate ::= ...
- version Version DEFAULT v1988,
-...
-
-BER encoding. Primitive. Contents octets give the value of
-the integer, base 256, in two's complement form, most
-significant digit first, with the minimum number of octets.
-The value 0 is encoded as a single 00 octet.
-
-Some example BER encodings (which also happen to be DER
-encodings) are given in Table 3.
-
- Integer BER encoding
- value
- 0 02 01 00
- 127 02 01 7F
- 128 02 02 00 80
- 256 02 02 01 00
- -128 02 01 80
- -129 02 02 FF 7F
-
- Table 3. Example BER encodings of INTEGER values.
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-
-5.8 NULL
-
-The NULL type denotes a null value.
-
-The NULL type is used for algorithm parameters in several
-places in PKCS.
-
-ASN.1 notation:
-
-NULL
-
-BER encoding. Primitive. Contents octets are empty.
-
-Example: The BER encoding of a NULL value can be either of
-the following, as well as others, depending on the form of
-the length octets:
-
-05 00
-
-05 81 00
-
-DER encoding. Primitive. Contents octets are empty; the DER
-encoding of a NULL value is always 05 00.
-
-
-5.9 OBJECT IDENTIFIER
-
-The OBJECT IDENTIFIER type denotes an object identifier, a
-sequence of integer components that identifies an object
-such as an algorithm, an attribute type, or perhaps a
-registration authority that defines other object
-identifiers. An OBJECT IDENTIFIER value can have any number
-of components, and components can generally have any
-nonnegative value. This type is a non-string type.
-
-OBJECT IDENTIFIER values are given meanings by registration
-authorities. Each registration authority is responsible for
-all sequences of components beginning with a given sequence.
-A registration authority typically delegates responsibility
-for subsets of the sequences in its domain to other
-registration authorities, or for particular types of object.
-There are always at least two components.
-
-The OBJECT IDENTIFIER type is used to identify content in
-PKCS #7's ContentInfo type, to identify algorithms in
-X.509's AlgorithmIdentifier type, and to identify attributes
-in X.501's Attribute and AttributeValueAssertion types. The
-Attribute type is used by PKCS #6, #7, #8, #9, and #10, and
-the AttributeValueAssertion type is used in X.501
-distinguished names. OBJECT IDENTIFIER values are defined
-throughout PKCS.
-
-ASN.1 notation:
-
-OBJECT IDENTIFIER
-
-The ASN.1 notation for values of the OBJECT IDENTIFIER type
-is
-
-{ [identifier] component1 ... componentn }
-
-componenti = identifieri | identifieri (valuei) | valuei
-
-where identifier, identifier1, ..., identifiern are
-identifiers, and value1, ..., valuen are optional integer
-values.
-
-The form without identifier is the "complete" value with all
-its components; the form with identifier abbreviates the
-beginning components with another object identifier value.
-The identifiers identifier1, ..., identifiern are intended
-primarily for documentation, but they must correspond to the
-integer value when both are present. These identifiers can
-appear without integer values only if they are among a small
-set of identifiers defined in X.208.
-
-Example: The following values both refer to the object
-identifier assigned to RSA Data Security, Inc.:
-
-{ iso(1) member-body(2) 840 113549 }
-{ 1 2 840 113549 }
-
-(In this example, which gives ASN.1 value notation, the
-object identifier values are decimal, not hexadecimal.)
-Table 4 gives some other object identifier values and their
-meanings.
-
- Object identifier value Meaning
- { 1 2 } ISO member bodies
- { 1 2 840 } US (ANSI)
- { 1 2 840 113549 } RSA Data Security, Inc.
- { 1 2 840 113549 1 } RSA Data Security, Inc. PKCS
- { 2 5 } directory services (X.500)
- { 2 5 8 } directory services-algorithms
-
- Table 4. Some object identifier values and their meanings.
-
-BER encoding. Primitive. Contents octets are as follows,
-where value1, ..., valuen denote the integer values of the
-components in the complete object identifier:
-
- 1. The first octet has value 40 * value1 + value2.
- (This is unambiguous, since value1 is limited to
- values 0, 1, and 2; value2 is limited to the range
- 0 to 39 when value1 is 0 or 1; and, according to
- X.208, n is always at least 2.)
-
- 2. The following octets, if any, encode value3, ...,
- valuen. Each value is encoded base 128, most
- significant digit first, with as few digits as
- possible, and the most significant bit of each
- octet except the last in the value's encoding set
- to "1."
-
-Example: The first octet of the BER encoding of RSA Data
-Security, Inc.'s object identifier is 40 * 1 + 2 = 42 =
-2a16. The encoding of 840 = 6 * 128 + 4816 is 86 48 and the
-encoding of 113549 = 6 * 1282 + 7716 * 128 + d16 is 86 f7
-0d. This leads to the following BER encoding:
-
-06 06 2a 86 48 86 f7 0d
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-
-5.10 OCTET STRING
-
-The OCTET STRING type denotes an arbitrary string of octets
-(eight-bit values). An OCTET STRING value can have any
-length, including zero. This type is a string type.
-
-The OCTET STRING type is used for salt values in PKCS #5's
-PBEParameter type, for message digests, encrypted message
-digests, and encrypted content in PKCS #7, and for private
-keys and encrypted private keys in PKCS #8.
-
-ASN.1 notation:
-
-OCTET STRING [SIZE ({size | size1..size2})]
-
-where size, size1, and size2 are optional size constraints.
-In the OCTET STRING SIZE (size) form, the octet string must
-have size octets. In the OCTET STRING SIZE (size1..size2)
-form, the octet string must have between size1 and size2
-octets. In the OCTET STRING form, the octet string can have
-any size.
-
-Example: PKCS #5's PBEParameter type has a component of type
-OCTET STRING:
-
-PBEParameter ::= SEQUENCE {
- salt OCTET STRING SIZE(8),
- iterationCount INTEGER }
-
-Here the size of the salt component is always eight octets.
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the value of the octet
-string, first octet to last octet. In a constructed
-encoding, the contents octets give the concatenation of the
-BER encodings of substrings of the OCTET STRING value.
-
-Example: The BER encoding of the OCTET STRING value 01 23 45
-67 89 ab cd ef can be any of the following, among others,
-depending on the form of length octets and whether the
-encoding is primitive or constructed:
-
-04 08 01 23 45 67 89 ab cd ef DER encoding
-
-04 81 08 01 23 45 67 89 ab cd ef long form of length octets
-
-24 0c constructed encoding: 01 ... 67 + 89 ... ef
- 04 04 01 23 45 67
- 04 04 89 ab cd ef
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The BER encoding of the OCTET STRING value 01 23 45
-67 89 ab cd ef is
-
-04 08 01 23 45 67 89 ab cd ef
-
-
-5.11 PrintableString
-
-The PrintableString type denotes an arbitrary string of
-printable characters from the following character set:
-
- A, B, ..., Z
- a, b, ..., z
- 0, 1, ..., 9
- (space) ' ( ) + , - . / : = ?
-
-This type is a string type.
-
-The PrintableString type is used in PKCS #9's challenge-
-password and unstructuerd-address attributes, and in several
-X.521 distinguished names attributes.
-
-ASN.1 notation:
-
-PrintableString
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the
-printable string, encoded in ASCII. In a constructed
-encoding, the contents octets give the concatenation of the
-BER encodings of consecutive substrings of the string.
-
-Example: The BER encoding of the PrintableString value "Test
-User 1" can be any of the following, among others, depending
-on the form of length octets and whether the encoding is
-primitive or constructed:
-
-13 0b 54 65 73 74 20 55 73 65 72 20 31 DER encoding
-
-13 81 0b long form of length octets
- 54 65 73 74 20 55 73 65 72 20 31
-
-33 0f constructed encoding: "Test " + "User 1"
- 13 05 54 65 73 74 20
- 13 06 55 73 65 72 20 31
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The DER encoding of the PrintableString value "Test
-User 1" is
-
-13 0b 54 65 73 74 20 55 73 65 72 20 31
-
-
-5.12 SEQUENCE
-
-The SEQUENCE type denotes an ordered collection of one or
-more types.
-
-The SEQUENCE type is used throughout PKCS and related
-standards.
-
-ASN.1 notation:
-
-SEQUENCE {
- [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
- ...,
- [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
-
-where identifier1 , ..., identifiern are optional, distinct
-identifiers for the components, Type1, ..., Typen are the
-types of the components, and value1, ..., valuen are optional
-default values for the components. The identifiers are
-primarily for documentation; they do not affect values of
-the type or their encodings in any way.
-
-The OPTIONAL qualifier indicates that the value of a
-component is optional and need not be present in the
-sequence. The DEFAULT qualifier also indicates that the
-value of a component is optional, and assigns a default
-value to the component when the component is absent.
-
-The types of any consecutive series of components with the
-OPTIONAL or DEFAULT qualifier, as well as of any component
-immediately following that series, must have distinct tags.
-This requirement is typically satisfied with explicit or
-implicit tagging on some of the components.
-
-Example: X.509's Validity type is a SEQUENCE type with two
-components:
-
-Validity ::= SEQUENCE {
- start UTCTime,
- end UTCTime }
-
-Here the identifiers for the components are start and end,
-and the types of the components are both UTCTime.
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-components of the sequence, in order of definition, with the
-following rules for components with the OPTIONAL and DEFAULT
-qualifiers:
-
- o if the value of a component with the OPTIONAL or
- DEFAULT qualifier is absent from the sequence,
- then the encoding of that component is not
- included in the contents octets
-
- o if the value of a component with the DEFAULT
- qualifier is the default value, then the encoding
- of that component may or may not be included in
- the contents octets
-
-DER encoding. Constructed. Contents octets are the same as
-the BER encoding, except that if the value of a component
-with the DEFAULT qualifier is the default value, the
-encoding of that component is not included in the contents
-octets.
-
-
-5.13 SEQUENCE OF
-
-The SEQUENCE OF type denotes an ordered collection of zero
-or more occurrences of a given type.
-
-The SEQUENCE OF type is used in X.501 distinguished names.
-
-ASN.1 notation:
-
-SEQUENCE OF Type
-
-where Type is a type.
-
-Example: X.501's RDNSequence type consists of zero or more
-occurences of the RelativeDistinguishedName type, most
-significant occurrence first:
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-occurrences in the collection, in order of occurence.
-
-DER encoding. Constructed. Contents octets are the
-concatenation of the DER encodings of the values of the
-occurrences in the collection, in order of occurence.
-
-
-5.14 SET
-
-The SET type denotes an unordered collection of one or more
-types.
-
-The SET type is not used in PKCS.
-
-ASN.1 notation:
-
-SET {
- [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
- ...,
- [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
-
-where identifier1, ..., identifiern are optional, distinct
-identifiers for the components, Type1, ..., Typen are the
-types of the components, and value1, ..., valuen are
-optional default values for the components. The identifiers
-are primarily for documentation; they do not affect values
-of the type or their encodings in any way.
-
-The OPTIONAL qualifier indicates that the value of a
-component is optional and need not be present in the set.
-The DEFAULT qualifier also indicates that the value of a
-component is optional, and assigns a default value to the
-component when the component is absent.
-
-The types must have distinct tags. This requirement is
-typically satisfied with explicit or implicit tagging on
-some of the components.
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-components of the set, in any order, with the following
-rules for components with the OPTIONAL and DEFAULT
-qualifiers:
-
- o if the value of a component with the OPTIONAL or
- DEFAULT qualifier is absent from the set, then the
- encoding of that component is not included in the
- contents octets
-
- o if the value of a component with the DEFAULT
- qualifier is the default value, then the encoding
- of that component may or may not be included in
- the contents octets
-
-DER encoding. Constructed. Contents octets are the same as
-for the BER encoding, except that:
-
- 1. If the value of a component with the DEFAULT
- qualifier is the default value, the encoding of
- that component is not included.
-
- 2. There is an order to the components, namely
- ascending order by tag.
-
-
-5.15 SET OF
-
-The SET OF type denotes an unordered collection of zero or
-more occurrences of a given type.
-
-The SET OF type is used for sets of attributes in PKCS #6,
-#7, #8, #9 and #10, for sets of message-digest algorithm
-identifiers, signer information, and recipient information
-in PKCS #7, and in X.501 distinguished names.
-
-ASN.1 notation:
-
-SET OF Type
-
-where Type is a type.
-
-Example: X.501's RelativeDistinguishedName type consists of
-zero or more occurrences of the AttributeValueAssertion
-type, where the order is unimportant:
-
-RelativeDistinguishedName ::=
- SET OF AttributeValueAssertion
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-occurrences in the collection, in any order.
-
-DER encoding. Constructed. Contents octets are the same as
-for the BER encoding, except that there is an order, namely
-ascending lexicographic order of BER encoding. Lexicographic
-comparison of two different BER encodings is done as
-follows: Logically pad the shorter BER encoding after the
-last octet with dummy octets that are smaller in value than
-any normal octet. Scan the BER encodings from left to right
-until a difference is found. The smaller-valued BER encoding
-is the one with the smaller-valued octet at the point of
-difference.
-
-
-5.16 T61String
-
-The T61String type denotes an arbtrary string of T.61
-characters. T.61 is an eight-bit extension to the ASCII
-character set. Special "escape" sequences specify the
-interpretation of subsequent character values as, for
-example, Japanese; the initial interpretation is Latin. The
-character set includes non-printing control characters. The
-T61String type allows only the Latin and Japanese character
-interepretations, and implementors' agreements for directory
-names exclude control characters [NIST92]. A T61String value
-can have any length, including zero. This type is a string
-type.
-
-The T61String type is used in PKCS #9's unstructured-address
-and challenge-password attributes, and in several X.521
-attributes.
-
-ASN.1 notation:
-
-T61String
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the
-T.61 string, encoded in ASCII. In a constructed encoding,
-the contents octets give the concatenation of the BER
-encodings of consecutive substrings of the T.61 string.
-
-Example: The BER encoding of the T61String value "cl'es
-publiques" (French for "public keys") can be any of the
-following, among others, depending on the form of length
-octets and whether the encoding is primitive or constructed:
-
-14 0f DER encoding
- 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
-
-14 81 0f long form of length octets
- 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
-
-34 15 constructed encoding: "cl'es" + " " + "publiques"
- 14 05 63 6c c2 65 73
- 14 01 20
- 14 09 70 75 62 6c 69 71 75 65 73
-
-The eight-bit character c2 is a T.61 prefix that adds an
-acute accent (') to the next character.
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The DER encoding of the T61String value "cl'es
-publiques" is
-
-14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
-
-
-5.17 UTCTime
-
-The UTCTime type denotes a "coordinated universal time" or
-Greenwich Mean Time (GMT) value. A UTCTime value includes
-the local time precise to either minutes or seconds, and an
-offset from GMT in hours and minutes. It takes any of the
-following forms:
-
-YYMMDDhhmmZ
-YYMMDDhhmm+hh'mm'
-YYMMDDhhmm-hh'mm'
-YYMMDDhhmmssZ
-YYMMDDhhmmss+hh'mm'
-YYMMDDhhmmss-hh'mm'
-
-where:
-
- YY is the least significant two digits of the year
-
- MM is the month (01 to 12)
-
- DD is the day (01 to 31)
-
- hh is the hour (00 to 23)
-
- mm are the minutes (00 to 59)
-
- ss are the seconds (00 to 59)
-
- Z indicates that local time is GMT, + indicates that
- local time is later than GMT, and - indicates that
- local time is earlier than GMT
-
- hh' is the absolute value of the offset from GMT in
- hours
-
- mm' is the absolute value of the offset from GMT in
- minutes
-
-This type is a string type.
-
-The UTCTime type is used for signing times in PKCS #9's
-signing-time attribute and for certificate validity periods
-in X.509's Validity type.
-
-ASN.1 notation:
-
-UTCTime
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the
-string, encoded in ASCII. In a constructed encoding, the
-contents octets give the concatenation of the BER encodings
-of consecutive substrings of the string. (The constructed
-encoding is not particularly interesting, since UTCTime
-values are so short, but the constructed encoding is
-permitted.)
-
-Example: The time this sentence was originally written was
-4:45:40 p.m. Pacific Daylight Time on May 6, 1991, which can
-be represented with either of the following UTCTime values,
-among others:
-
-"910506164540-0700"
-
-"910506234540Z"
-
-These values have the following BER encodings, among others:
-
-17 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a
-
-17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30
- 30
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-
-6. An example
-
-This section gives an example of ASN.1 notation and DER
-encoding: the X.501 type Name.
-
-
-6.1 Abstract notation
-
-This section gives the ASN.1 notation for the X.501 type
-Name.
-
-Name ::= CHOICE {
- RDNSequence }
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-RelativeDistinguishedName ::=
- SET OF AttributeValueAssertion
-
-AttributeValueAssertion ::= SEQUENCE {
- AttributeType,
- AttributeValue }
-
-AttributeType ::= OBJECT IDENTIFIER
-
-AttributeValue ::= ANY
-
-The Name type identifies an object in an X.500 directory.
-Name is a CHOICE type consisting of one alternative:
-RDNSequence. (Future revisions of X.500 may have other
-alternatives.)
-
-The RDNSequence type gives a path through an X.500 directory
-tree starting at the root. RDNSequence is a SEQUENCE OF type
-consisting of zero or more occurences of
-RelativeDistinguishedName.
-
-The RelativeDistinguishedName type gives a unique name to an
-object relative to the object superior to it in the
-directory tree. RelativeDistinguishedName is a SET OF type
-consisting of zero or more occurrences of
-AttributeValueAssertion.
-
-The AttributeValueAssertion type assigns a value to some
-attribute of a relative distinguished name, such as country
-name or common name. AttributeValueAssertion is a SEQUENCE
-type consisting of two components, an AttributeType type and
-an AttributeValue type.
-
-The AttributeType type identifies an attribute by object
-identifier. The AttributeValue type gives an arbitrary
-attribute value. The actual type of the attribute value is
-determined by the attribute type.
-
-
-6.2 DER encoding
-
-This section gives an example of a DER encoding of a value
-of type Name, working from the bottom up.
-
-The name is that of the Test User 1 from the PKCS examples
-[Kal93]. The name is represented by the following path:
-
- (root)
- |
- countryName = "US"
- |
- organizationName = "Example Organization"
- |
- commonName = "Test User 1"
-
-Each level corresponds to one RelativeDistinguishedName
-value, each of which happens for this name to consist of one
-AttributeValueAssertion value. The AttributeType value is
-before the equals sign, and the AttributeValue value (a
-printable string for the given attribute types) is after the
-equals sign.
-
-The countryName, organizationName, and commonUnitName are
-attribute types defined in X.520 as:
-
-attributeType OBJECT IDENTIFIER ::=
- { joint-iso-ccitt(2) ds(5) 4 }
-
-countryName OBJECT IDENTIFIER ::= { attributeType 6 }
-organizationName OBJECT IDENTIFIER ::=
- { attributeType 10 }
-commonUnitName OBJECT IDENTIFIER ::=
- { attributeType 3 }
-
-
-6.2.1 AttributeType
-
-The three AttributeType values are OCTET STRING values, so
-their DER encoding follows the primitive, definite-length
-method:
-
-06 03 55 04 06 countryName
-
-06 03 55 04 0a organizationName
-
-06 03 55 04 03 commonName
-
-The identifier octets follow the low-tag form, since the tag
-is 6 for OBJECT IDENTIFIER. Bits 8 and 7 have value "0,"
-indicating universal class, and bit 6 has value "0,"
-indicating that the encoding is primitive. The length octets
-follow the short form. The contents octets are the
-concatenation of three octet strings derived from
-subidentifiers (in decimal): 40 * 2 + 5 = 85 = 5516; 4; and
-6, 10, or 3.
-
-
-6.2.2 AttributeValue
-
-The three AttributeValue values are PrintableString values,
-so their encodings follow the primitive, definite-length
-method:
-
-13 02 55 53 "US"
-
-13 14 "Example Organization"
- 45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
- 74 69 6f 6e
-
-13 0b "Test User 1"
- 54 65 73 74 20 55 73 65 72 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for PrintableString, 19 (decimal), is between 0 and
-30. Bits 8 and 7 have value "0" since PrintableString is in
-the universal class. Bit 6 has value "0" since the encoding
-is primitive. The length octets follow the short form, and
-the contents octets are the ASCII representation of the
-attribute value.
-
-
-6.2.3 AttributeValueAssertion
-
-The three AttributeValueAssertion values are SEQUENCE
-values, so their DER encodings follow the constructed,
-definite-length method:
-
-30 09 countryName = "US"
- 06 03 55 04 06
- 13 02 55 53
-
-30 1b organizationName = "Example Organizaiton"
- 06 03 55 04 0a
- 13 14 ... 6f 6e
-
-30 12 commonName = "Test User 1"
- 06 03 55 04 0b
- 13 0b ... 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for SEQUENCE, 16 (decimal), is between 0 and 30.
-Bits 8 and 7 have value "0" since SEQUENCE is in the
-universal class. Bit 6 has value "1" since the encoding is
-constructed. The length octets follow the short form, and
-the contents octets are the concatenation of the DER
-encodings of the attributeType and attributeValue
-components.
-
-
-6.2.4 RelativeDistinguishedName
-
-The three RelativeDistinguishedName values are SET OF
-values, so their DER encodings follow the constructed,
-definite-length method:
-
-31 0b
- 30 09 ... 55 53
-
-31 1d
- 30 1b ... 6f 6e
-
-31 14
- 30 12 ... 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for SET OF, 17 (decimal), is between 0 and 30. Bits
-8 and 7 have value "0" since SET OF is in the universal
-class Bit 6 has value "1" since the encoding is constructed.
-The lengths octets follow the short form, and the contents
-octets are the DER encodings of the respective
-AttributeValueAssertion values, since there is only one
-value in each set.
-
-
-6.2.5 RDNSequence
-
-The RDNSequence value is a SEQUENCE OF value, so its DER
-encoding follows the constructed, definite-length method:
-
-30 42
- 31 0b ... 55 53
- 31 1d ... 6f 6e
- 31 14 ... 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for SEQUENCE OF, 16 (decimal), is between 0 and 30.
-Bits 8 and 7 have value "0" since SEQUENCE OF is in the
-universal class. Bit 6 has value "1" since the encoding is
-constructed. The lengths octets follow the short form, and
-the contents octets are the concatenation of the DER
-encodings of the three RelativeDistinguishedName values, in
-order of occurrence.
-
-
-6.2.6 Name
-
-The Name value is a CHOICE value, so its DER encoding is the
-same as that of the RDNSequence value:
-
-30 42
- 31 0b
- 30 09
- 06 03 55 04 06 attributeType = countryName
- 13 02 55 53 attributeValue = "US"
- 31 1d
- 30 1b
- 06 03 55 04 0a attributeType = organizationName
- 13 14 attributeValue = "Example Organization"
- 45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
- 74 69 6f 6e
-
- 31 14
- 30 12
- 06 03 55 04 03 attributeType = commonName
- 13 0b attributeValue = "Test User 1"
- 54 65 73 74 20 55 73 65 72 20 31
-
-
-References
-
-PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption
- Standard. Version 1.5, November 1993.
-
-PKCS #3 RSA Laboratories. PKCS #3: Diffie-Hellman Key-
- Agreement Standard. Version 1.4, November 1993.
-
-PKCS #5 RSA Laboratories. PKCS #5: Password-Based
- Encryption Standard. Version 1.5, November 1993.
-
-PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
- Syntax Standard. Version 1.5, November 1993.
-
-PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message
- Syntax Standard. Version 1.5, November 1993.
-
-PKCS #8 RSA Laboratories. PKCS #8: Private-Key Information
- Syntax Standard. Version 1.2, November 1993.
-
-PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
- Types. Version 1.1, November 1993.
-
-PKCS #10 RSA Laboratories. PKCS #10: Certification Request
- Syntax Standard. Version 1.0, November 1993.
-
-X.200 CCITT. Recommendation X.200: Reference Model of
- Open Systems Interconnection for CCITT
- Applications. 1984.
-
-X.208 CCITT. Recommendation X.208: Specification of
- Abstract Syntax Notation One (ASN.1). 1988.
-
-X.209 CCITT. Recommendation X.209: Specification of
- Basic Encoding Rules for Abstract Syntax Notation
- One (ASN.1). 1988.
-
-X.500 CCITT. Recommendation X.500: The
- Directory--Overview of Concepts, Models and
- Services. 1988.
-
-X.501 CCITT. Recommendation X.501: The Directory--
- Models. 1988.
-
-X.509 CCITT. Recommendation X.509: The Directory--
- Authentication Framework. 1988.
-
-X.520 CCITT. Recommendation X.520: The Directory--
- Selected Attribute Types. 1988.
-
-[Kal93] Burton S. Kaliski Jr. Some Examples of the PKCS
- Standards. RSA Laboratories, November 1993.
-
-[NIST92] NIST. Special Publication 500-202: Stable
- Implementation Agreements for Open Systems
- Interconnection Protocols. Part 11 (Directory
- Services Protocols). December 1992.
-
-
-Revision history
-
-
-June 3, 1991 version
-
-The June 3, 1991 version is part of the initial public
-release of PKCS. It was published as NIST/OSI Implementors'
-Workshop document SEC-SIG-91-17.
-
-
-November 1, 1993 version
-
-The November 1, 1993 version incorporates several editorial
-changes, including the addition of a revision history. It is
-updated to be consistent with the following versions of the
-PKCS documents:
-
- PKCS #1: RSA Encryption Standard. Version 1.5, November
- 1993.
-
- PKCS #3: Diffie-Hellman Key-Agreement Standard. Version
- 1.4, November 1993.
-
- PKCS #5: Password-Based Encryption Standard. Version
- 1.5, November 1993.
-
- PKCS #6: Extended-Certificate Syntax Standard. Version
- 1.5, November 1993.
-
- PKCS #7: Cryptographic Message Syntax Standard. Version
- 1.5, November 1993.
-
- PKCS #8: Private-Key Information Syntax Standard.
- Version 1.2, November 1993.
-
- PKCS #9: Selected Attribute Types. Version 1.1,
- November 1993.
-
- PKCS #10: Certification Request Syntax Standard.
- Version 1.0, November 1993.
-
-The following substantive changes were made:
-
- Section 5: Description of T61String type is added.
-
- Section 6: Names are changed, consistent with other
- PKCS examples.
-
-
-Author's address
-
-Burton S. Kaliski Jr., Ph.D.
-Chief Scientist
-RSA Laboratories (415) 595-7703
-100 Marine Parkway (415) 595-4126 (fax)
-Redwood City, CA 94065 USA burt@rsa.com
projects / openldap / commitdiff