mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-27 03:20:22 +08:00
1856 lines
61 KiB
Plaintext
1856 lines
61 KiB
Plaintext
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
|