/crypto/heimdal/doc/layman.asc
Unknown | 1855 lines | 1342 code | 513 blank | 0 comment | 0 complexity | dbe47a235c7b1da117037a3c7882669b MD5 | raw file
Possible License(s): MPL-2.0-no-copyleft-exception, BSD-3-Clause, LGPL-2.0, LGPL-2.1, BSD-2-Clause, 0BSD, JSON, AGPL-1.0, GPL-2.0
- 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