Network Working Group                                         C. Wallace
Internet-Draft                                        Cygnacom Solutions
Intended status: Informational                               C. Gardiner
Expires: November 27, 2009                              BBN Technologies
                                                            May 26, 2009


                           ASN.1 Translation
                  draft-ietf-pkix-asn1-translation-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 27, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.








Wallace & Gardiner      Expires November 27, 2009               [Page 1]

Internet-Draft              ASN.1 Translation                   May 2009


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 written using 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 focus on items that vary
   with the ASN.1 version.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  ASN.1 design elements  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Open types . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  ANY DEFINED BY . . . . . . . . . . . . . . . . . . . .  4
       2.1.2.  OCTET STRINGs and BIT STRINGs  . . . . . . . . . . . .  4
       2.1.3.  Information Object Classes . . . . . . . . . . . . . .  5
     2.2.  Constraints  . . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.1.  Simple table constraints . . . . . . . . . . . . . . .  8
       2.2.2.  Component relation constraints . . . . . . . . . . . .  8
       2.2.3.  Content constraints  . . . . . . . . . . . . . . . . . 11
     2.3.  Parameterization . . . . . . . . . . . . . . . . . . . . . 12
     2.4.  Versioning and Extensibility . . . . . . . . . . . . . . . 14
       2.4.1.  Extension markers  . . . . . . . . . . . . . . . . . . 14
       2.4.2.  Version brackets . . . . . . . . . . . . . . . . . . . 14
   3.  Character set differences  . . . . . . . . . . . . . . . . . . 16
   4.  ASN.1 translation  . . . . . . . . . . . . . . . . . . . . . . 17
     4.1.  Downgrading from X.68x to X.208  . . . . . . . . . . . . . 17
     4.2.  Upgrading from X.208 to X.68x  . . . . . . . . . . . . . . 17
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22








Wallace & Gardiner      Expires November 27, 2009               [Page 2]

Internet-Draft              ASN.1 Translation                   May 2009


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
   [I-D.ietf-pkix-new-asn1] and [I-D.ietf-smime-new-asn1], 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.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document addresses two different versions of ASN.1.  One version
   is defined in a single document (X.208) and the other 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.

























Wallace & Gardiner      Expires November 27, 2009               [Page 3]

Internet-Draft              ASN.1 Translation                   May 2009


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
   [I-D.ietf-pkix-new-asn1] and [I-D.ietf-smime-new-asn1] 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 are available in X.208, X.68x or
   both to accommodate this practice, as described below.

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 [RFC3852], 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.  However, X.208
   does not provide a means for establishing a relationship between a
   type and the type identifier.


   -- from RFC 3852
   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 }


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.  The definitions of Extension and
   SubjectPublicKeyInfo in [RFC5280] demonstrate the usage of OCTET



Wallace & Gardiner      Expires November 27, 2009               [Page 4]

Internet-Draft              ASN.1 Translation                   May 2009


   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 indicates 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].  These
   serve to allow protocol designers to express the types of information
   associated with a particular data type.  The TYPE-IDENTIFIER
   information object, defined in Annex A of [CCITT.X681.2002], provides
   a basic information object that associates an identifier with a data



Wallace & Gardiner      Expires November 27, 2009               [Page 5]

Internet-Draft              ASN.1 Translation                   May 2009


   type.  [I-D.ietf-smime-new-asn1] 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 3852 module in [I-D.ietf-smime-new-asn1]
   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}



   This example illustrates the following:

   o  Definition of an information object class: TYPE-IDENITIFIER 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.





Wallace & Gardiner      Expires November 27, 2009               [Page 6]

Internet-Draft              ASN.1 Translation                   May 2009


   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 not using 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 the Versioning and Extensibility section below).

   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


   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







Wallace & Gardiner      Expires November 27, 2009               [Page 7]

Internet-Draft              ASN.1 Translation                   May 2009


2.2.1.  Simple table constraints

   Simple table constraints are widely used in [I-D.ietf-pkix-new-asn1]
   and [I-D.ietf-smime-new-asn1] to limit implementor options (although
   the constraints are almost always followed by or include
   extensibility markers making the parameters serve an informational
   purpose not as a limitation).  Table constraints are defined in
   [CCITT.X682.2002].

   The following example from [I-D.ietf-smime-new-asn1] provides two
   examples of 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 [I-D.ietf-pkix-new-asn1], there is some
   overlap between the CertExtensions and CrlExtensions sets.


   -- from updated RFC 3852 module in [I-D.ietf-smime-new-asn1]
   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 }}

   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.  The following example from
   [RFC2560] as updated [I-D.ietf-pkix-new-asn1] demonstrates this
   usage.







Wallace & Gardiner      Expires November 27, 2009               [Page 8]

Internet-Draft              ASN.1 Translation                   May 2009


   -- from updated RFC 2560 module in [I-D.ietf-pkix-new-asn1]
   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 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 [I-D.ietf-pkix-new-asn1] provides an
   example where the outermost and innermost SEQUENCE, SET or CHOICE are
   different.  Relative to the atNotation included in the definition of
   the requestMessageValue field, the outermost SEQUENCE, SET or CHOICE
   is TaggedRequest and the innermost is the SEQUENCE used to define the
   orm field.











Wallace & Gardiner      Expires November 27, 2009               [Page 9]

Internet-Draft              ASN.1 Translation                   May 2009


   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 defintion of the signed field of ToBeSigned.


   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}))
   }


   The above example could be alternatively written with correct
   atNotation as follows, with the definition of the algorithm field
   included within ToBeSigned.










Wallace & Gardiner      Expires November 27, 2009              [Page 10]

Internet-Draft              ASN.1 Translation                   May 2009


     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 structure named ToBeSigned.  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 contents constraints syntax defined in
   [CCITT.X682.2002].  Below are the revised definitions from
   [I-D.ietf-pkix-new-asn1] and [I-D.ietf-smime-new-asn1].  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 the type
   associated with the information object selected from the ExtensionSet
   object set using the value of the extnID field.  For reasons
   described above in the "Component relation constraints" section, 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      Expires November 27, 2009              [Page 11]

Internet-Draft              ASN.1 Translation                   May 2009


   -- from updated RFC 5280 module in [I-D.ietf-pkix-new-asn1]
   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 encding 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
   [I-D.ietf-pkix-new-asn1] shows this usage.  The toBeSigned field
   takes the type passed as a parameter.


   -- from [I-D.ietf-pkix-new-asn1]
   SIGNED{ToBeSigned} ::= SEQUENCE {
       toBeSigned  ToBeSigned,
       algorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
                       {SignatureAlgorithms}},
       signature   BIT STRING
   }

   -- from updated RFC5280 module in [I-D.ietf-pkix-new-asn1]
   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



Wallace & Gardiner      Expires November 27, 2009              [Page 12]

Internet-Draft              ASN.1 Translation                   May 2009


   object class but they are not used by the definition of
   AlgorithmIdentifier, as demonstrated by the the SIGNATURE-ALGORITHM
   class 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 [I-D.ietf-pkix-new-asn1]
   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 [I-D.ietf-pkix-new-asn1]
   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
   }









Wallace & Gardiner      Expires November 27, 2009              [Page 13]

Internet-Draft              ASN.1 Translation                   May 2009


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.

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
   [I-D.ietf-pkix-new-asn1] and [I-D.ietf-smime-new-asn1] 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
   KeyAgreementAlgs KEY-AGREE ::= { kaa-esdh | kaa-ssdh, ...}

   -- from updated RFC 3852
   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.



Wallace & Gardiner      Expires November 27, 2009              [Page 14]

Internet-Draft              ASN.1 Translation                   May 2009


   [I-D.ietf-pkix-new-asn1] added version brackets to the definition of
   TBSCertificate to illustrate the addition of the issuerUniqueID,
   subjectUniqueID and extensions fields, as shown below.


   -- from updated RFC 5280 module in [I-D.ietf-pkix-new-asn1]
   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
       ]], ... }




























Wallace & Gardiner      Expires November 27, 2009              [Page 15]

Internet-Draft              ASN.1 Translation                   May 2009


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 is additionally includes the following:

      !&*/;>@^_|

   The > and | characters can also be used in X.208 syntax in macro
   defnintions.





























Wallace & Gardiner      Expires November 27, 2009              [Page 16]

Internet-Draft              ASN.1 Translation                   May 2009


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, version brackets and extension
   markers.  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.

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 of the introduction of constraints, parameterization,
   versioning, extensibility, etc.




























Wallace & Gardiner      Expires November 27, 2009              [Page 17]

Internet-Draft              ASN.1 Translation                   May 2009


5.  IANA Considerations

   There are no IANA considerations.  Please delete this section prior
   to RFC publication.















































Wallace & Gardiner      Expires November 27, 2009              [Page 18]

Internet-Draft              ASN.1 Translation                   May 2009


6.  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.












































Wallace & Gardiner      Expires November 27, 2009              [Page 19]

Internet-Draft              ASN.1 Translation                   May 2009


7.  References

7.1.  Normative References

   [CCITT.X208.1988]
              International International Telephone and Telegraph
              Consultative Committee, "Specification of Abstract Syntax
              Notation One (ASN.1)", CCITT Recommendation X.208,
              November 1988.

   [CCITT.X680.2002]
              International 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 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 International Telephone and Telegraph
              Consultative Committee, "Abstract Syntax Notation One
              (ASN.1): Constraint specification", CCITT Recommendation
              X.682, July 2002.

   [CCITT.X683.2002]
              International International Telephone and Telegraph
              Consultative Committee, "Abstract Syntax Notation One
              (ASN.1): Parameterization of ASN.1 specifications",
              CCITT Recommendation X.683, July 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.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 International Telephone and Telegraph
              Consultative Committee, "ASN.1 encoding rules:



Wallace & Gardiner      Expires November 27, 2009              [Page 20]

Internet-Draft              ASN.1 Translation                   May 2009


              Specification of basic encoding Rules (BER), Canonical
              encoding rules (CER) and Distinguished encoding rules
              (DER)", CCITT Recommendation X.690, July 2002.

   [I-D.ietf-pkix-new-asn1]
              Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX",
              draft-ietf-pkix-new-asn1-05 (work in progress),
              April 2009.

   [I-D.ietf-smime-new-asn1]
              Hoffman, P. and J. Schaad, "New ASN.1 Modules for CMS and
              S/MIME", draft-ietf-smime-new-asn1-05 (work in progress),
              April 2009.

   [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.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [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.


























Wallace & Gardiner      Expires November 27, 2009              [Page 21]

Internet-Draft              ASN.1 Translation                   May 2009


Authors' Addresses

   Carl Wallace
   Cygnacom Solutions
   Suite 5200
   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      Expires November 27, 2009              [Page 22]