doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc6025.txt b/doc/rfc/rfc6025.txt
new file mode 100644
index 0000000..8ee7de5
--- /dev/null
+++ b/doc/rfc/rfc6025.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        C. Wallace
+Request for Comments: 6025                            Cygnacom Solutions
+Category: Informational                                      C. Gardiner
+ISSN: 2070-1721                                         BBN Technologies
+                                                            October 2010
+
+
+                           ASN.1 Translation
+
+Abstract
+
+   Abstract Syntax Notation One (ASN.1) is widely used throughout the
+   IETF Security Area and has been for many years.  Some specifications
+   were written using a now deprecated version of ASN.1 and some were
+   written using the current version of ASN.1.  Not all ASN.1 compilers
+   support both older and current syntax.  This document is intended to
+   provide guidance to specification authors and to implementers
+   converting ASN.1 modules from one version of ASN.1 to another version
+   without causing changes to the "bits on the wire".  This document
+   does not provide a comprehensive tutorial of any version of ASN.1.
+   Instead, it addresses ASN.1 features that are used in IETF Security
+   Area specifications with a focus on items that vary with the ASN.1
+   version.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6025.
+
+
+
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 1]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  ASN.1 Design Elements  . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Open Types . . . . . . . . . . . . . . . . . . . . . . . .  3
+       2.1.1.  ANY DEFINED BY . . . . . . . . . . . . . . . . . . . .  4
+       2.1.2.  OCTET STRINGs and BIT STRINGs  . . . . . . . . . . . .  5
+       2.1.3.  Information Object Classes . . . . . . . . . . . . . .  5
+     2.2.  Constraints  . . . . . . . . . . . . . . . . . . . . . . .  8
+       2.2.1.  Simple Table Constraints . . . . . . . . . . . . . . .  8
+       2.2.2.  Component Relation Constraints . . . . . . . . . . . .  9
+       2.2.3.  Content Constraints  . . . . . . . . . . . . . . . . . 11
+     2.3.  Parameterization . . . . . . . . . . . . . . . . . . . . . 12
+     2.4.  Versioning and Extensibility . . . . . . . . . . . . . . . 13
+       2.4.1.  Extension Markers  . . . . . . . . . . . . . . . . . . 14
+       2.4.2.  Version Brackets . . . . . . . . . . . . . . . . . . . 14
+   3.  Character Set Differences  . . . . . . . . . . . . . . . . . . 15
+   4.  ASN.1 Translation  . . . . . . . . . . . . . . . . . . . . . . 16
+     4.1.  Downgrading from X.68x to X.208  . . . . . . . . . . . . . 16
+     4.2.  Upgrading from X.208 to X.68x  . . . . . . . . . . . . . . 16
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 2]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+1.  Introduction
+
+   This document is intended to serve as a tutorial for converting ASN.1
+   modules written using [CCITT.X208.1988] to [CCITT.X680.2002], or vice
+   versa.  Preparation of this document was motivated by [RFC5911] and
+   [RFC5912], which provide updated ASN.1 modules for a number of RFCs.
+
+   The intent of this specification is to assist with translation of
+   ASN.1 from one version to another without resulting in any changes to
+   the encoded results when using the Basic Encoding Rules or
+   Distinguished Encoding Rules [CCITT.X209.1988] [CCITT.X690.2002].
+   Other encoding rules were not considered.
+
+   Transforming a new ASN.1 module to an older ASN.1 module can be
+   performed in a fairly mechanical manner; much of the transformation
+   consists of deleting new constructs.  Transforming an older ASN.1
+   module to a newer ASN.1 module can also be done fairly mechanically,
+   if one does not wish to move many of the constraints that are
+   contained in the prose into the ASN.1 module.  If the constraints are
+   to be added, then the conversion can be a complex process.
+
+1.1.  Terminology
+
+   This document addresses two different versions of ASN.1.  The old
+   (1988) version was defined in a single document (X.208) and the newer
+   (1998, 2002) version is defined in a series of documents (X.680,
+   X.681, X.682, and X.683).  For convenience, the series of documents
+   is henceforth referred to as X.68x.  Specific documents from the
+   series are referenced by name where appropriate.
+
+2.  ASN.1 Design Elements
+
+   When translating an ASN.1 module from X.208 syntax to X.68x syntax,
+   or vice versa, many definitions do not require or benefit from
+   change.  Review of the original ASN.1 modules updated by [RFC5911]
+   and [RFC5912] and the revised modules included in those documents
+   indicates that most changes can be sorted into one of a few
+   categories.  This section describes these categories.
+
+2.1.  Open Types
+
+   Protocols often feature flexible designs that enable other (later)
+   specifications to define the syntax and semantics of some features.
+   For example, [RFC5280] includes the definition of the Extension
+   structure.  There are many instances of extensions defined in other
+   specifications.  Several mechanisms to accommodate this practice are
+   available in X.208, X.68x, or both, as described below.
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 3]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+2.1.1.  ANY DEFINED BY
+
+   X.208 defines the ANY DEFINED BY production for specifying open
+   types.  This typically appears in a SEQUENCE along with an OBJECT
+   IDENTIFIER that indicates the type of object that is encoded.  The
+   ContentInfo structure, shown below from [RFC5652], uses ANY DEFINED
+   BY along with an OBJECT IDENTIFIER field to identify and convey
+   arbitrary types of data.  Each content type to be wrapped in a
+   ContentInfo is assigned a unique OBJECT IDENTIFIER, such as the
+   id-signedData shown below.  However, X.208 does not provide a formal
+   means for establishing a relationship between a type and the type
+   identifier.  Any associations are done in the comments of the module
+   and/or the text of the associated document.
+
+   -- from RFC 5652
+   ContentInfo ::= SEQUENCE {
+       contentType ContentType,
+       content [0] EXPLICIT ANY DEFINED BY contentType }
+
+   ContentType ::= OBJECT IDENTIFIER
+
+   id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+      us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
+
+   ANY DEFINED BY may also appear using an INTEGER to indicate the type
+   of object that is encoded, as shown in the following example from
+   [RFC5280].
+
+   -- from RFC 5280
+   ExtensionAttribute ::=  SEQUENCE {
+       extension-attribute-type [0] IMPLICIT INTEGER
+           (0..ub-extension-attributes),
+       extension-attribute-value [1]
+           ANY DEFINED BY extension-attribute-type }
+
+   Though the usage of ANY DEFINED BY was deprecated in 1994, it appears
+   in some active specifications.  The AttributeValue definition in
+   [RFC5280] uses ANY with a DEFINED BY comment to bind the value to a
+   type identifier field.
+
+   -- from RFC 5280
+   AttributeTypeAndValue ::= SEQUENCE {
+       type     AttributeType,
+       value    AttributeValue }
+
+   AttributeType ::= OBJECT IDENTIFIER
+
+   AttributeValue ::= ANY -- DEFINED BY AttributeType
+
+
+
+Wallace & Gardiner            Informational                     [Page 4]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+2.1.2.  OCTET STRINGs and BIT STRINGs
+
+   Both X.208 and X.68x allow open types to be implemented using OCTET
+   STRINGs and BIT STRINGs as containers.  The definitions of Extension
+   and SubjectPublicKeyInfo in [RFC5280] demonstrate the usage of OCTET
+   STRING and BIT STRING, respectively, to convey information that is
+   further defined using ASN.1.
+
+   -- from RFC 5280
+   Extension  ::=  SEQUENCE  {
+       extnID      OBJECT IDENTIFIER,
+       critical    BOOLEAN DEFAULT FALSE,
+       extnValue   OCTET STRING
+       -- contains the DER encoding of an ASN.1 value
+       -- corresponding to the extension type identified
+       -- by extnID
+   }
+
+   SubjectPublicKeyInfo  ::=  SEQUENCE  {
+        algorithm            AlgorithmIdentifier,
+        subjectPublicKey     BIT STRING  }
+
+   In both cases, the prose of the specification describes that the
+   adjacent OBJECT IDENTIFIER value indicates the type of structure
+   within the value of the primitive OCTET STRING or BIT STRING type.
+   For example, where an extnID field contains the value
+   id-ce-basicConstraints, the extnValue field contains an encoded
+   BasicConstraints as the value of the OCTET STRING, as shown in the
+   dump of an encoded extension below.
+
+   Tag Length      Value
+   30   15:         SEQUENCE {
+   06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
+   01    1:           BOOLEAN TRUE
+   04    5:           OCTET STRING, encapsulates {
+   30    3:               SEQUENCE {
+   01    1:                 BOOLEAN TRUE
+          :                 }
+          :               }
+          :           }
+
+2.1.3.  Information Object Classes
+
+   Information object classes are defined in [CCITT.X681.2002].  Object
+   classes allow protocol designers to relate pieces of data that are in
+   some way associated.  In the most generic of terms, an Information
+   Object class can be thought of as a database schema, with Information
+   Object Sets being instances of the databases.
+
+
+
+Wallace & Gardiner            Informational                     [Page 5]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   Unlike type definitions, object classes with the same structure are
+   not equivalent.  Thus, if you have:
+
+      FOO ::= TYPE-IDENTIFIER
+
+      BAR ::= TYPE-IDENTIFIER
+
+   FOO and BAR are not interchangeable.
+
+   TYPE-IDENTIFIER is one of the predefined information object classes
+   in Annex A of [CCITT.X681.2002].  This provides for a simple mapping
+   from an OBJECT IDENTIFIER to a data type.  The tag UNIQUE on &id
+   means that this value may appear only once in an Information Object
+   Set; however, multiple objects can be defined with the same &id
+   value.
+
+   [RFC5911] uses the TYPE-IDENTIFIER construction to update the
+   definition of ContentInfo, as shown below.
+
+   -- TYPE-IDENTIFIER definition from X.681
+   TYPE-IDENTIFIER ::= CLASS
+   {
+       &id OBJECT IDENTIFIER UNIQUE,
+       &Type
+   }
+   WITH SYNTAX {&Type IDENTIFIED BY &id}
+
+   -- from updated RFC 5652 module in [RFC5911]
+   CONTENT-TYPE ::= TYPE-IDENTIFIER
+   ContentType ::= CONTENT-TYPE.&id
+
+   ContentInfo ::= SEQUENCE {
+       contentType        CONTENT-TYPE.
+                       &id({ContentSet}),
+       content            [0] EXPLICIT CONTENT-TYPE.
+                       &Type({ContentSet}{@contentType})}
+
+   ContentSet CONTENT-TYPE ::= {
+       --  Define the set of content types to be recognized.
+       ct-Data | ct-SignedData | ct-EncryptedData | ct-EnvelopedData |
+       ct-AuthenticatedData | ct-DigestedData, ... }
+
+   -- other CONTENT-TYPE instances not shown for brevity
+   ct-SignedData CONTENT-TYPE ::=
+        { SignedData IDENTIFIED BY id-signedData}
+
+
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 6]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   This example illustrates the following:
+
+   o  Definition of an information object class: TYPE-IDENTIFIER and
+      CONTENT-TYPE are information object classes.
+
+   o  Definition of an information object, or an instance of an
+      information object class: ct-SignedData is an information object.
+
+   o  Definition of an information object set: ContentSet is an
+      information object set.
+
+   o  Usage of an information object: The definition of ContentInfo uses
+      information from the CONTENT-TYPE information object class.
+
+   o  Defining constraints using an object set: Both the contentType and
+      content fields are constrained by ContentSet.
+
+   As noted above, TYPE-IDENTIFIER simply associates an OBJECT
+   IDENTIFIER with an arbitrary data type.  CONTENT-TYPE is a TYPE-
+   IDENTIFIER.  The WITH SYNTAX component allows for a more natural
+   language expression of information object definitions.
+
+   ct-SignedData is the name of an information object that associated
+   the identifier id-signedData with the data type SignedData.  It is an
+   instance of the CONTENT-TYPE information object class.  The &Type
+   field is assigned the value SignedData, and the &id field is assigned
+   the value id-signedData.  The example above uses the syntax provided
+   by the WITH SYNTAX component of the TYPE-IDENTIFIER definition.  An
+   equivalent definition that does not use the provided syntax is as
+   follows:
+
+   ct-SignedData CONTENT-TYPE ::=
+   {
+       &id id-signedData,
+       &Type SignedData
+   }
+
+   ContentSet is the name of a set of information objects derived from
+   the CONTENT-TYPE information object class.  The set contains six
+   information objects and is extensible, as indicated by the ellipsis
+   (see Section 2.4, "Versioning and Extensibility").
+
+   ContentInfo is defined using type information from an information
+   object, i.e., the type of the contentType field is that of the &id
+   field from CONTENT-TYPE.  An equivalent definition is as follows:
+
+   ContentType ::= OBJECT IDENTIFIER
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 7]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   Both fields in ContentInfo are constrained.  The contentType field is
+   constrained using a simple table constraint that restricts the values
+   to those from the corresponding field of the objects in ContentSet.
+   The content field is constrained using a component relationship
+   constraint.  Constraints are discussed in the next section.
+
+2.2.  Constraints
+
+   The X.68x versions of the ASN.1 specifications introduced the ability
+   to use the object information sets as part of the constraint on the
+   values that a field can take.  Simple table constraints are used to
+   restrict the set of values that can occur in a field.  Component
+   relation constraints allow for the restriction of a field based on
+   contents of other fields in the type.
+
+2.2.1.  Simple Table Constraints
+
+   Simple table constraints are widely used in [RFC5911] and [RFC5912]
+   to limit implementer options (although the constraints are almost
+   always followed by or include extensibility markers, which make the
+   parameters serve as information not as limitations).  Table
+   constraints are defined in [CCITT.X682.2002].
+
+   Some ASN.1 compilers have the ability to use the simple table
+   constraint to check that a field contains one of the legal values.
+
+   The following example from [RFC5911] demonstrates using table
+   constraints to clarify the intended usage of a particular field.  The
+   parameters indicate the types of attributes that are typically found
+   in the signedAttrs and unsignedAttrs fields.  In this example, the
+   object sets are disjoint but this is not required.  For example, in
+   [RFC5912], there is some overlap between the CertExtensions and
+   CrlExtensions sets.
+
+   -- from updated RFC 5652 module in [RFC5911]
+   SignerInfo ::= SEQUENCE {
+       version CMSVersion,
+       sid SignerIdentifier,
+       digestAlgorithm DigestAlgorithmIdentifier,
+       signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
+       signatureAlgorithm SignatureAlgorithmIdentifier,
+       signature SignatureValue,
+       unsignedAttrs [1] IMPLICIT Attributes
+            {{UnsignedAttributes}} OPTIONAL }
+
+   SignedAttributes ::= Attributes {{ SignedAttributesSet }}
+
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 8]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   SignedAttributesSet ATTRIBUTE ::=
+          { aa-signingTime | aa-messageDigest | aa-contentType, ... }
+
+   UnsignedAttributes ATTRIBUTE ::= { aa-countersignature, ... }
+
+2.2.2.  Component Relation Constraints
+
+   Component relation constraints are often used to bind the type field
+   of an open type to the identifier field.  Using the binding in this
+   way allows a compiler to immediately decode the associated type when
+   the containing structure is defined.  The following example from
+   [RFC2560] as updated in [RFC5912] demonstrates this usage.
+
+   -- from updated RFC 2560 module in [RFC5912]
+   RESPONSE ::= TYPE-IDENTIFIER
+
+   ResponseSet RESPONSE ::= {basicResponse, ...}
+
+   ResponseBytes ::=       SEQUENCE {
+       responseType        RESPONSE.
+                               &id ({ResponseSet}),
+       response            OCTET STRING (CONTAINING RESPONSE.
+                               &Type({ResponseSet}{@responseType}))}
+
+   In this example, the response field is constrained to contain a type
+   identified by the responseType field.  The controlling field is
+   identified using atNotation, e.g., "@responseType". atNotation can be
+   defined relative to the outermost SEQUENCE, SET, or CHOICE or
+   relative to the field with which the atNotation is associated.  When
+   there is no '.' immediately after the '@', the field appears as a
+   member of the outermost SEQUENCE, SET, or CHOICE.  When there is a
+   '.' immediately after the '@', each '.' represents a SEQUENCE, SET,
+   or CHOICE starting with the SEQUENCE, SET, or CHOICE that contains
+   the field with which the atNotation is associated.  For example,
+   ResponseBytes could have been written as shown below.  In this case,
+   the syntax is very similar since the innermost and outermost
+   SEQUENCE, SET, or CHOICE are the same.
+
+   ResponseBytes ::=       SEQUENCE {
+       responseType        RESPONSE.
+                               &id ({ResponseSet}),
+       response            OCTET STRING (CONTAINING RESPONSE.
+                               &Type({ResponseSet}{@.responseType}))}
+
+   The TaggedRequest example from [RFC5912] provides an example where
+   the outermost and innermost SEQUENCE, SET, or CHOICE are different.
+   Relative to the atNotation included in the definition of the
+
+
+
+
+Wallace & Gardiner            Informational                     [Page 9]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   requestMessageValue field, the outermost SEQUENCE, SET, or CHOICE is
+   TaggedRequest, and the innermost is the SEQUENCE used to define the
+   orm field.
+
+   TaggedRequest ::= CHOICE {
+      tcr               [0] TaggedCertificationRequest,
+      crm               [1] CertReqMsg,
+      orm               [2] SEQUENCE {
+          bodyPartID            BodyPartID,
+          requestMessageType    OTHER-REQUEST.&id({OtherRequests}),
+          requestMessageValue   OTHER-REQUEST.&Type({OtherRequests}
+                                    {@.requestMessageType})
+      }
+   }
+
+   When referencing a field using atNotation, the definition of the
+   field must be included within the outermost SEQUENCE, SET, or CHOICE.
+   References to fields within structures that are defined separately
+   are not allowed.  For example, the following example includes invalid
+   atNotation in the definition of the signature field within the SIGNED
+   parameterized type.
+
+   AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
+             SEQUENCE {
+                 algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
+                 parameters  ALGORITHM-TYPE.
+                        &Params({AlgorithmSet}{@algorithm}) OPTIONAL
+             }
+
+   -- example containing invalid atNotation
+   SIGNED{ToBeSigned} ::= SEQUENCE {
+      toBeSigned           ToBeSigned,
+      algorithmIdentifier  AlgorithmIdentifier
+                               { SIGNATURE-ALGORITHM, {...}}
+      },
+      signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
+                               {SignatureAlgorithms}
+                               {@algorithmIdentifier.algorithm}))
+   }
+
+   Alternatively, the above example could be written with correct
+   atNotation as follows, with the definition of the algorithm field
+   included within ToBeSigned.
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 10]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+     SIGNED{ToBeSigned} ::= SEQUENCE {
+        toBeSigned           ToBeSigned,
+        algorithmIdentifier  SEQUENCE {
+            algorithm        SIGNATURE-ALGORITHM.
+                                 &id({SignatureAlgorithms}),
+            parameters       SIGNATURE-ALGORITHM.
+                                 &Params({SignatureAlgorithms}
+                                     {@algorithmIdentifier.algorithm})
+        },
+        signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
+                                 {SignatureAlgorithms}
+                                 {@algorithmIdentifier.algorithm}))
+     }
+
+   In the above example, the outermost SEQUENCE, SET, or CHOICE relative
+   to the parameters field is the SIGNED parameterized type.  The
+   innermost structure is the SEQUENCE used as the type for the
+   algorithmIdentifier field.  The atNotation for the parameters field
+   could be expressed using any of the following representations:
+
+      @algorithmIdentifier.algorithm
+
+      @.algorithm
+
+   The atNotation for the signature field has only one representation.
+
+2.2.3.  Content Constraints
+
+   Open types implemented as OCTET STRINGs or BIT STRINGs can be
+   constrained using the contents constraints syntax defined in
+   [CCITT.X682.2002].  Below are the revised definitions from [RFC5911]
+   and [RFC5912].  These show usage of OCTET STRING and BIT STRING along
+   with constrained sets of identifiers.  The Extension definition uses
+   a content constraint that requires the value of the OCTET STRING to
+   be an encoding of the type associated with the information object
+   selected from the ExtensionSet object set using the value of the
+   extnID field.  For reasons described in Section 2.2.2, "Component
+   Relation Constraints", the SubjectPublicKeyInfo definition relies on
+   prose to bind the BIT STRING to the type identifier because it is not
+   possible to express a content constraint that includes a component
+   relationship constraint to bind the type value within the algorithm
+   field to the subjectPublicKey field.
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 11]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   -- from updated RFC 5280 module in [RFC5912]
+   Extension{EXTENSION:ExtensionSet} ::= SEQUENCE {
+       extnID      EXTENSION.&id({ExtensionSet}),
+       critical    BOOLEAN
+       -- (EXTENSION.&Critical({ExtensionSet}{@extnID}))
+                          DEFAULT FALSE,
+       extnValue   OCTET STRING (CONTAINING
+                     EXTENSION.&ExtnType({ExtensionSet}{@extnID}))
+                     --  contains the DER encoding of the ASN.1 value
+                     --  corresponding to the extension type identified
+                     --  by extnID
+   }
+
+   SubjectPublicKeyInfo  ::=  SEQUENCE  {
+       algorithm            AlgorithmIdentifier{PUBLIC-KEY,
+                                {PublicKeyAlgorithms}},
+       subjectPublicKey     BIT STRING
+   }
+
+2.3.  Parameterization
+
+   Parameterization is defined in [CCITT.X683.2002] and can also be used
+   to define new types in a way similar to the macro notation described
+   in Annex A of X.208.  The following example from [RFC5912] shows this
+   usage.  The toBeSigned field takes the type passed as a parameter.
+
+   -- from [RFC5912]
+   SIGNED{ToBeSigned} ::= SEQUENCE {
+       toBeSigned  ToBeSigned,
+       algorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
+                       {SignatureAlgorithms}},
+       signature   BIT STRING
+   }
+
+   -- from updated RFC5280 module in [RFC5912]
+   Certificate  ::=  SIGNED{TBSCertificate}
+
+   Parameters need not be simple types.  The following example
+   demonstrates the usage of an information object class and an
+   information object set as parameters.  The first parameter in the
+   definition of AlgorithmIdentifier is an information object class.
+   Information object classes used for this parameter must have &id and
+   &Params fields, which determine the type of the algorithm and
+   parameters fields.  Other fields may be present in the information
+   object class, but they are not used by the definition of
+   AlgorithmIdentifier, as demonstrated by the SIGNATURE-ALGORITHM class
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 12]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   shown below.  The second parameter is an information object set that
+   is used to constrain the values that appear in the algorithm and
+   parameters fields.
+
+   -- from [RFC5912]
+   AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet}
+       ::= SEQUENCE
+   {
+       algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
+       parameters  ALGORITHM-TYPE.&Params
+                     ({AlgorithmSet}{@algorithm}) OPTIONAL
+   }
+
+   SIGNATURE-ALGORITHM ::= CLASS {
+       &id             OBJECT IDENTIFIER,
+       &Params         OPTIONAL,
+       &Value          OPTIONAL,
+       &paramPresence  ParamOptions DEFAULT absent,
+       &HashSet        DIGEST-ALGORITHM OPTIONAL,
+       &PublicKeySet   PUBLIC-KEY OPTIONAL,
+       &smimeCaps      SMIME-CAPS OPTIONAL
+   } WITH SYNTAX {
+       IDENTIFIER &id
+       [VALUE &Value]
+       [PARAMS [TYPE &Params] ARE &paramPresence ]
+       [HASHES &HashSet]
+       [PUBLIC KEYS &PublicKeySet]
+       [SMIME CAPS &smimeCaps]
+   }
+
+   -- from updated RFC 2560 module in [RFC5912]
+   BasicOCSPResponse       ::= SEQUENCE {
+       tbsResponseData      ResponseData,
+       signatureAlgorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
+                             {sa-dsaWithSHA1 | sa-rsaWithSHA1 |
+                                  sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
+       signature            BIT STRING,
+       certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
+   }
+
+2.4.  Versioning and Extensibility
+
+   Specifications are often revised and ASN.1 modules updated to include
+   new components.  [CCITT.X681.2002] provides two mechanisms useful in
+   supporting extensibility: extension markers and version brackets.
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 13]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+2.4.1.  Extension Markers
+
+   An extension marker is represented by an ellipsis (i.e., three
+   adjacent periods).  Extension markers are included in specifications
+   at points where the protocol designer anticipates future changes.
+   This can also be achieved by including EXTENSIBILITY IMPLIED in the
+   ASN.1 module definition.  EXTENSIBILITY IMPLIED is the equivalent to
+   including an extension marker in each type defined in the ASN.1
+   module.  Extensibility markers are used throughout [RFC5911] and
+   [RFC5912] where object sets are defined.  In other instances, the
+   updated modules retroactively added extension markers where fields
+   were added to an earlier version by an update, as shown in the
+   CertificateChoices example below.
+
+   Examples:
+
+   -- from updated RFC 3370 module in [RFC5911]
+   KeyAgreementAlgs KEY-AGREE ::= { kaa-esdh | kaa-ssdh, ...}
+
+   -- from updated RFC 5652 module in [RFC5911]
+   CertificateChoices ::= CHOICE {
+       certificate Certificate,
+       extendedCertificate [0] IMPLICIT ExtendedCertificate,
+            -- Obsolete
+       ...,
+       [[3: v1AttrCert [1] IMPLICIT AttributeCertificateV1]],
+            -- Obsolete
+       [[4: v2AttrCert [2] IMPLICIT AttributeCertificateV2]],
+       [[5: other      [3] IMPLICIT OtherCertificateFormat]]
+   }
+
+   Protocol designers should use extension markers within definitions
+   that are likely to change.  For example, extensibility markers should
+   be used when enumerating error values.
+
+2.4.2.  Version Brackets
+
+   Version brackets can be used to indicate features that are available
+   in later versions of an ASN.1 module but not in earlier versions.
+   [RFC5912] added version brackets to the definition of TBSCertificate
+   to illustrate the addition of the issuerUniqueID, subjectUniqueID,
+   and extensions fields, as shown below.
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 14]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   -- from updated RFC 5280 module in [RFC5912]
+   TBSCertificate  ::=  SEQUENCE  {
+       version         [0]  Version DEFAULT v1,
+       serialNumber         CertificateSerialNumber,
+       signature            AlgorithmIdentifier{SIGNATURE-ALGORITHM,
+                                 {SignatureAlgorithms}},
+       issuer               Name,
+       validity             Validity,
+       subject              Name,
+       subjectPublicKeyInfo SubjectPublicKeyInfo,
+       ... ,
+       [[2:               -- If present, version MUST be v2
+       issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
+       subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL
+       ]],
+       [[3:               -- If present, version MUST be v3 --
+       extensions      [3]  ExtensionSet{{CertExtensions}} OPTIONAL
+       ]], ... }
+
+3.  Character Set Differences
+
+   X.68s uses a character set that is a superset of the character set
+   defined in X.208.  The character set defined in X.208 includes the
+   following:
+
+      A to Z
+
+      a to z
+
+      0 to 9
+
+      :=,{}<.
+
+      ()[]-'"
+
+   The character set in X.68x additionally includes the following:
+
+      !&*/;>@^_|
+
+   The > and | characters can also be used in X.208 syntax in macro
+   definitions.
+
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 15]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+4.  ASN.1 Translation
+
+4.1.  Downgrading from X.68x to X.208
+
+   At a minimum, downgrading an ASN.1 module from X.68x syntax to X.208
+   requires the removal of features not supported by X.208.  As
+   indicated above, the features most commonly used in IETF Security
+   Area ASN.1 modules are information object classes (and object sets),
+   content constraints, parameterization, extension markers, and version
+   brackets.  Extension markers and version brackets can simply be
+   deleted (or commented out).  The definitions for information object
+   classes and object sets can also be deleted or commented out, as
+   these will not be used.  The following checklist can be used in most
+   cases:
+
+   o  Remove all Information Set Class, Information Set Object, and
+      Information Set Object Set definitions and imports from the file.
+
+   o  Replace all fixed Type Information Set Class element references
+      with the fixed type.  (That is, replace FOO.&id with OBJECT
+      IDENTIFIER.)
+
+   o  Delete all simple constraints.
+
+   o  Delete all CONTAINING statements.
+
+   o  Replace all variable Type Information Set Class element references
+      with either ANY or ANY DEFINED BY statements.
+
+   o  Remove version and extension markers.
+
+   o  Manually enforce all instances of parameterized types.
+
+4.2.  Upgrading from X.208 to X.68x
+
+   The amount of change associated with upgrading from X.208 syntax to
+   X.68x syntax is dependent on the reasons for changing and personal
+   style.  A minimalist approach could consist of altering any
+   deprecated features, most commonly ANY DEFINED BY, and adding any
+   necessary extensibility markers.  A more comprehensive approach may
+   include the introduction of constraints, parameterization,
+   versioning, extensibility, etc.
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 16]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   The following checklist can be used when upgrading a module without
+   introducing constraints:
+
+      Use TYPE-IDENTIFIER.&Type for "ANY".
+
+      Use TYPE-IDENTIFIER.&Type for "ANY DEFINED BY ...".
+
+   When constraints are introduced during an upgrade, additional steps
+   are necessary:
+
+   1.  Identify each unique class that should be defined based on what
+       types of things exist.
+
+   2.  Define an Information Object Class for each of the classes above
+       with the appropriate elements.
+
+   3.  Define all of the appropriate Information Object Sets based on
+       the classes defined in step 2 along with the different places
+       that they should be used.
+
+   4.  Replace ANY by the appropriate class and variable type element.
+
+   5.  Replace ANY DEFINED BY with the appropriate variable type element
+       and the components constraint.  Replace the element used in the
+       constraint with the appropriate fixed type element and simple
+       constraint.
+
+   6.  Add any simple constraints as appropriate.
+
+   7.  Define any objects and fill in elements for object sets as
+       appropriate.
+
+5.  Security Considerations
+
+   Where a module is downgraded from X.68x syntax to X.208 there is loss
+   of potential automated enforcement of constraints expressed by the
+   author of the module being downgraded.  These constraints should be
+   captured in prose or ASN.1 comments and enforced through other means,
+   as necessary.
+
+   Depending on the feature set of the ASN.1 compiler being used, the
+   code to enforce and use constraints may be generated automatically or
+   may require the programmer to do this independently.  It is the
+   responsibility of the programmer to ensure that the constraints on
+   the ASN.1 expressed either in prose or in the ASN.1 module are
+   actually enforced.
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 17]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+6.  References
+
+6.1.  Normative References
+
+   [CCITT.X208.1988]  International Telephone and Telegraph Consultative
+                      Committee, "Specification of Abstract Syntax
+                      Notation One (ASN.1)", CCITT Recommendation X.208,
+                      November 1988.
+
+   [CCITT.X680.2002]  International Telephone and Telegraph Consultative
+                      Committee, "Abstract Syntax Notation One (ASN.1):
+                      Specification of basic notation",
+                      CCITT Recommendation X.680, July 2002.
+
+   [CCITT.X681.2002]  International Telephone and Telegraph Consultative
+                      Committee, "Abstract Syntax Notation One (ASN.1):
+                      Information object specification",
+                      CCITT Recommendation X.681, July 2002.
+
+   [CCITT.X682.2002]  International Telephone and Telegraph Consultative
+                      Committee, "Abstract Syntax Notation One (ASN.1):
+                      Constraint specification", CCITT Recommendation
+                      X.682, July 2002.
+
+   [CCITT.X683.2002]  International Telephone and Telegraph Consultative
+                      Committee, "Abstract Syntax Notation One (ASN.1):
+                      Parameterization of ASN.1 specifications",
+                      CCITT Recommendation X.683, July 2002.
+
+6.2.  Informative References
+
+   [CCITT.X209.1988]  International Telephone and Telegraph Consultative
+                      Committee, "Specification of Basic Encoding Rules
+                      for Abstract Syntax Notation One (ASN.1)",
+                      CCITT Recommendation X.209, 1988.
+
+   [CCITT.X690.2002]  International Telephone and Telegraph Consultative
+                      Committee, "ASN.1 encoding rules: Specification of
+                      basic encoding Rules (BER), Canonical encoding
+                      rules (CER) and Distinguished encoding rules
+                      (DER)", CCITT Recommendation X.690, July 2002.
+
+   [RFC2560]          Myers, M., Ankney, R., Malpani, A., Galperin, S.,
+                      and C. Adams, "X.509 Internet Public Key
+                      Infrastructure Online Certificate Status Protocol
+                      - OCSP", RFC 2560, June 1999.
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 18]
+
+RFC 6025                    ASN.1 Translation               October 2010
+
+
+   [RFC5280]          Cooper, D., Santesson, S., Farrell, S., Boeyen,
+                      S., Housley, R., and W. Polk, "Internet X.509
+                      Public Key Infrastructure Certificate and
+                      Certificate Revocation List (CRL) Profile",
+                      RFC 5280, May 2008.
+
+   [RFC5652]          Housley, R., "Cryptographic Message Syntax (CMS)",
+                      STD 70, RFC 5652, September 2009.
+
+   [RFC5911]          Hoffman, P. and J. Schaad, "New ASN.1 Modules for
+                      Cryptographic Message Syntax (CMS) and S/MIME",
+                      RFC 5911, June 2010.
+
+   [RFC5912]          Hoffman, P. and J. Schaad, "New ASN.1 Modules for
+                      the Public Key Infrastructure Using X.509 (PKIX)",
+                      RFC 5912, June 2010.
+
+Authors' Addresses
+
+   Carl Wallace
+   Cygnacom Solutions
+   Suite 5400
+   7925 Jones Branch Drive
+   McLean, VA  22102
+
+   EMail: cwallace@cygnacom.com
+
+
+   Charles Gardiner
+   BBN Technologies
+   10 Moulton Street
+   Cambridge, MA  02138
+
+   EMail: gardiner@bbn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wallace & Gardiner            Informational                    [Page 19]
+