Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2459

Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Pages: 129
Obsoleted by:  3280
Part 3 of 4 – Pages 52 to 90
First   Prev   Next

ToP   noToC   RFC2459 - Page 52   prevText
6  Certification Path Validation

   Certification path validation procedures for the Internet PKI are
   based on section 12.4.3 of [X.509].  Certification path processing
   verifies the binding between the subject distinguished name and/or
   subject alternative name and subject public key.  The binding is
   limited by constraints which are specified in the certificates which
   comprise the path. The basic constraints and policy constraints
   extensions allow the certification path processing logic to automate
   the decision making process.

   This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST be functionally
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result.

   In section 6.1, the text describes basic path validation. This text
   assumes that all valid paths begin with certificates issued by a
   single "most-trusted CA". The algorithm requires the public key of
   the CA, the CA's name, the validity period of the public key, and any
   constraints upon the set of paths which may be validated using this
   key.

   The "most-trusted CA" is a matter of policy: it could be a root CA in
   a hierarchical PKI; the CA that issued the verifier's own
   certificate(s); or any other CA in a network PKI.  The path
   validation procedure is the same regardless of the choice of "most-
   trusted CA."

   section 6.2 describes extensions to the basic path validation
   algorithm. Two specific cases are discussed: the case where paths may
   begin with one of several trusted CAs; and where compatibility with
   the PEM architecture is required.

6.1 Basic Path Validation

   The text assumes that the trusted public key (and related
   information) is contained in a "self-signed" certificate. This
   simplifies the description of the path processing procedure.  Note
   that the signature on the self-signed certificate does not provide
   any security services.  The trusted public key (and related
   information) may be obtained in other formats; the information is
   trusted because of other procedures used to obtain and protect it.
ToP   noToC   RFC2459 - Page 53
   The goal of path validation is to verify the binding between a
   subject distinguished name or subject alternative name and subject
   public key, as represented in the "end entity" certificate, based on
   the public key of the "most-trusted CA".  This requires obtaining a
   sequence of certificates that support that binding.  The procedures
   performed to obtain this sequence is outside the scope of this
   section.

   The following text also assumes that certificates do not use subject
   or unique identifier fields or private critical extensions, as
   recommended within this profile.  However, if these components appear
   in certificates, they MUST be processed.  Finally, policy qualifiers
   are also neglected for the sake of clarity.

   A certification path is a sequence of n certificates where:

      * for all x in {1,(n-1)}, the subject of certificate x is the
      issuer of certificate x+1.
      * certificate x=1 is the the self-signed certificate, and
      * certificate x=n is the end entity certificate.

   This section assumes the following inputs are provided to the path
   processing logic:

      (a)  a certification path of length n;

      (b)  a set of initial policy identifiers (each comprising a
      sequence of policy element identifiers), which identifies one or
      more certificate policies, any one of which would be acceptable
      for the purposes of certification path processing, or the special
      value "any-policy";

      (c)  the current date/time (if not available internally to the
      certification path processing module); and

      (d)  the time, T, for which the validity of the path should be
      determined.  (This may be the current date/time, or some point in
      the past.)

   From the inputs, the procedure intializes five state variables:

      (a)  acceptable policy set:  A set of certificate policy
      identifiers comprising the policy or policies recognized by the
      public key user together with policies deemed equivalent through
      policy mapping. The initial value of the acceptable policy set is
      the special value "any-policy".
ToP   noToC   RFC2459 - Page 54
      (b)  constrained subtrees:  A set of root names defining a set of
      subtrees within which all subject names in subsequent certificates
      in the certification path shall fall. The initial value is
      "unbounded".

      (c)  excluded subtrees:  A set of root names defining a set of
      subtrees within which no subject name in subsequent certificates
      in the certification path may fall. The initial value is "empty".

      (d)  explicit policy: an integer which indicates if an explicit
      policy identifier is required. The integer indicates the first
      certificate in the path where this requirement is imposed. Once
      set, this variable may be decreased, but may not be increased.
      (That is, if a certificate in the path requires explicit policy
      identifiers, a later certificate can not remove this requirement.)
      The initial value is n+1.

      (e)  policy mapping: an integer which indicates if policy mapping
      is permitted.  The integer indicates the last certificate on which
      policy mapping may be applied.  Once set, this variable may be
      decreased, but may not be increased. (That is, if a certificate in
      the path specifies policy mapping is not permitted, it can not be
      overriden by a later certificate.) The initial value is n+1.

   The actions performed by the path processing software for each
   certificate i=1 through n are described below.  The self-signed
   certificate is certificate i=1, the end entity certificate is i=n.
   The processing is performed sequentially, so that processing
   certificate i affects the state variables for processing certificate
   (i+1). Note that actions (h) through (m) are not applied to the end
   entity certificate (certificate n).

   The path processing actions to be performed are:

      (a)  Verify the basic certificate information, including:

         (1) the certificate was signed using the subject public key
         from certificate i-1 (in the special case i=1, this step may be
         omitted; if not, use the subject public key from the same
         certificate),

         (2) the certificate validity period includes time T,

         (3) the certificate had not been revoked at time T and is not
         currently on hold status that commenced before time T, (this
         may be determined by obtaining the appropriate CRL or status
         information, or by out-of-band mechanisms), and
ToP   noToC   RFC2459 - Page 55
         (4) the subject and issuer names chain correctly (that is, the
         issuer of this certificate was the subject of the previous
         certificate.)

      (b)  Verify that the subject name and subjectAltName extension
      (critical or noncritical) is consistent with the constrained
      subtrees state variables.

      (c)  Verify that the subject name and subjectAltName extension
      (critical or noncritical) is consistent with the excluded subtrees
      state variables.

      (d)  Verify that policy information is consistent with the initial
      policy set:

         (1) if the explicit policy state variable is less than or equal
         to i, a policy identifier in the certificate shall be in the
         initial policy set; and

         (2) if the policy mapping variable is less than or equal to i,
         the policy identifier may not be mapped.

      (e)  Verify that policy information is consistent with the
      acceptable policy set:

         (1) if the certificate policies extension is marked critical,
         the intersection of the policies extension and the acceptable
         policy set shall be non-null;

         (2) the acceptable policy set is assigned the resulting
         intersection as its new value.

      (g) Verify that the intersection of the acceptable policy set and
      the initial policy set is non-null.

      (h)  Recognize and process any other critical extension present in
      the certificate.

      (i) Verify that the certificate is a CA certificate (as specified
      in a basicConstraints extension or as verified out-of-band).

      (j)  If permittedSubtrees is present in the certificate, set the
      constrained subtrees state variable to the intersection of its
      previous value and the value indicated in the extension field.

      (k)  If excludedSubtrees is present in the certificate, set the
      excluded subtrees state variable to the union of its previous
      value and the value indicated in the extension field.
ToP   noToC   RFC2459 - Page 56
      (l)  If a policy constraints extension is included in the
      certificate, modify the explicit policy and policy mapping state
      variables as follows:

         (1) If requireExplicitPolicy is present and has value r, the
         explicit policy state variable is set to the minimum of its
         current value and the sum of r and i (the current certificate
         in the sequence).

         (2) If inhibitPolicyMapping is present and has value q, the
         policy mapping state variable is set to the minimum of its
         current value and the sum of q and i (the current certificate
         in the sequence).

      (m) If a key usage extension is marked critical, ensure the
      keyCertSign bit is set.

   If any one of the above checks fail, the procedure terminates,
   returning a failure indication and an appropriate reason.  If none of
   the above checks fail on the end-entity certificate, the procedure
   terminates, returning a success indication together with the set of
   all policy qualifier values encountered in the set of certificates.

6.2 Extending Path Validation

   The path validation algorithm presented in 6.1 is based on several
   simplifying assumptions (e.g., a single trusted CA that starts all
   valid paths). This algorithm may be extended for cases where the
   assumptions do not hold.

   This procedure may be extended for multiple trusted CAs by providing
   a set of self-signed certificates to the validation module.  In this
   case, a valid path could begin with any one of the self-signed
   certificates.  Limitations in the trust paths for any particular key
   may be incorporated into the self-signed certificate's extensions. In
   this way, the self-signed certificates permit the path validation
   module to automatically incorporate local security policy and
   requirements.

   It is also possible to specify an extended version of the above
   certification path processing procedure which results in default
   behavior identical to the rules of PEM [RFC 1422].  In this extended
   version, additional inputs to the procedure are a list of one or more
   Policy Certification Authorities (PCAs) names and an indicator of the
   position in the certification path where the PCA is expected.  At the
   nominated PCA position, the CA name is compared against this list.
   If a recognized PCA name is found, then a constraint of
   SubordinateToCA is implicitly assumed for the remainder of the
ToP   noToC   RFC2459 - Page 57
   certification path and processing continues.  If no valid PCA name is
   found, and if the certification path cannot be validated on the basis
   of identified policies, then the certification path is considered
   invalid.

7  Algorithm Support

   This section describes cryptographic algorithms which may be used
   with this profile.  The section describes one-way hash functions and
   digital signature algorithms which may be used to sign certificates
   and CRLs, and identifies OIDs for public keys contained in a
   certificate.

   Conforming CAs and applications are not required to support the
   algorithms or algorithm identifiers described in this section.
   However, conforming CAs and applications that use the algorithms
   identified here MUST support them as specified.

7.1  One-way Hash Functions

   This section identifies one-way hash functions for use in the
   Internet PKI.  One-way hash functions are also called message digest
   algorithms. SHA-1 is the preferred one-way hash function for the
   Internet PKI.  However, PEM uses MD2 for certificates [RFC 1422] [RFC
   1423] and MD5 is used in other legacy applications.  For this reason,
   MD2 and MD5 are included in this profile.

7.1.1  MD2 One-way Hash Function

   MD2 was developed by Ron Rivest for RSA Data Security. RSA Data
   Security has not placed the MD2 algorithm in the public domain.
   Rather, RSA Data Security has granted license to use MD2 for non-
   commercial Internet Privacy-Enhanced Mail.  For this reason, MD2 may
   continue to be used with PEM certificates, but SHA-1 is preferred.
   MD2 produces a 128-bit "hash" of the input.  MD2 is fully described
   in RFC 1319 [RFC 1319].

   At the Selected Areas in Cryptography '95 conference in May 1995,
   Rogier and Chauvaud presented an attack on MD2 that can nearly find
   collisions [RC95].  Collisions occur when one can find two different
   messages that generate the same message digest.  A checksum operation
   in MD2 is the only remaining obstacle to the success of the attack.
   For this reason, the use of MD2 for new applications is discouraged.
   It is still reasonable to use MD2 to verify existing signatures, as
   the ability to find collisions in MD2 does not enable an attacker to
   find new messages having a previously computed hash value.
ToP   noToC   RFC2459 - Page 58
7.1.2  MD5 One-way Hash Function

   MD5 was developed by Ron Rivest for RSA Data Security. RSA Data
   Security has placed the MD5 algorithm in the public domain.  MD5
   produces a 128-bit "hash" of the input.  MD5 is fully described in
   RFC 1321 [RFC 1321].

   Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
   but there are no other known cryptanalytic results.  The use of MD5
   for new applications is discouraged.  It is still reasonable to use
   MD5 to verify existing signatures.

7.1.3  SHA-1 One-way Hash Function

   SHA-1 was developed by the U.S. Government.  SHA-1 produces a 160-bit
   "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS
   180-1].

   SHA-1 is the one-way hash function of choice for use with both the
   RSA and DSA signature algorithms (see sec. 7.2).

7.2  Signature Algorithms

   Certificates and CRLs described by this standard may be signed with
   any public key signature algorithm.  The certificate or CRL indicates
   the algorithm through an algorithm identifier which appears in the
   signatureAlgorithm field in a Certificate or CertificateList.  This
   algorithm identifier is an OID and has optionally associated
   parameters.  This section identifies algorithm identifiers and
   parameters that shall be used in the signatureAlgorithm field in a
   Certificate or CertificateList.

   RSA and DSA are the most popular signature algorithms used in the
   Internet.  Signature algorithms are always used in conjunction with a
   one-way hash function identified in section 7.1.

   The signature algorithm and one-way hash function used to sign a
   certificate or CRL is indicated by use of an algorithm identifier.
   An algorithm identifier is an OID, and may include associated
   parameters.  This section identifies OIDS for RSA and DSA.  The
   contents of the parameters component for each algorithm vary; details
   are provided for each algorithm.

   The data to be signed (e.g., the one-way hash function output value)
   is formatted for the signature algorithm to be used.  Then, a private
   key operation (e.g., RSA encryption) is performed to generate the
ToP   noToC   RFC2459 - Page 59
   signature value.  This signature value is then ASN.1 encoded as a BIT
   STRING and included in the Certificate or CertificateList in the
   signature field.

7.2.1  RSA Signature Algorithm

   A patent statement regarding the RSA algorithm can be found at the
   end of this profile.

   The RSA algorithm is named for its inventors: Rivest, Shamir, and
   Adleman.  This profile includes three signature algorithms based on
   the RSA asymmetric encryption algorithm. The signature algorithms
   combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
   functions.

   The signature algorithm with MD2 and the RSA encryption algorithm is
   defined in PKCS #1 [RFC 2313].  As defined in RFC 2313, the ASN.1 OID
   used to identify this signature algorithm is:

        md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs-1(1) 2  }

   The signature algorithm with MD5 and the RSA encryption algorithm is
   defined in PKCS #1 [RFC 2313].  As defined in RFC 2313, the ASN.1 OID
   used to identify this signature algorithm is:

        md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs-1(1) 4  }

   The signature algorithm with SHA-1 and the RSA encryption algorithm
   is implemented using the padding and encoding conventions described
   in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
   hash algorithm.  The ASN.1 object identifier used to identify this
   signature algorithm is:

        sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
            pkcs-1(1) 5  }

   When any of these three OIDs appears within the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type shall be
   the ASN.1 type NULL.

   The RSA signature generation process and the encoding of the result
   is described in detail in RFC 2313.
ToP   noToC   RFC2459 - Page 60
7.2.2  DSA Signature Algorithm

   A patent statement regarding the DSA can be found at the end of this
   profile.

   The Digital Signature Algorithm (DSA) is also called the Digital
   Signature Standard (DSS).  DSA was developed by the U.S. Government,
   and DSA is used in conjunction with the the SHA-1 one-way hash
   function.  DSA is fully described in FIPS 186 [FIPS 186].  The ASN.1
   OIDs used to identify this signature algorithm are:

           id-dsa-with-sha1 ID  ::=  {
                   iso(1) member-body(2) us(840) x9-57 (10040)
                   x9cm(4) 3 }

   Where the id-dsa-with-sha1 algorithm identifier appears as the
   algorithm field in an AlgorithmIdentifier, the encoding shall omit
   the parameters field.  That is, the AlgorithmIdentifier shall be a
   SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1.

   The DSA parameters in the subjectPublicKeyInfo field of the
   certificate of the issuer shall apply to the verification of the
   signature.

   When signing, the DSA algorithm generates two values.  These values
   are commonly referred to as r and s.  To easily transfer these two
   values as one signature, they shall be ASN.1 encoded using the
   following ASN.1 structure:

           Dss-Sig-Value  ::=  SEQUENCE  {
                   r       INTEGER,
                   s       INTEGER  }

7.3  Subject Public Key Algorithms

   Certificates described by this profile may convey a public key for
   any public key algorithm. The certificate indicates the algorithm
   through an algorithm identifier.  This algorithm identifier is an OID
   and optionally associated parameters.

   This section identifies preferred OIDs and parameters for the RSA,
   DSA, and Diffie-Hellman algorithms.  Conforming CAs shall use the
   identified OIDs when issuing certificates containing public keys for
   these algorithms. Conforming applications supporting any of these
   algorithms shall, at a minimum, recognize the OID identified in this
   section.
ToP   noToC   RFC2459 - Page 61
7.3.1  RSA Keys

   The OID rsaEncryption identifies RSA public keys.

        pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                       rsadsi(113549) pkcs(1) 1 }

        rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

   The rsaEncryption OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier. The parameters field shall
   have ASN.1 type NULL for this algorithm identifier.

   The RSA public key shall be encoded using the ASN.1 type
   RSAPublicKey:

      RSAPublicKey ::= SEQUENCE {
         modulus            INTEGER, -- n
         publicExponent     INTEGER  -- e -- }

   where modulus is the modulus n, and publicExponent is the public
   exponent e.  The DER encoded RSAPublicKey is the value of the BIT
   STRING subjectPublicKey.

   This OID is used in public key certificates for both RSA signature
   keys and RSA encryption keys. The intended application for the key
   may be indicated in the key usage field (see sec. 4.2.1.3).  The use
   of a single key for both signature and encryption purposes is not
   recommended, but is not forbidden.

   If the keyUsage extension is present in an end entity certificate
   which conveys an RSA public key, any combination of the following
   values may be present:  digitalSignature; nonRepudiation;
   keyEncipherment; and dataEncipherment.  If the keyUsage extension is
   present in a CA certificate which conveys an RSA public key, any
   combination of the following values may be present:
   digitalSignature; nonRepudiation; keyEncipherment; dataEncipherment;
   keyCertSign; and cRLSign.  However, this specification RECOMMENDS
   that if keyCertSign or cRLSign is present, both keyEncipherment and
   dataEncipherment should not be present.

7.3.2  Diffie-Hellman Key Exchange Key

   The Diffie-Hellman OID supported by this profile is defined by ANSI
   X9.42 [X9.42].

        dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                  us(840) ansi-x942(10046) number-type(2) 1 }
ToP   noToC   RFC2459 - Page 62
   The dhpublicnumber OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier. The parameters field of that
   type, which has the algorithm-specific syntax ANY DEFINED BY
   algorithm, have the ASN.1 type DomainParameters for this algorithm.

        DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

        ValidationParms ::= SEQUENCE {
              seed             BIT STRING,
              pgenCounter      INTEGER }

   The fields of type DomainParameters have the following meanings:

      p identifies the prime p defining the Galois field;

      g specifies the generator of the multiplicative subgroup of order
      g;

      q specifies the prime factor of p-1;

      j optionally specifies the value that satisfies the equation
      p=jq+1 to support the optional verification of group parameters;

      seed optionally specifies the bit string parameter used as the
      seed for the system parameter generation process; and

      pgenCounter optionally specifies the integer value output as part
      of the of the system parameter prime generation process.

   If either of the parameter generation components (pgencounter or
   seed) is provided, the other shall be present as well.

   The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER;
   this encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo
   data element.

      DHPublicKey ::= INTEGER -- public key, y = g^x mod p
ToP   noToC   RFC2459 - Page 63
   If the keyUsage extension is present in a certificate which conveys a
   DH public key, the following values may be present:  keyAgreement;
   encipherOnly; and decipherOnly.  At most one of encipherOnly and
   decipherOnly shall be asserted in keyUsage extension.

7.3.3  DSA Signature Keys

   The Digital Signature Algorithm (DSA) is also known as the Digital
   Signature Standard (DSS). The DSA OID supported by this profile is

        id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
                  x9cm(4) 1 }

   The id-dsa algorithm syntax includes optional parameters.  These
   parameters are commonly referred to as p, q, and g.  When omitted,
   the parameters component shall be omitted entirely. That is, the
   AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT
   IDENTIFIER id-dsa.

   If the DSA algorithm parameters are present in the
   subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included
   using the following ASN.1 structure:

        Dss-Parms  ::=  SEQUENCE  {
            p             INTEGER,
            q             INTEGER,
            g             INTEGER  }


   If the DSA algorithm parameters are absent from the
   subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using DSA, then the certificate issuer's DSA
   parameters apply to the subject's DSA key.  If the DSA algorithm
   parameters are absent from the subjectPublicKeyInfo
   AlgorithmIdentifier and the CA signed the subject certificate using a
   signature algorithm other than DSA, then the subject's DSA parameters
   are distributed by other means.  If the subjectPublicKeyInfo
   AlgorithmIdentifier field omits the parameters component and the CA
   signed the subject with a signature algorithm other than DSA, then
   clients shall reject the certificate.

   When signing, DSA algorithm generates two values.  These values are
   commonly referred to as r and s.  To easily transfer these two values
   as one signature, they are ASN.1 encoded using the following ASN.1
   structure:
ToP   noToC   RFC2459 - Page 64
        Dss-Sig-Value  ::=  SEQUENCE  {
            r             INTEGER,
            s             INTEGER  }

   The encoded signature is conveyed as the value of the BIT STRING
   signature in a Certificate or CertificateList.

   The DSA public key shall be ASN.1 DER encoded as an INTEGER; this
   encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

        DSAPublicKey ::= INTEGER -- public key, Y

   If the keyUsage extension is present in an end entity certificate
   which conveys a DSA public key, any combination of the following
   values may be present:  digitalSignature; and nonRepudiation.

   If the keyUsage extension is present in an CA certificate which
   conveys a DSA public key, any combination of the following values may
   be present:  digitalSignature; nonRepudiation; keyCertSign; and
   cRLSign.

8 References

   [FIPS 180-1]  Federal Information Processing Standards Publication
                 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
                 [Supersedes FIPS PUB 180 dated 11 May 1993.]

   [FIPS 186]    Federal Information Processing Standards Publication
                 (FIPS PUB) 186, Digital Signature Standard, 18 May
                 1994.

   [RC95]        Rogier, N. and Chauvaud, P., "The compression function
                 of MD2 is not collision free," Presented at Selected
                 Areas in Cryptography '95, May 1995.

   [RFC 791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
                 September 1981.

   [RFC 822]     Crocker, D., "Standard for the format of ARPA Internet
                 text messages", STD 11, RFC 822, August 1982.

   [RFC 1034]    Mockapetris, P., "Domain names - concepts and
                 facilities", STD 13, RFC 1034, November 1987.

   [RFC 1319]    Kaliski, B., "The MD2 Message-Digest Algorithm," RFC
                 1319, April 1992.
ToP   noToC   RFC2459 - Page 65
   [RFC 1321]    Rivest, R., "The MD5 Message-Digest Algorithm," RFC
                 1321, April 1992.

   [RFC 1422]    Kent, S.,  "Privacy Enhancement for Internet Electronic
                 Mail: Part II: Certificate-Based Key Management," RFC
                 1422, February 1993.

   [RFC 1423]    Balenson, D., "Privacy Enhancement for Internet
                 Electronic Mail: Part III: Algorithms, Modes, and
                 Identifiers," RFC 1423, February 1993.

   [RFC 1519]    Fuller, V., Li, T., Yu, J. and K. Varadhan. "Classless
                 Inter-Domain Routing (CIDR): an Address Assignment and
                 Aggregation Strategy", RFC 1519, September 1993.

   [RFC 1738]    Berners-Lee, T., Masinter L., and M. McCahill.
                 "Uniform Resource Locators (URL)", RFC 1738, December
                 1994.

   [RFC 1778]    Howes, T., Kille S., Yeong, W. and C. Robbins. "The
                 String Representation of Standard Attribute Syntaxes,"
                 RFC 1778, March 1995.

   [RFC 1883]    Deering, S. and R. Hinden. "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 1883, December 1995.

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

   [RFC 2247]    Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
                 Sataluri. "Using Domains in LDAP/X.500 Distinguished
                 Names", RFC 2247, January 1998.

   [RFC 2277]    Alvestrand, H., "IETF Policy on Character Sets and
                 Languages", RFC 2277, January 1998.

   [RFC 2279]    Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", RFC 2279, January 1998.

   [RFC 2313]    Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
                 2313, March 1998.

   [SDN.701]     SDN.701, "Message Security Protocol 4.0", Revision A
                 1997-02-06.

   [X.208]       CCITT Recommendation X.208: Specification of Abstract
                 Syntax Notation One (ASN.1), 1988.
ToP   noToC   RFC2459 - Page 66
   [X.501]       ITU-T Recommendation X.501: Information Technology -
                 Open Systems Interconnection - The Directory: Models,
                 1993.

   [X.509]       ITU-T Recommendation X.509 (1997 E): Information
                 Technology - Open Systems Interconnection - The
                 Directory: Authentication Framework, June 1997.

   [X.520]       ITU-T Recommendation X.520: Information Technology -
                 Open Systems Interconnection - The Directory: Selected
                 Attribute Types, 1993.

   [X9.42]       ANSI X9.42-199x, Public Key Cryptography for The
                 Financial Services Industry: Agreement of Symmetric
                 Algorithm Keys Using Diffie-Hellman (Working Draft),
                 December 1997.

   [X9.55]       ANSI X9.55-1995, Public Key Cryptography For The
                 Financial Services Industry: Extensions To Public Key
                 Certificates And Certificate Revocation Lists, 8
                 December, 1995.

   [X9.57]        ANSI X9.57-199x, Public Key Cryptography For The
                 Financial Services Industry: Certificate Management
                 (Working Draft), 21 June, 1996.

9  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
ToP   noToC   RFC2459 - Page 67
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

10  Security Considerations

   The majority of this specification is devoted to the format and
   content of certificates and CRLs.  Since certificates and CRLs are
   digitally signed, no additional integrity service is necessary.
   Neither certificates nor CRLs need be kept secret, and unrestricted
   and anonymous access to certificates and CRLs has no security
   implications.

   However, security factors outside the scope of this specification
   will affect the assurance provided to certificate users.  This
   section highlights critical issues that should be considered by
   implementors, administrators, and users.

   The procedures performed by CAs and RAs to validate the binding of
   the subject's identity of their public key greatly affect the
   assurance that should be placed in the certificate.  Relying parties
   may wish to review the CA's certificate practice statement.  This may
   be particularly important when issuing certificates to other CAs.

   The use of a single key pair for both signature and other purposes is
   strongly discouraged. Use of separate key pairs for signature and key
   management provides several benefits to the users. The ramifications
   associated with loss or disclosure of a signature key are different
   from loss or disclosure of a key management key. Using separate key
   pairs permits a balanced and flexible response.  Similarly, different
   validity periods or key lengths for each key pair may be appropriate
   in some application environments. Unfortunately, some legacy
   applications (e.g., SSL) use a single key pair for signature and key
   management.

   The protection afforded private keys is a critical factor in
   maintaining security.  On a small scale, failure of users to protect
   their private keys will permit an attacker to masquerade as them, or
   decrypt their personal information. On a larger scale, compromise of
   a CA's private signing key may have a catastrophic effect.  If an
   attacker obtains the private key unnoticed, the attacker may issue
   bogus certificates and CRLs.  Existence of bogus certificates and
   CRLs will undermine confidence in the system. If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.
   Rebuilding after such a compromise will be problematic, so CAs are
   advised to implement a combination of strong technical measures
   (e.g., tamper-resistant cryptographic modules) and appropriate
ToP   noToC   RFC2459 - Page 68
   management procedures (e.g., separation of duties) to avoid such an
   incident.

   Loss of a CA's private signing key may also be problematic.  The CA
   would not be able to produce CRLs or perform normal key rollover.
   CAs are advised to maintain secure backup for signing keys.  The
   security of the key backup procedures is a critical factor in
   avoiding key compromise.

   The availability and freshness of revocation information will affect
   the degree of assurance that should be placed in a certificate.
   While certificates expire naturally, events may occur during its
   natural lifetime which negate the binding between the subject and
   public key.  If revocation information is untimely or unavailable,
   the assurance associated with the binding is clearly reduced.
   Similarly, implementations of the Path Validation mechanism described
   in section 6 that omit revocation checking provide less assurance
   than those that support it.

   The path validation algorithm depends on the certain knowledge of the
   public keys (and other information) about one or more trusted CAs.
   The decision to trust a CA is an important decision as it ultimately
   determines the trust afforded a certificate. The authenticated
   distribution of trusted CA public keys (usually in the form of a
   "self-signed" certificate) is a security critical out of band process
   that is beyond the scope of this specification.

   In addition, where a key compromise or CA failure occurs for a
   trusted CA, the user will need to modify the information provided to
   the path validation routine.  Selection of too many trusted CAs will
   make the trusted CA information difficult to maintain.  On the other
   hand, selection of only one trusted CA may limit users to a closed
   community of users until a global PKI emerges.

   The quality of implementations that process certificates may also
   affect the degree of assurance provided.  The path validation
   algorithm described in section 6 relies upon the integrity of the
   trusted CA information, and especially the integrity of the public
   keys associated with the trusted CAs.  By substituting public keys
   for which an attacker has the private key, an attacker could trick
   the user into accepting false certificates.

   The binding between a key and certificate subject cannot be stronger
   than the cryptographic module implementation and algorithms used to
   generate the signature.  Short key lengths or weak hash algorithms
   will limit the utility of a certificate.  CAs are encouraged to note
   advances in cryptology so they can employ strong cryptographic
   techniques.  In addition, CAs should decline to issue certificates to
ToP   noToC   RFC2459 - Page 69
   CAs or end entities that generate weak signatures.

   Inconsistent application of name comparison rules may result in
   acceptance of invalid X.509 certification paths, or rejection of
   valid ones.  The X.500 series of specifications defines rules for
   comparing distinguished names require comparison of strings without
   regard to case, character set, multi-character white space substring,
   or leading and trailing white space.  This specification relaxes
   these requirements, requiring support for binary comparison at a
   minimum.

   CAs shall encode the distinguished name in the subject field of a CA
   certificate identically to the distinguished name in the issuer field
   in certificates issued by the latter CA.  If CAs use different
   encodings, implementations of this specification may fail to
   recognize name chains for paths that include this certificate.  As a
   consequence, valid paths could be rejected.

   In addition, name constraints for distinguished names shall be stated
   identically to the encoding used in the subject field or
   subjectAltName extension.  If not, (1) name constraints stated as
   excludedSubTrees will not match and invalid paths will be accepted
   and (2) name constraints expressed as permittedSubtrees will not
   match and valid paths will be rejected.  To avoid acceptance of
   invalid paths, CAs should state name constraints for distinguished
   names as permittedSubtrees where ever possible.
ToP   noToC   RFC2459 - Page 70
Appendix A. Psuedo-ASN.1 Structures and OIDs

   This section describes data objects used by conforming PKI components
   in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
   1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
   UNIVERSAL Types UniversalString, BMPString and UTF8String.

   The ASN.1 syntax does not permit the inclusion of type statements in
   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
   the new UNIVERSAL types in modules using the 1988 syntax.  As a
   result, this module does not conform to either version of the ASN.1
   standard.

   This appendix may be converted into 1988 ASN.1 by replacing the
   defintions for the UNIVERSAL Types with the 1988 catch-all "ANY".

A.1 Explicitly Tagged Module, 1988 Syntax

PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}


DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

-- IMPORTS NONE --

-- UNIVERSAL Types defined in '93 and '98 ASN.1
-- but required by this specification

UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
        -- UniversalString is defined in ASN.1:1993

BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
      -- BMPString is the subtype of UniversalString and models
       -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
        -- The content of this type conforms to RFC 2279.

--
-- PKIX specific OIDs

id-pkix  OBJECT IDENTIFIER  ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
ToP   noToC   RFC2459 - Page 71
                    security(5) mechanisms(5) pkix(7) }
-- PKIX arcs

id-pe OBJECT IDENTIFIER  ::=  { id-pkix 1 }
        -- arc for private certificate extensions
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
        -- arc for policy qualifier types
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
        -- arc for extended key purpose OIDS
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
        -- arc for access descriptors

-- policyQualifierIds for Internet policy qualifiers

id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
        -- OID for CPS qualifier
id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
        -- OID for user notice qualifier

-- access descriptor definitions

id-ad-ocsp      OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

-- attribute data types --

Attribute       ::=     SEQUENCE {
        type            AttributeType,
        values  SET OF AttributeValue
                -- at least one value is required -- }

AttributeType           ::=   OBJECT IDENTIFIER

AttributeValue          ::=   ANY

AttributeTypeAndValue           ::=     SEQUENCE {
        type    AttributeType,
        value   AttributeValue }

-- suggested naming attributes: Definition of the following
--  information object set may be augmented to meet local
--  requirements.  Note that deleting members of the set may
--  prevent interoperability with conforming implementations.
--  presented in pairs: the AttributeType followed by the
--  type definition for the corresponding AttributeValue

--Arc for standard naming attributes
id-at           OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
ToP   noToC   RFC2459 - Page 72
-- Attributes of type NameDirectoryString
id-at-name              AttributeType   ::=     {id-at 41}
id-at-surname           AttributeType   ::=     {id-at 4}
id-at-givenName         AttributeType   ::=     {id-at 42}
id-at-initials          AttributeType   ::=     {id-at 43}
id-at-generationQualifier       AttributeType   ::=     {id-at 44}

X520name        ::= CHOICE {
      teletexString         TeletexString (SIZE (1..ub-name)),
      printableString       PrintableString (SIZE (1..ub-name)),
      universalString       UniversalString (SIZE (1..ub-name)),
      utf8String            UTF8String (SIZE (1..ub-name)),
      bmpString             BMPString (SIZE(1..ub-name))   }

--

id-at-commonName        AttributeType   ::=     {id-at 3}

X520CommonName  ::=      CHOICE {
      teletexString         TeletexString (SIZE (1..ub-common-name)),
      printableString       PrintableString (SIZE (1..ub-common-name)),
      universalString       UniversalString (SIZE (1..ub-common-name)),
      utf8String            UTF8String (SIZE (1..ub-common-name)),
      bmpString             BMPString (SIZE(1..ub-common-name))   }

--

id-at-localityName      AttributeType   ::=     {id-at 7}

X520LocalityName ::= CHOICE {
      teletexString       TeletexString (SIZE (1..ub-locality-name)),
      printableString     PrintableString (SIZE (1..ub-locality-name)),
      universalString     UniversalString (SIZE (1..ub-locality-name)),
      utf8String          UTF8String (SIZE (1..ub-locality-name)),
      bmpString           BMPString (SIZE(1..ub-locality-name))   }

--

id-at-stateOrProvinceName       AttributeType   ::=     {id-at 8}

X520StateOrProvinceName         ::= CHOICE {
      teletexString       TeletexString (SIZE (1..ub-state-name)),
      printableString     PrintableString (SIZE (1..ub-state-name)),
      universalString     UniversalString (SIZE (1..ub-state-name)),
      utf8String          UTF8String (SIZE (1..ub-state-name)),
      bmpString           BMPString (SIZE(1..ub-state-name))   }

--
ToP   noToC   RFC2459 - Page 73
id-at-organizationName          AttributeType   ::=     {id-at 10}

X520OrganizationName ::= CHOICE {
  teletexString     TeletexString (SIZE (1..ub-organization-name)),
  printableString   PrintableString (SIZE (1..ub-organization-name)),
  universalString   UniversalString (SIZE (1..ub-organization-name)),
  utf8String        UTF8String (SIZE (1..ub-organization-name)),
  bmpString         BMPString (SIZE(1..ub-organization-name))   }

--

id-at-organizationalUnitName    AttributeType   ::=     {id-at 11}

X520OrganizationalUnitName ::= CHOICE {
 teletexString    TeletexString (SIZE (1..ub-organizational-unit-name)),
 printableString        PrintableString
                      (SIZE (1..ub-organizational-unit-name)),
 universalString        UniversalString
                      (SIZE (1..ub-organizational-unit-name)),
 utf8String       UTF8String (SIZE (1..ub-organizational-unit-name)),
 bmpString        BMPString (SIZE(1..ub-organizational-unit-name))   }

--

id-at-title     AttributeType   ::=     {id-at 12}

X520Title ::=   CHOICE {
      teletexString         TeletexString (SIZE (1..ub-title)),
      printableString       PrintableString (SIZE (1..ub-title)),
      universalString       UniversalString (SIZE (1..ub-title)),
      utf8String            UTF8String (SIZE (1..ub-title)),
      bmpString             BMPString (SIZE(1..ub-title))   }

--

id-at-dnQualifier       AttributeType   ::=     {id-at 46}
X520dnQualifier ::=     PrintableString

id-at-countryName       AttributeType   ::=     {id-at 6}
X520countryName ::=     PrintableString (SIZE (2)) -- IS 3166 codes


 -- Legacy attributes

pkcs-9 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }

emailAddress AttributeType      ::= { pkcs-9 1 }
ToP   noToC   RFC2459 - Page 74
Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length))

-- naming data types --

Name            ::=   CHOICE { -- only one possibility for now --
                                 rdnSequence  RDNSequence }

RDNSequence     ::=   SEQUENCE OF RelativeDistinguishedName

DistinguishedName       ::=   RDNSequence

RelativeDistinguishedName  ::=
                    SET SIZE (1 .. MAX) OF AttributeTypeAndValue

-- Directory string type --

DirectoryString ::= CHOICE {
      teletexString             TeletexString (SIZE (1..MAX)),
      printableString           PrintableString (SIZE (1..MAX)),
      universalString           UniversalString (SIZE (1..MAX)),
      utf8String              UTF8String (SIZE (1..MAX)),
      bmpString               BMPString (SIZE(1..MAX))   }

-- certificate and CRL specific structures begin here

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version shall be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version shall be v2 or v3
     extensions      [3]  Extensions OPTIONAL
                          -- If present, version shall be v3 --  }

Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

CertificateSerialNumber  ::=  INTEGER
ToP   noToC   RFC2459 - Page 75
Validity ::= SEQUENCE {
     notBefore      Time,
     notAfter       Time }

Time ::= CHOICE {
     utcTime        UTCTime,
     generalTime    GeneralizedTime }

UniqueIdentifier  ::=  BIT STRING

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING  }

Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

Extension  ::=  SEQUENCE  {
     extnID      OBJECT IDENTIFIER,
     critical    BOOLEAN DEFAULT FALSE,
     extnValue   OCTET STRING  }

-- CRL structures

CertificateList  ::=  SEQUENCE  {
     tbsCertList          TBSCertList,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertList  ::=  SEQUENCE  {
     version                 Version OPTIONAL,
                                  -- if present, shall be v2
     signature               AlgorithmIdentifier,
     issuer                  Name,
     thisUpdate              Time,
     nextUpdate              Time OPTIONAL,
     revokedCertificates     SEQUENCE OF SEQUENCE  {
          userCertificate         CertificateSerialNumber,
          revocationDate          Time,
          crlEntryExtensions      Extensions OPTIONAL
                                         -- if present, shall be v2
                               }  OPTIONAL,
     crlExtensions           [0] Extensions OPTIONAL
                                         -- if present, shall be v2 -- }

-- Version, Time, CertificateSerialNumber, and Extensions were
-- defined earlier for use in the certificate structure

AlgorithmIdentifier  ::=  SEQUENCE  {
ToP   noToC   RFC2459 - Page 76
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                -- contains a value of the type
                                -- registered for use with the
                                -- algorithm object identifier value

-- Algorithm OIDs and parameter structures

pkcs-1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }

md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
     iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }

Dss-Sig-Value  ::=  SEQUENCE  {
     r       INTEGER,
     s       INTEGER  }

dhpublicnumber OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

DomainParameters ::= SEQUENCE {
     p       INTEGER, -- odd prime, p=jq +1
     g       INTEGER, -- generator, g
     q       INTEGER, -- factor of p-1
     j       INTEGER OPTIONAL, -- subgroup factor, j>= 2
     validationParms  ValidationParms OPTIONAL }

ValidationParms ::= SEQUENCE {
     seed             BIT STRING,
     pgenCounter      INTEGER }

id-dsa OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

Dss-Parms  ::=  SEQUENCE  {
     p             INTEGER,
     q             INTEGER,
     g             INTEGER  }
ToP   noToC   RFC2459 - Page 77
-- x400 address syntax starts here
--      OR Names

ORAddress ::= SEQUENCE {
   built-in-standard-attributes BuiltInStandardAttributes,
   built-in-domain-defined-attributes
                        BuiltInDomainDefinedAttributes OPTIONAL,
   -- see also teletex-domain-defined-attributes
   extension-attributes ExtensionAttributes OPTIONAL }
--      The OR-address is semantically absent from the OR-name if the
--      built-in-standard-attribute sequence is empty and the
--      built-in-domain-defined-attributes and extension-attributes are
--      both omitted.

--      Built-in Standard Attributes

BuiltInStandardAttributes ::= SEQUENCE {
   country-name CountryName OPTIONAL,
   administration-domain-name AdministrationDomainName OPTIONAL,
   network-address      [0] NetworkAddress OPTIONAL,
   -- see also extended-network-address
   terminal-identifier  [1] TerminalIdentifier OPTIONAL,
   private-domain-name  [2] PrivateDomainName OPTIONAL,
   organization-name    [3] OrganizationName OPTIONAL,
   -- see also teletex-organization-name
   numeric-user-identifier      [4] NumericUserIdentifier OPTIONAL,
   personal-name        [5] PersonalName OPTIONAL,
   -- see also teletex-personal-name
   organizational-unit-names    [6] OrganizationalUnitNames OPTIONAL
   -- see also teletex-organizational-unit-names -- }

CountryName ::= [APPLICATION 1] CHOICE {
   x121-dcc-code NumericString
                (SIZE (ub-country-name-numeric-length)),
   iso-3166-alpha2-code PrintableString
                (SIZE (ub-country-name-alpha-length)) }

AdministrationDomainName ::= [APPLICATION 2] CHOICE {
   numeric NumericString (SIZE (0..ub-domain-name-length)),
   printable PrintableString (SIZE (0..ub-domain-name-length)) }

NetworkAddress ::= X121Address  -- see also extended-network-address

X121Address ::= NumericString (SIZE (1..ub-x121-address-length))

TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))

PrivateDomainName ::= CHOICE {
ToP   noToC   RFC2459 - Page 78
   numeric NumericString (SIZE (1..ub-domain-name-length)),
   printable PrintableString (SIZE (1..ub-domain-name-length)) }

OrganizationName ::= PrintableString
                            (SIZE (1..ub-organization-name-length))
-- see also teletex-organization-name

NumericUserIdentifier ::= NumericString
                            (SIZE (1..ub-numeric-user-id-length))

PersonalName ::= SET {
   surname [0] PrintableString (SIZE (1..ub-surname-length)),
   given-name [1] PrintableString
                        (SIZE (1..ub-given-name-length)) OPTIONAL,
   initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL,
   generation-qualifier [3] PrintableString
                (SIZE (1..ub-generation-qualifier-length)) OPTIONAL }
-- see also teletex-personal-name

OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
                                        OF OrganizationalUnitName
-- see also teletex-organizational-unit-names

OrganizationalUnitName ::= PrintableString (SIZE
                        (1..ub-organizational-unit-name-length))

--      Built-in Domain-defined Attributes

BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
                                (1..ub-domain-defined-attributes) OF
                                BuiltInDomainDefinedAttribute

BuiltInDomainDefinedAttribute ::= SEQUENCE {
   type PrintableString (SIZE
                        (1..ub-domain-defined-attribute-type-length)),
   value PrintableString (SIZE
                        (1..ub-domain-defined-attribute-value-length))}

--      Extension Attributes

ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
                        ExtensionAttribute

ExtensionAttribute ::=  SEQUENCE {
   extension-attribute-type [0] INTEGER (0..ub-extension-attributes),
   extension-attribute-value [1]
                        ANY DEFINED BY extension-attribute-type }
ToP   noToC   RFC2459 - Page 79
-- Extension types and attribute values
--

common-name INTEGER ::= 1

CommonName ::= PrintableString (SIZE (1..ub-common-name-length))

teletex-common-name INTEGER ::= 2

TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))

teletex-organization-name INTEGER ::= 3

TeletexOrganizationName ::=
                TeletexString (SIZE (1..ub-organization-name-length))

teletex-personal-name INTEGER ::= 4

TeletexPersonalName ::= SET {
   surname [0] TeletexString (SIZE (1..ub-surname-length)),
   given-name [1] TeletexString
                (SIZE (1..ub-given-name-length)) OPTIONAL,
   initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
   generation-qualifier [3] TeletexString (SIZE
                (1..ub-generation-qualifier-length)) OPTIONAL }

teletex-organizational-unit-names INTEGER ::= 5

TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
        (1..ub-organizational-units) OF TeletexOrganizationalUnitName

TeletexOrganizationalUnitName ::= TeletexString
                        (SIZE (1..ub-organizational-unit-name-length))

pds-name INTEGER ::= 7

PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))

physical-delivery-country-name INTEGER ::= 8

PhysicalDeliveryCountryName ::= CHOICE {
   x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
   iso-3166-alpha2-code PrintableString
                        (SIZE (ub-country-name-alpha-length)) }

postal-code INTEGER ::= 9

PostalCode ::= CHOICE {
ToP   noToC   RFC2459 - Page 80
   numeric-code NumericString (SIZE (1..ub-postal-code-length)),
   printable-code PrintableString (SIZE (1..ub-postal-code-length)) }

physical-delivery-office-name INTEGER ::= 10

PhysicalDeliveryOfficeName ::= PDSParameter

physical-delivery-office-number INTEGER ::= 11

PhysicalDeliveryOfficeNumber ::= PDSParameter

extension-OR-address-components INTEGER ::= 12

ExtensionORAddressComponents ::= PDSParameter

physical-delivery-personal-name INTEGER ::= 13

PhysicalDeliveryPersonalName ::= PDSParameter

physical-delivery-organization-name INTEGER ::= 14

PhysicalDeliveryOrganizationName ::= PDSParameter

extension-physical-delivery-address-components INTEGER ::= 15

ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter

unformatted-postal-address INTEGER ::= 16

UnformattedPostalAddress ::= SET {
   printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
           PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
   teletex-string TeletexString
         (SIZE (1..ub-unformatted-address-length)) OPTIONAL }

street-address INTEGER ::= 17

StreetAddress ::= PDSParameter

post-office-box-address INTEGER ::= 18

PostOfficeBoxAddress ::= PDSParameter

poste-restante-address INTEGER ::= 19

PosteRestanteAddress ::= PDSParameter

unique-postal-name INTEGER ::= 20
ToP   noToC   RFC2459 - Page 81
UniquePostalName ::= PDSParameter

local-postal-attributes INTEGER ::= 21

LocalPostalAttributes ::= PDSParameter

PDSParameter ::= SET {
   printable-string PrintableString
                (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
   teletex-string TeletexString
                (SIZE(1..ub-pds-parameter-length)) OPTIONAL }

extended-network-address INTEGER ::= 22

ExtendedNetworkAddress ::= CHOICE {
   e163-4-address SEQUENCE {
        number [0] NumericString (SIZE (1..ub-e163-4-number-length)),
        sub-address [1] NumericString
                (SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL },
   psap-address [0] PresentationAddress }

PresentationAddress ::= SEQUENCE {
        pSelector       [0] EXPLICIT OCTET STRING OPTIONAL,
        sSelector       [1] EXPLICIT OCTET STRING OPTIONAL,
        tSelector       [2] EXPLICIT OCTET STRING OPTIONAL,
        nAddresses      [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }

terminal-type  INTEGER ::= 23

TerminalType ::= INTEGER {
   telex (3),
   teletex (4),
   g3-facsimile (5),
   g4-facsimile (6),
   ia5-terminal (7),
   videotex (8) } (0..ub-integer-options)

--      Extension Domain-defined Attributes

teletex-domain-defined-attributes INTEGER ::= 6

TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
   (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute

TeletexDomainDefinedAttribute ::= SEQUENCE {
        type TeletexString
               (SIZE (1..ub-domain-defined-attribute-type-length)),
        value TeletexString
ToP   noToC   RFC2459 - Page 82
               (SIZE (1..ub-domain-defined-attribute-value-length)) }

--  specifications of Upper Bounds shall be regarded as mandatory
--  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
--  Upper Bounds

--      Upper Bounds
ub-name INTEGER ::=     32768
ub-common-name  INTEGER ::=     64
ub-locality-name        INTEGER ::=     128
ub-state-name   INTEGER ::=     128
ub-organization-name    INTEGER ::=     64
ub-organizational-unit-name     INTEGER ::=     64
ub-title        INTEGER ::=     64
ub-match        INTEGER ::=     128

ub-emailaddress-length INTEGER ::= 128

ub-common-name-length INTEGER ::= 64
ub-country-name-alpha-length INTEGER ::= 2
ub-country-name-numeric-length INTEGER ::= 3
ub-domain-defined-attributes INTEGER ::= 4
ub-domain-defined-attribute-type-length INTEGER ::= 8
ub-domain-defined-attribute-value-length INTEGER ::= 128
ub-domain-name-length INTEGER ::= 16
ub-extension-attributes INTEGER ::= 256
ub-e163-4-number-length INTEGER ::= 15
ub-e163-4-sub-address-length INTEGER ::= 40
ub-generation-qualifier-length INTEGER ::= 3
ub-given-name-length INTEGER ::= 16
ub-initials-length INTEGER ::= 5
ub-integer-options INTEGER ::= 256
ub-numeric-user-id-length INTEGER ::= 32
ub-organization-name-length INTEGER ::= 64
ub-organizational-unit-name-length INTEGER ::= 32
ub-organizational-units INTEGER ::= 4
ub-pds-name-length INTEGER ::= 16
ub-pds-parameter-length INTEGER ::= 30
ub-pds-physical-address-lines INTEGER ::= 6
ub-postal-code-length INTEGER ::= 16
ub-surname-length INTEGER ::= 40
ub-terminal-id-length INTEGER ::= 24
ub-unformatted-address-length INTEGER ::= 180
ub-x121-address-length INTEGER ::= 16

-- Note - upper bounds on string types, such as TeletexString, are
-- measured in characters.  Excepting PrintableString or IA5String, a
-- significantly greater number of octets will be required to hold
ToP   noToC   RFC2459 - Page 83
-- such a value.  As a minimum, 16 octets, or twice the specified upper
-- bound, whichever is the larger, should be allowed for TeletexString.
-- For UTF8String or UniversalString at least four times the upper
-- bound should be allowed.

END
ToP   noToC   RFC2459 - Page 84
A.2 Implicitly Tagged Module, 1988 Syntax

PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS
        id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps,
            id-ad, id-ad-ocsp, id-ad-caIssuers,
            -- delete following line if "new" types are supported --
            BMPString, UniversalString, UTF8String, -- end "new" types
                ORAddress, Name, RelativeDistinguishedName,
                CertificateSerialNumber,
                CertificateList, AlgorithmIdentifier, ub-name,
                Attribute, DirectoryString
                FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                id-mod(0) id-pkix1-explicit(1)};


-- ISO arc for standard certificate and CRL extensions

id-ce OBJECT IDENTIFIER  ::=  {joint-iso-ccitt(2) ds(5) 29}

-- authority key identifier OID and syntax

id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier            OPTIONAL,
      authorityCertIssuer       [1] GeneralNames             OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber  OPTIONAL }
    -- authorityCertIssuer and authorityCertSerialNumber shall both
    -- be present or both be absent

KeyIdentifier ::= OCTET STRING

-- subject key identifier OID and syntax

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier
ToP   noToC   RFC2459 - Page 85
-- key usage extension OID and syntax

id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

KeyUsage ::= BIT STRING {
     digitalSignature        (0),
     nonRepudiation          (1),
     keyEncipherment         (2),
     dataEncipherment        (3),
     keyAgreement            (4),
     keyCertSign             (5),
     cRLSign                 (6),
     encipherOnly            (7),
     decipherOnly            (8) }

-- private key usage period extension OID and syntax

id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }

PrivateKeyUsagePeriod ::= SEQUENCE {
     notBefore       [0]     GeneralizedTime OPTIONAL,
     notAfter        [1]     GeneralizedTime OPTIONAL }
     -- either notBefore or notAfter shall be present

-- certificate policies extension OID and syntax

id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
     policyIdentifier   CertPolicyId,
     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
             PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {
       policyQualifierId  PolicyQualifierId,
       qualifier        ANY DEFINED BY policyQualifierId }

-- Implementations that recognize additional policy qualifiers shall
-- augment the following definition for PolicyQualifierId

PolicyQualifierId ::=
    OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

-- CPS pointer qualifier
ToP   noToC   RFC2459 - Page 86
CPSuri ::= IA5String

-- user notice qualifier

UserNotice ::= SEQUENCE {
     noticeRef        NoticeReference OPTIONAL,
     explicitText     DisplayText OPTIONAL}

NoticeReference ::= SEQUENCE {
     organization     DisplayText,
     noticeNumbers    SEQUENCE OF INTEGER }

DisplayText ::= CHOICE {
     visibleString    VisibleString  (SIZE (1..200)),
     bmpString        BMPString      (SIZE (1..200)),
     utf8String       UTF8String     (SIZE (1..200)) }

-- policy mapping extension OID and syntax

id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
     issuerDomainPolicy      CertPolicyId,
     subjectDomainPolicy     CertPolicyId }

-- subject alternative name extension OID and syntax

id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
     otherName                       [0]     AnotherName,
     rfc822Name                      [1]     IA5String,
     dNSName                         [2]     IA5String,
     x400Address                     [3]     ORAddress,
     directoryName                   [4]     Name,
     ediPartyName                    [5]     EDIPartyName,
     uniformResourceIdentifier       [6]     IA5String,
     iPAddress                       [7]     OCTET STRING,
     registeredID                    [8]     OBJECT IDENTIFIER }

-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::= SEQUENCE {
ToP   noToC   RFC2459 - Page 87
     type-id    OBJECT IDENTIFIER,
     value      [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {
     nameAssigner            [0]     DirectoryString OPTIONAL,
     partyName               [1]     DirectoryString }

-- issuer alternative name extension OID and syntax

id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }

IssuerAltName ::= GeneralNames

id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

-- basic constraints extension OID and syntax

id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

-- name constraints extension OID and syntax

id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }

NameConstraints ::= SEQUENCE {
     permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
     excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
     base                    GeneralName,
     minimum         [0]     BaseDistance DEFAULT 0,
     maximum         [1]     BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

-- policy constraints extension OID and syntax

id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }

PolicyConstraints ::= SEQUENCE {
     requireExplicitPolicy           [0] SkipCerts OPTIONAL,
ToP   noToC   RFC2459 - Page 88
     inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

-- CRL distribution points extension OID and syntax

id-ce-cRLDistributionPoints     OBJECT IDENTIFIER  ::=  {id-ce 31}

CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {
     distributionPoint       [0]     DistributionPointName OPTIONAL,
     reasons                 [1]     ReasonFlags OPTIONAL,
     cRLIssuer               [2]     GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {
     fullName                [0]     GeneralNames,
     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {
     unused                  (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6) }

-- extended key usage extension OID and syntax

id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

-- extended key purpose OIDs
id-kp-serverAuth      OBJECT IDENTIFIER ::= { id-kp 1 }
id-kp-clientAuth      OBJECT IDENTIFIER ::= { id-kp 2 }
id-kp-codeSigning     OBJECT IDENTIFIER ::= { id-kp 3 }
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
id-kp-ipsecEndSystem  OBJECT IDENTIFIER ::= { id-kp 5 }
id-kp-ipsecTunnel     OBJECT IDENTIFIER ::= { id-kp 6 }
id-kp-ipsecUser       OBJECT IDENTIFIER ::= { id-kp 7 }
id-kp-timeStamping    OBJECT IDENTIFIER ::= { id-kp 8 }

-- authority info access
ToP   noToC   RFC2459 - Page 89
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

AuthorityInfoAccessSyntax  ::=
        SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription  ::=  SEQUENCE {
        accessMethod          OBJECT IDENTIFIER,
        accessLocation        GeneralName  }

-- CRL number extension OID and syntax

id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

CRLNumber ::= INTEGER (0..MAX)

-- issuing distribution point extension OID and syntax

id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

IssuingDistributionPoint ::= SEQUENCE {
     distributionPoint       [0] DistributionPointName OPTIONAL,
     onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
     onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
     onlySomeReasons         [3] ReasonFlags OPTIONAL,
     indirectCRL             [4] BOOLEAN DEFAULT FALSE }


id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

-- deltaCRLIndicator ::= BaseCRLNumber

BaseCRLNumber ::= CRLNumber

-- CRL reasons extension OID and syntax

id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

CRLReason ::= ENUMERATED {
     unspecified             (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6),
     removeFromCRL           (8) }

-- certificate issuer CRL entry extension OID and syntax
ToP   noToC   RFC2459 - Page 90
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }

CertificateIssuer ::= GeneralNames

-- hold instruction extension OID and syntax

id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

HoldInstructionCode ::= OBJECT IDENTIFIER

-- ANSI x9 holdinstructions

-- ANSI x9 arc holdinstruction arc
holdInstruction OBJECT IDENTIFIER ::=
          {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}

-- ANSI X9 holdinstructions referenced by this standard
id-holdinstruction-none OBJECT IDENTIFIER  ::=
                {holdInstruction 1} -- deprecated
id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
                {holdInstruction 2}
id-holdinstruction-reject OBJECT IDENTIFIER ::=
                {holdInstruction 3}

-- invalidity date CRL entry extension OID and syntax

id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }

InvalidityDate ::=  GeneralizedTime

END


(next page on part 4)

Next Section