tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3447

 
 
 

Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1

Part 3 of 3, p. 44 to 72
Prev RFC Part

 


prevText      Top      Up      ToC       Page 44 
Appendix A. ASN.1 syntax

A.1 RSA key representation

   This section defines ASN.1 object identifiers for RSA public and
   private keys, and defines the types RSAPublicKey and RSAPrivateKey.
   The intended application of these definitions includes X.509
   certificates, PKCS #8 [46], and PKCS #12 [47].

   The object identifier rsaEncryption identifies RSA public and private
   keys as defined in Appendices A.1.1 and A.1.2.  The parameters field
   associated with this OID in a value of type AlgorithmIdentifier shall
   have a value of type NULL.

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

   The definitions in this section have been extended to support multi-
   prime RSA, but are backward compatible with previous versions.

A.1.1 RSA public key syntax

   An RSA public key should be represented with the ASN.1 type
   RSAPublicKey:

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

   The fields of type RSAPublicKey have the following meanings:

    * modulus is the RSA modulus n.

    * publicExponent is the RSA public exponent e.

Top      Up      ToC       Page 45 
A.1.2 RSA private key syntax

   An RSA private key should be represented with the ASN.1 type
   RSAPrivateKey:

      RSAPrivateKey ::= SEQUENCE {
          version           Version,
          modulus           INTEGER,  -- n
          publicExponent    INTEGER,  -- e
          privateExponent   INTEGER,  -- d
          prime1            INTEGER,  -- p
          prime2            INTEGER,  -- q
          exponent1         INTEGER,  -- d mod (p-1)
          exponent2         INTEGER,  -- d mod (q-1)
          coefficient       INTEGER,  -- (inverse of q) mod p
          otherPrimeInfos   OtherPrimeInfos OPTIONAL
      }

   The fields of type RSAPrivateKey have the following meanings:

    * version is the version number, for compatibility with future
      revisions of this document.  It shall be 0 for this version of the
      document, unless multi-prime is used, in which case it shall be 1.

            Version ::= INTEGER { two-prime(0), multi(1) }
               (CONSTRAINED BY
               {-- version must be multi if otherPrimeInfos present --})

    * modulus is the RSA modulus n.

    * publicExponent is the RSA public exponent e.

    * privateExponent is the RSA private exponent d.

    * prime1 is the prime factor p of n.

    * prime2 is the prime factor q of n.

    * exponent1 is d mod (p - 1).

    * exponent2 is d mod (q - 1).

    * coefficient is the CRT coefficient q^(-1) mod p.

    * otherPrimeInfos contains the information for the additional primes
      r_3, ..., r_u, in order.  It shall be omitted if version is 0 and
      shall contain at least one instance of OtherPrimeInfo if version
      is 1.

Top      Up      ToC       Page 46 
         OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo

         OtherPrimeInfo ::= SEQUENCE {
             prime             INTEGER,  -- ri
             exponent          INTEGER,  -- di
             coefficient       INTEGER   -- ti
         }

   The fields of type OtherPrimeInfo have the following meanings:

    * prime is a prime factor r_i of n, where i >= 3.

    * exponent is d_i = d mod (r_i - 1).

    * coefficient is the CRT coefficient t_i = (r_1 * r_2 * ... * r_(i-
      1))^(-1) mod r_i.

   Note.  It is important to protect the RSA private key against both
   disclosure and modification.  Techniques for such protection are
   outside the scope of this document.  Methods for storing and
   distributing private keys and other cryptographic data are described
   in PKCS #12 and #15.

A.2 Scheme identification

   This section defines object identifiers for the encryption and
   signature schemes.  The schemes compatible with PKCS #1 v1.5 have the
   same definitions as in PKCS #1 v1.5.  The intended application of
   these definitions includes X.509 certificates and PKCS #7.

   Here are type identifier definitions for the PKCS #1 OIDs:

      PKCS1Algorithms    ALGORITHM-IDENTIFIER ::= {
          { OID rsaEncryption              PARAMETERS NULL } |
          { OID md2WithRSAEncryption       PARAMETERS NULL } |
          { OID md5WithRSAEncryption       PARAMETERS NULL } |
          { OID sha1WithRSAEncryption      PARAMETERS NULL } |
          { OID sha256WithRSAEncryption    PARAMETERS NULL } |
          { OID sha384WithRSAEncryption    PARAMETERS NULL } |
          { OID sha512WithRSAEncryption    PARAMETERS NULL } |
          { OID id-RSAES-OAEP PARAMETERS RSAES-OAEP-params } |
          PKCS1PSourceAlgorithms                             |
          { OID id-RSASSA-PSS PARAMETERS RSASSA-PSS-params } ,
          ...  -- Allows for future expansion --
      }

Top      Up      ToC       Page 47 
A.2.1 RSAES-OAEP

   The object identifier id-RSAES-OAEP identifies the RSAES-OAEP
   encryption scheme.

      id-RSAES-OAEP    OBJECT IDENTIFIER ::= { pkcs-1 7 }

   The parameters field associated with this OID in a value of type
   AlgorithmIdentifier shall have a value of type RSAES-OAEP-params:

      RSAES-OAEP-params ::= SEQUENCE {
          hashAlgorithm     [0] HashAlgorithm    DEFAULT sha1,
          maskGenAlgorithm  [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
          pSourceAlgorithm  [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty
      }

   The fields of type RSAES-OAEP-params have the following meanings:

    * hashAlgorithm identifies the hash function.  It shall be an
      algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms.
      For a discussion of supported hash functions, see Appendix B.1.

         HashAlgorithm ::= AlgorithmIdentifier {
            {OAEP-PSSDigestAlgorithms}
         }

         OAEP-PSSDigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
             { OID id-sha1 PARAMETERS NULL   }|
             { OID id-sha256 PARAMETERS NULL }|
             { OID id-sha384 PARAMETERS NULL }|
             { OID id-sha512 PARAMETERS NULL },
             ...  -- Allows for future expansion --
         }

      The default hash function is SHA-1:

         sha1    HashAlgorithm ::= {
             algorithm   id-sha1,
             parameters  SHA1Parameters : NULL
         }

         SHA1Parameters ::= NULL

    * maskGenAlgorithm identifies the mask generation function.  It
      shall be an algorithm ID with an OID in the set
      PKCS1MGFAlgorithms, which for this version shall consist of
      id-mgf1, identifying the MGF1 mask generation function (see
      Appendix B.2.1).  The parameters field associated with id-mgf1

Top      Up      ToC       Page 48 
      shall be an algorithm ID with an OID in the set
      OAEP-PSSDigestAlgorithms, identifying the hash function on which
      MGF1 is based.

         MaskGenAlgorithm ::= AlgorithmIdentifier {
            {PKCS1MGFAlgorithms}
         }
         PKCS1MGFAlgorithms    ALGORITHM-IDENTIFIER ::= {
             { OID id-mgf1 PARAMETERS HashAlgorithm },
             ...  -- Allows for future expansion --
         }

      The default mask generation function is MGF1 with SHA-1:

         mgf1SHA1    MaskGenAlgorithm ::= {
             algorithm   id-mgf1,
             parameters  HashAlgorithm : sha1
         }

    * pSourceAlgorithm identifies the source (and possibly the value)
      of the label L.  It shall be an algorithm ID with an OID in the
      set PKCS1PSourceAlgorithms, which for this version shall consist
      of id-pSpecified, indicating that the label is specified
      explicitly.  The parameters field associated with id-pSpecified
      shall have a value of type OCTET STRING, containing the
      label.  In previous versions of this specification, the term
      "encoding parameters" was used rather than "label", hence the
      name of the type below.

         PSourceAlgorithm ::= AlgorithmIdentifier {
            {PKCS1PSourceAlgorithms}
         }

         PKCS1PSourceAlgorithms    ALGORITHM-IDENTIFIER ::= {
             { OID id-pSpecified PARAMETERS EncodingParameters },
             ...  -- Allows for future expansion --
         }

         id-pSpecified    OBJECT IDENTIFIER ::= { pkcs-1 9 }

         EncodingParameters ::= OCTET STRING(SIZE(0..MAX))

Top      Up      ToC       Page 49 
      The default label is an empty string (so that lHash will contain
      the hash of the empty string):

         pSpecifiedEmpty    PSourceAlgorithm ::= {
             algorithm   id-pSpecified,
             parameters  EncodingParameters : emptyString
         }

         emptyString    EncodingParameters ::= ''H

      If all of the default values of the fields in RSAES-OAEP-params
      are used, then the algorithm identifier will have the following
      value:

         rSAES-OAEP-Default-Identifier  RSAES-AlgorithmIdentifier ::= {
             algorithm   id-RSAES-OAEP,
             parameters  RSAES-OAEP-params : {
                 hashAlgorithm       sha1,
                 maskGenAlgorithm    mgf1SHA1,
                 pSourceAlgorithm    pSpecifiedEmpty
             }
         }

         RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier {
            {PKCS1Algorithms}
         }

A.2.2 RSAES-PKCS1-v1_5

   The object identifier rsaEncryption (see Appendix A.1) identifies the
   RSAES-PKCS1-v1_5 encryption scheme.  The parameters field associated
   with this OID in a value of type AlgorithmIdentifier shall have a
   value of type NULL.  This is the same as in PKCS #1 v1.5.

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

A.2.3 RSASSA-PSS

   The object identifier id-RSASSA-PSS identifies the RSASSA-PSS
   encryption scheme.

      id-RSASSA-PSS    OBJECT IDENTIFIER ::= { pkcs-1 10 }

Top      Up      ToC       Page 50 
   The parameters field associated with this OID in a value of type
   AlgorithmIdentifier shall have a value of type RSASSA-PSS-params:

      RSASSA-PSS-params ::= SEQUENCE {
          hashAlgorithm      [0] HashAlgorithm    DEFAULT sha1,
          maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
          saltLength         [2] INTEGER          DEFAULT 20,
          trailerField       [3] TrailerField     DEFAULT trailerFieldBC
      }

   The fields of type RSASSA-PSS-params have the following meanings:

    * hashAlgorithm identifies the hash function.  It shall be an
      algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms (see
      Appendix A.2.1).  The default hash function is SHA-1.

    * maskGenAlgorithm identifies the mask generation function.  It
      shall be an algorithm ID with an OID in the set

      PKCS1MGFAlgorithms (see Appendix A.2.1).  The default mask
      generation function is MGF1 with SHA-1.  For MGF1 (and more
      generally, for other mask generation functions based on a hash
      function), it is recommended that the underlying hash function be
      the same as the one identified by hashAlgorithm; see Note 2 in
      Section 9.1 for further comments.

    * saltLength is the octet length of the salt.  It shall be an
      integer.  For a given hashAlgorithm, the default value of
      saltLength is the octet length of the hash value.  Unlike the
      other fields of type RSASSA-PSS-params, saltLength does not need
      to be fixed for a given RSA key pair.

    * trailerField is the trailer field number, for compatibility with
      the draft IEEE P1363a [27].  It shall be 1 for this version of the
      document, which represents the trailer field with hexadecimal
      value 0xbc.  Other trailer fields (including the trailer field
      HashID || 0xcc in IEEE P1363a) are not supported in this document.

         TrailerField ::= INTEGER { trailerFieldBC(1) }

      If the default values of the hashAlgorithm, maskGenAlgorithm, and
      trailerField fields of RSASSA-PSS-params are used, then the
      algorithm identifier will have the following value:

Top      Up      ToC       Page 51 
         rSASSA-PSS-Default-Identifier  RSASSA-AlgorithmIdentifier ::= {
             algorithm   id-RSASSA-PSS,
             parameters  RSASSA-PSS-params : {
                 hashAlgorithm       sha1,
                 maskGenAlgorithm    mgf1SHA1,
                 saltLength          20,
                 trailerField        trailerFieldBC
             }
         }

         RSASSA-AlgorithmIdentifier ::=
             AlgorithmIdentifier { {PKCS1Algorithms} }

   Note.  In some applications, the hash function underlying a signature
   scheme is identified separately from the rest of the operations in
   the signature scheme.  For instance, in PKCS #7 [45], a hash function
   identifier is placed before the message and a "digest encryption"
   algorithm identifier (indicating the rest of the operations) is
   carried with the signature.  In order for PKCS #7 to support the
   RSASSA-PSS signature scheme, an object identifier would need to be
   defined for the operations in RSASSA-PSS after the hash function
   (analogous to the RSAEncryption OID for the RSASSA-PKCS1-v1_5
   scheme).  S/MIME CMS [25] takes a different approach.  Although a
   hash function identifier is placed before the message, an algorithm
   identifier for the full signature scheme may be carried with a CMS
   signature (this is done for DSA signatures).  Following this
   convention, the id-RSASSA-PSS OID can be used to identify RSASSA-PSS
   signatures in CMS.  Since CMS is considered the successor to PKCS #7
   and new developments such as the addition of support for RSASSA-PSS
   will be pursued with respect to CMS rather than PKCS #7, an OID for
   the "rest of" RSASSA-PSS is not defined in this version of PKCS #1.

A.2.4 RSASSA-PKCS1-v1_5

   The object identifier for RSASSA-PKCS1-v1_5 shall be one of the
   following.  The choice of OID depends on the choice of hash
   algorithm: MD2, MD5, SHA-1, SHA-256, SHA-384, or SHA-512.  Note that
   if either MD2 or MD5 is used, then the OID is just as in PKCS #1
   v1.5.  For each OID, the parameters field associated with this OID in
   a value of type AlgorithmIdentifier shall have a value of type NULL.
   The OID should be chosen in accordance with the following table:

      Hash algorithm   OID
      --------------------------------------------------------
      MD2              md2WithRSAEncryption    ::= {pkcs-1 2}
      MD5              md5WithRSAEncryption    ::= {pkcs-1 4}
      SHA-1            sha1WithRSAEncryption   ::= {pkcs-1 5}
      SHA-256          sha256WithRSAEncryption ::= {pkcs-1 11}

Top      Up      ToC       Page 52 
      SHA-384          sha384WithRSAEncryption ::= {pkcs-1 12}
      SHA-512          sha512WithRSAEncryption ::= {pkcs-1 13}


   The EMSA-PKCS1-v1_5 encoding method includes an ASN.1 value of type
   DigestInfo, where the type DigestInfo has the syntax

      DigestInfo ::= SEQUENCE {
          digestAlgorithm DigestAlgorithm,
          digest OCTET STRING
      }

   digestAlgorithm identifies the hash function and shall be an
   algorithm ID with an OID in the set PKCS1-v1-5DigestAlgorithms.  For
   a discussion of supported hash functions, see Appendix B.1.

      DigestAlgorithm ::=
          AlgorithmIdentifier { {PKCS1-v1-5DigestAlgorithms} }

      PKCS1-v1-5DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
          { OID id-md2 PARAMETERS NULL    }|
          { OID id-md5 PARAMETERS NULL    }|
          { OID id-sha1 PARAMETERS NULL   }|
          { OID id-sha256 PARAMETERS NULL }|
          { OID id-sha384 PARAMETERS NULL }|
          { OID id-sha512 PARAMETERS NULL }
      }

Appendix B. Supporting techniques

   This section gives several examples of underlying functions
   supporting the encryption schemes in Section 7 and the encoding
   methods in Section 9.  A range of techniques is given here to allow
   compatibility with existing applications as well as migration to new
   techniques.  While these supporting techniques are appropriate for
   applications to implement, none of them is required to be
   implemented.  It is expected that profiles for PKCS #1 v2.1 will be
   developed that specify particular supporting techniques.

   This section also gives object identifiers for the supporting
   techniques.

B.1 Hash functions

   Hash functions are used in the operations contained in Sections 7 and
   9.  Hash functions are deterministic, meaning that the output is
   completely determined by the input.  Hash functions take octet
   strings of variable length, and generate fixed length octet strings.

Top      Up      ToC       Page 53 
   The hash functions used in the operations contained in Sections 7 and
   9 should generally be collision-resistant.  This means that it is
   infeasible to find two distinct inputs to the hash function that
   produce the same output.  A collision-resistant hash function also
   has the desirable property of being one-way; this means that given an
   output, it is infeasible to find an input whose hash is the specified
   output.  In addition to the requirements, the hash function should
   yield a mask generation function (Appendix B.2) with pseudorandom
   output.

   Six hash functions are given as examples for the encoding methods in
   this document: MD2 [33], MD5 [41], SHA-1 [38], and the proposed
   algorithms SHA-256, SHA-384, and SHA-512 [39].  For the RSAES-OAEP
   encryption scheme and EMSA-PSS encoding method, only SHA-1 and SHA-
   256/384/512 are recommended.  For the EMSA-PKCS1-v1_5 encoding
   method, SHA-1 or SHA-256/384/512 are recommended for new
   applications.  MD2 and MD5 are recommended only for compatibility
   with existing applications based on PKCS #1 v1.5.

   The object identifiers id-md2, id-md5, id-sha1, id-sha256, id-sha384,
   and id-sha512, identify the respective hash functions:

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

      id-md5      OBJECT IDENTIFIER ::= {
          iso(1) member-body(2) us(840) rsadsi(113549)
          digestAlgorithm(2) 5
      }

      id-sha1    OBJECT IDENTIFIER ::= {
          iso(1) identified-organization(3) oiw(14) secsig(3)
          algorithms(2) 26
      }

      id-sha256    OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840) organization(1)
          gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1
      }

      id-sha384    OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840) organization(1)
          gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2
      }

Top      Up      ToC       Page 54 
      id-sha512    OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840) organization(1)
          gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3
      }

   The parameters field associated with id-md2 and id-md5 in a value of
   type AlgorithmIdentifier shall have a value of type NULL.

   The parameters field associated with id-sha1, id-sha256, id-sha384,
   and id-sha512 should be omitted, but if present, shall have a value
   of type NULL.

   Note.  Version 1.5 of PKCS #1 also allowed for the use of MD4 in
   signature schemes.  The cryptanalysis of MD4 has progressed
   significantly in the intervening years.  For example, Dobbertin [18]
   demonstrated how to find collisions for MD4 and that the first two
   rounds of MD4 are not one-way [20].  Because of these results and
   others (e.g., [8]), MD4 is no longer recommended.  There have also
   been advances in the cryptanalysis of MD2 and MD5, although not
   enough to warrant removal from existing applications.  Rogier and
   Chauvaud [43] demonstrated how to find collisions in a modified
   version of MD2.  No one has demonstrated how to find collisions for
   the full MD5 algorithm, although partial results have been found
   (e.g., [9][19]).

   To address these concerns, SHA-1, SHA-256, SHA-384, or SHA-512 are
   recommended for new applications.  As of today, the best (known)
   collision attacks against these hash functions are generic attacks
   with complexity 2^(L/2), where L is the bit length of the hash
   output.  For the signature schemes in this document, a collision
   attack is easily translated into a signature forgery.  Therefore, the
   value L / 2 should be at least equal to the desired security level in
   bits of the signature scheme (a security level of B bits means that
   the best attack has complexity 2^B).  The same rule of thumb can be
   applied to RSAES-OAEP; it is recommended that the bit length of the
   seed (which is equal to the bit length of the hash output) be twice
   the desired security level in bits.

B.2 Mask generation functions

   A mask generation function takes an octet string of variable length
   and a desired output length as input, and outputs an octet string of
   the desired length.  There may be restrictions on the length of the
   input and output octet strings, but such bounds are generally very
   large.  Mask generation functions are deterministic; the octet string
   output is completely determined by the input octet string.  The
   output of a mask generation function should be pseudorandom: Given
   one part of the output but not the input, it should be infeasible to

Top      Up      ToC       Page 55 
   predict another part of the output.  The provable security of RSAES-
   OAEP and RSASSA-PSS relies on the random nature of the output of the
   mask generation function, which in turn relies on the random nature
   of the underlying hash.

   One mask generation function is given here: MGF1, which is based on a
   hash function.  MGF1 coincides with the mask generation functions
   defined in IEEE Std 1363-2000 [26] and the draft ANSI X9.44 [1].
   Future versions of this document may define other mask generation
   functions.

B.2.1 MGF1

   MGF1 is a Mask Generation Function based on a hash function.

   MGF1 (mgfSeed, maskLen)

   Options:
   Hash     hash function (hLen denotes the length in octets of the hash
            function output)

   Input:
   mgfSeed  seed from which mask is generated, an octet string
   maskLen  intended length in octets of the mask, at most 2^32 hLen

   Output:
   mask     mask, an octet string of length maskLen

   Error:   "mask too long"

   Steps:

   1. If maskLen > 2^32 hLen, output "mask too long" and stop.

   2. Let T be the empty octet string.

   3. For counter from 0 to \ceil (maskLen / hLen) - 1, do the
      following:

      a. Convert counter to an octet string C of length 4 octets (see
         Section 4.1):

            C = I2OSP (counter, 4) .

      b. Concatenate the hash of the seed mgfSeed and C to the octet
         string T:

            T = T || Hash(mgfSeed || C) .

Top      Up      ToC       Page 56 
   4. Output the leading maskLen octets of T as the octet string mask.

   The object identifier id-mgf1 identifies the MGF1 mask generation
   function:

   id-mgf1    OBJECT IDENTIFIER ::= { pkcs-1 8 }

   The parameters field associated with this OID in a value of type
   AlgorithmIdentifier shall have a value of type hashAlgorithm,
   identifying the hash function on which MGF1 is based.

Appendix C. ASN.1 module

PKCS-1 {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
    modules(0) pkcs-1(1)
}

-- $ Revision: 2.1r1 $

-- This module has been checked for conformance with the ASN.1
-- standard by the OSS ASN.1 Tools

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL
-- All types and values defined in this module are exported for use
-- in other ASN.1 modules.

IMPORTS

id-sha256, id-sha384, id-sha512
    FROM NIST-SHA2 {
        joint-iso-itu-t(2) country(16) us(840) organization(1)
        gov(101) csor(3) nistalgorithm(4) modules(0) sha2(1)
    };

-- ============================
--   Basic object identifiers
-- ============================

-- The DER encoding of this in hexadecimal is:
-- (0x)06 08
--        2A 86 48 86 F7 0D 01 01
--
pkcs-1    OBJECT IDENTIFIER ::= {

Top      Up      ToC       Page 57 
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1
}

--
-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
--
rsaEncryption    OBJECT IDENTIFIER ::= { pkcs-1 1 }

--
-- When id-RSAES-OAEP is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be RSAES-OAEP-params.
--
id-RSAES-OAEP    OBJECT IDENTIFIER ::= { pkcs-1 7 }

--
-- When id-pSpecified is used in an AlgorithmIdentifier the
-- parameters MUST be an OCTET STRING.
--
id-pSpecified    OBJECT IDENTIFIER ::= { pkcs-1 9 }

-- When id-RSASSA-PSS is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be RSASSA-PSS-params.
--
id-RSASSA-PSS    OBJECT IDENTIFIER ::= { pkcs-1 10 }

--
-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
--
md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }

--
-- This OID really belongs in a module with the secsig OIDs.
--
id-sha1    OBJECT IDENTIFIER ::= {
    iso(1) identified-organization(3) oiw(14) secsig(3)
    algorithms(2) 26
}

--
-- OIDs for MD2 and MD5, allowed only in EMSA-PKCS1-v1_5.
--

Top      Up      ToC       Page 58 
id-md2 OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2
}

id-md5 OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5
}

--
-- When id-mgf1 is used in an AlgorithmIdentifier the parameters MUST
-- be present and MUST be a HashAlgorithm, for example sha1.
--
id-mgf1    OBJECT IDENTIFIER ::= { pkcs-1 8 }

-- ================
--   Useful types
-- ================

ALGORITHM-IDENTIFIER ::= CLASS {
    &id    OBJECT IDENTIFIER  UNIQUE,
    &Type  OPTIONAL
}
    WITH SYNTAX { OID &id [PARAMETERS &Type] }

--
-- Note: the parameter InfoObjectSet in the following definitions
-- allows a distinct information object set to be specified for sets
-- of algorithms such as:
-- DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
--     { OID id-md2  PARAMETERS NULL }|
--     { OID id-md5  PARAMETERS NULL }|
--     { OID id-sha1 PARAMETERS NULL }
-- }
--

AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::=
SEQUENCE {
    algorithm  ALGORITHM-IDENTIFIER.&id({InfoObjectSet}),
    parameters
        ALGORITHM-IDENTIFIER.&Type({InfoObjectSet}{@.algorithm})
            OPTIONAL
}

-- ==============
--   Algorithms
-- ==============

--

Top      Up      ToC       Page 59 
-- Allowed EME-OAEP and EMSA-PSS digest algorithms.
--
OAEP-PSSDigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
    { OID id-sha1 PARAMETERS NULL   }|
    { OID id-sha256 PARAMETERS NULL }|
    { OID id-sha384 PARAMETERS NULL }|
    { OID id-sha512 PARAMETERS NULL },
    ...  -- Allows for future expansion --
}

--
-- Allowed EMSA-PKCS1-v1_5 digest algorithms.
--
PKCS1-v1-5DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
    { OID id-md2 PARAMETERS NULL    }|
    { OID id-md5 PARAMETERS NULL    }|
    { OID id-sha1 PARAMETERS NULL   }|
    { OID id-sha256 PARAMETERS NULL }|
    { OID id-sha384 PARAMETERS NULL }|
    { OID id-sha512 PARAMETERS NULL }
}

-- When id-md2 and id-md5 are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

-- When id-sha1, id-sha256, id-sha384 and id-sha512 are used in an
-- AlgorithmIdentifier the parameters (which are optional) SHOULD
-- be omitted. However, an implementation MUST also accept
-- AlgorithmIdentifier values where the parameters are NULL.

sha1    HashAlgorithm ::= {
    algorithm   id-sha1,
    parameters  SHA1Parameters : NULL  -- included for compatibility
                                       -- with existing implementations
}

HashAlgorithm ::= AlgorithmIdentifier { {OAEP-PSSDigestAlgorithms} }

SHA1Parameters ::= NULL

--
-- Allowed mask generation function algorithms.
-- If the identifier is id-mgf1, the parameters are a HashAlgorithm.
--
PKCS1MGFAlgorithms    ALGORITHM-IDENTIFIER ::= {
    { OID id-mgf1 PARAMETERS HashAlgorithm },
    ...  -- Allows for future expansion --
}

Top      Up      ToC       Page 60 
--
-- Default AlgorithmIdentifier for id-RSAES-OAEP.maskGenAlgorithm and
-- id-RSASSA-PSS.maskGenAlgorithm.
--
mgf1SHA1    MaskGenAlgorithm ::= {
    algorithm   id-mgf1,
    parameters  HashAlgorithm : sha1
}

MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} }

--
-- Allowed algorithms for pSourceAlgorithm.
--
PKCS1PSourceAlgorithms    ALGORITHM-IDENTIFIER ::= {
    { OID id-pSpecified PARAMETERS EncodingParameters },
    ...  -- Allows for future expansion --
}

EncodingParameters ::= OCTET STRING(SIZE(0..MAX))

--
-- This identifier means that the label L is an empty string, so the
-- digest of the empty string appears in the RSA block before
-- masking.
--
pSpecifiedEmpty    PSourceAlgorithm ::= {
    algorithm   id-pSpecified,
    parameters  EncodingParameters : emptyString
}

PSourceAlgorithm ::= AlgorithmIdentifier { {PKCS1PSourceAlgorithms} }

emptyString    EncodingParameters ::= ''H

--
-- Type identifier definitions for the PKCS #1 OIDs.
--
PKCS1Algorithms    ALGORITHM-IDENTIFIER ::= {
    { OID rsaEncryption              PARAMETERS NULL } |
    { OID md2WithRSAEncryption       PARAMETERS NULL } |
    { OID md5WithRSAEncryption       PARAMETERS NULL } |
    { OID sha1WithRSAEncryption      PARAMETERS NULL } |
    { OID sha256WithRSAEncryption    PARAMETERS NULL } |
    { OID sha384WithRSAEncryption    PARAMETERS NULL } |
    { OID sha512WithRSAEncryption    PARAMETERS NULL } |
    { OID id-RSAES-OAEP PARAMETERS RSAES-OAEP-params } |
    PKCS1PSourceAlgorithms                             |

Top      Up      ToC       Page 61 
    { OID id-RSASSA-PSS PARAMETERS RSASSA-PSS-params } ,
    ...  -- Allows for future expansion --
}

-- ===================
--   Main structures
-- ===================

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

--
-- Representation of RSA private key with information for the CRT
-- algorithm.
--
RSAPrivateKey ::= SEQUENCE {
    version           Version,
    modulus           INTEGER,  -- n
    publicExponent    INTEGER,  -- e
    privateExponent   INTEGER,  -- d
    prime1            INTEGER,  -- p
    prime2            INTEGER,  -- q
    exponent1         INTEGER,  -- d mod (p-1)
    exponent2         INTEGER,  -- d mod (q-1)
    coefficient       INTEGER,  -- (inverse of q) mod p
    otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

Version ::= INTEGER { two-prime(0), multi(1) }
    (CONSTRAINED BY {
        -- version must be multi if otherPrimeInfos present --
    })

OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo

OtherPrimeInfo ::= SEQUENCE {
    prime             INTEGER,  -- ri
    exponent          INTEGER,  -- di
    coefficient       INTEGER   -- ti
}

--
-- AlgorithmIdentifier.parameters for id-RSAES-OAEP.
-- Note that the tags in this Sequence are explicit.
--
RSAES-OAEP-params ::= SEQUENCE {

Top      Up      ToC       Page 62 
    hashAlgorithm      [0] HashAlgorithm     DEFAULT sha1,
    maskGenAlgorithm   [1] MaskGenAlgorithm  DEFAULT mgf1SHA1,
    pSourceAlgorithm   [2] PSourceAlgorithm  DEFAULT pSpecifiedEmpty
}

--
-- Identifier for default RSAES-OAEP algorithm identifier.
-- The DER Encoding of this is in hexadecimal:
-- (0x)30 0D
--        06 09
--           2A 86 48 86 F7 0D 01 01 07
--        30 00
-- Notice that the DER encoding of default values is "empty".
--

rSAES-OAEP-Default-Identifier    RSAES-AlgorithmIdentifier ::= {
    algorithm   id-RSAES-OAEP,
    parameters  RSAES-OAEP-params : {
        hashAlgorithm       sha1,
        maskGenAlgorithm    mgf1SHA1,
        pSourceAlgorithm    pSpecifiedEmpty
    }
}

RSAES-AlgorithmIdentifier ::=
    AlgorithmIdentifier { {PKCS1Algorithms} }

--
-- AlgorithmIdentifier.parameters for id-RSASSA-PSS.
-- Note that the tags in this Sequence are explicit.
--
RSASSA-PSS-params ::= SEQUENCE {
    hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
    maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1,
    saltLength         [2] INTEGER            DEFAULT 20,
    trailerField       [3] TrailerField       DEFAULT trailerFieldBC
}

TrailerField ::= INTEGER { trailerFieldBC(1) }

--
-- Identifier for default RSASSA-PSS algorithm identifier
-- The DER Encoding of this is in hexadecimal:
-- (0x)30 0D
--        06 09
--           2A 86 48 86 F7 0D 01 01 0A
--        30 00
-- Notice that the DER encoding of default values is "empty".

Top      Up      ToC       Page 63 
--
rSASSA-PSS-Default-Identifier    RSASSA-AlgorithmIdentifier ::= {
    algorithm   id-RSASSA-PSS,
    parameters  RSASSA-PSS-params : {
        hashAlgorithm       sha1,
        maskGenAlgorithm    mgf1SHA1,
        saltLength          20,
        trailerField        trailerFieldBC
    }
}

RSASSA-AlgorithmIdentifier ::=
    AlgorithmIdentifier { {PKCS1Algorithms} }

--
-- Syntax for the EMSA-PKCS1-v1_5 hash identifier.
--
DigestInfo ::= SEQUENCE {
    digestAlgorithm DigestAlgorithm,
    digest OCTET STRING
}

DigestAlgorithm ::=
    AlgorithmIdentifier { {PKCS1-v1-5DigestAlgorithms} }

END  -- PKCS1Definitions

Appendix D. Intellectual Property Considerations

   The RSA public-key cryptosystem is described in U.S. Patent
   4,405,829, which expired on September 20, 2000.  RSA Security Inc.
   makes no other patent claims on the constructions described in this
   document, although specific underlying techniques may be covered.

   Multi-prime RSA is described in U.S. Patent 5,848,159.

   The University of California has indicated that it has a patent
   pending on the PSS signature scheme [5].  It has also provided a
   letter to the IEEE P1363 working group stating that if the PSS
   signature scheme is included in an IEEE standard, "the University of
   California will, when that standard is adopted, FREELY license any
   conforming implementation of PSS as a technique for achieving a
   digital signature with appendix" [23].  The PSS signature scheme is
   specified in the IEEE P1363a draft [27], which was in ballot
   resolution when this document was published.

Top      Up      ToC       Page 64 
   License to copy this document is granted provided that it is
   identified as "RSA Security Inc.  Public-Key Cryptography Standards
   (PKCS)" in all material mentioning or referencing this document.

   RSA Security Inc. makes no other representations regarding
   intellectual property claims by other parties.  Such determination is
   the responsibility of the user.

Appendix E. Revision history

   Versions 1.0 - 1.3

      Versions 1.0 - 1.3 were distributed to participants in RSA Data
      Security, Inc.'s Public-Key Cryptography Standards meetings in
      February and March 1991.

   Version 1.4

      Version 1.4 was part of the June 3, 1991 initial public release of
      PKCS.  Version 1.4 was published as NIST/OSI Implementors'
      Workshop document SEC-SIG-91-18.

   Version 1.5

      Version 1.5 incorporated several editorial changes, including
      updates to the references and the addition of a revision history.
      The following substantive changes were made:

      -  Section 10: "MD4 with RSA" signature and verification processes
         were added.
      -  Section 11: md4WithRSAEncryption object identifier was added.

      Version 1.5 was republished as IETF RFC 2313.

   Version 2.0

      Version 2.0 incorporated major editorial changes in terms of the
      document structure and introduced the RSAES-OAEP encryption
      scheme.  This version continued to support the encryption and
      signature processes in version 1.5, although the hash algorithm
      MD4 was no longer allowed due to cryptanalytic advances in the
      intervening years.  Version 2.0 was republished as IETF RFC 2437
      [35].

Top      Up      ToC       Page 65 
   Version 2.1

      Version 2.1 introduces multi-prime RSA and the RSASSA-PSS
      signature scheme with appendix along with several editorial
      improvements.  This version continues to support the schemes in
      version 2.0.

Appendix F. References

   [1]   ANSI X9F1 Working Group.  ANSI X9.44 Draft D2: Key
         Establishment Using Integer Factorization Cryptography.
         Working Draft, March 2002.

   [2]   M. Bellare, A. Desai, D. Pointcheval and P. Rogaway.  Relations
         Among Notions of Security for Public-Key Encryption Schemes.
         In H. Krawczyk, editor, Advances in Cryptology - Crypto '98,
         volume 1462 of Lecture Notes in Computer Science, pp. 26 - 45.
         Springer Verlag, 1998.

   [3]   M. Bellare and P. Rogaway.  Optimal Asymmetric Encryption - How
         to Encrypt with RSA.  In A. De Santis, editor, Advances in
         Cryptology - Eurocrypt '94, volume 950 of Lecture Notes in
         Computer Science, pp. 92 - 111.  Springer Verlag, 1995.

   [4]   M. Bellare and P. Rogaway.  The Exact Security of Digital
         Signatures - How to Sign with RSA and Rabin.  In U. Maurer,
         editor, Advances in Cryptology - Eurocrypt '96, volume 1070 of
         Lecture Notes in Computer Science, pp. 399 - 416.  Springer
         Verlag, 1996.

   [5]   M. Bellare and P. Rogaway.  PSS: Provably Secure Encoding
         Method for Digital Signatures.  Submission to IEEE P1363
         working group, August 1998.  Available from
         http://grouper.ieee.org/groups/1363/.

   [6]   D. Bleichenbacher.  Chosen Ciphertext Attacks Against Protocols
         Based on the RSA Encryption Standard PKCS #1.  In H. Krawczyk,
         editor, Advances in Cryptology - Crypto '98, volume 1462 of
         Lecture Notes in Computer Science, pp. 1 - 12.  Springer
         Verlag, 1998.

   [7]   D. Bleichenbacher, B. Kaliski and J. Staddon.  Recent Results
         on PKCS #1: RSA Encryption Standard.  RSA Laboratories'
         Bulletin No. 7, June 1998.

Top      Up      ToC       Page 66 
   [8]   B. den Boer and A. Bosselaers.  An Attack on the Last Two
         Rounds of MD4.  In J.  Feigenbaum, editor, Advances in
         Cryptology - Crypto '91, volume 576 of Lecture Notes in
         Computer Science, pp. 194 - 203.  Springer Verlag, 1992.

   [9]   B. den Boer and A. Bosselaers.  Collisions for the Compression
         Function of MD5.  In T. Helleseth, editor, Advances in
         Cryptology - Eurocrypt '93, volume 765 of Lecture Notes in
         Computer Science, pp. 293 - 304.  Springer Verlag, 1994.

   [10]  D. Coppersmith, M. Franklin, J. Patarin and M. Reiter.  Low-
         Exponent RSA with Related Messages.  In U. Maurer, editor,
         Advances in Cryptology - Eurocrypt '96, volume 1070 of Lecture
         Notes in Computer Science, pp. 1 - 9.  Springer Verlag, 1996.

   [11]  D. Coppersmith, S. Halevi and C. Jutla.  ISO 9796-1 and the New
         Forgery Strategy.  Presented at the rump session of Crypto '99,
         August 1999.

   [12]  J.-S. Coron.  On the Exact Security of Full Domain Hashing.  In
         M. Bellare, editor, Advances in Cryptology - Crypto 2000,
         volume 1880 of Lecture Notes in Computer Science, pp. 229 -
         235.  Springer Verlag, 2000.

   [13]  J.-S. Coron.  Optimal Security Proofs for PSS and Other
         Signature Schemes.   In L. Knudsen, editor, Advances in
         Cryptology - Eurocrypt 2002, volume 2332 of Lecture Notes in
         Computer Science, pp. 272 - 287.  Springer Verlag, 2002.

   [14]  J.-S. Coron, M. Joye, D. Naccache and P. Paillier.  New Attacks
         on PKCS #1 v1.5 Encryption.  In B. Preneel, editor, Advances in
         Cryptology - Eurocrypt 2000, volume 1807 of Lecture Notes in
         Computer Science, pp. 369 - 379.  Springer Verlag, 2000.

   [15]  J.-S. Coron, D. Naccache and J. P. Stern.  On the Security of
         RSA Padding.  In M. Wiener, editor, Advances in Cryptology -
         Crypto '99, volume 1666 of Lecture Notes in Computer Science,
         pp. 1 - 18.  Springer Verlag, 1999.

   [16]  Y. Desmedt and A.M. Odlyzko.  A Chosen Text Attack on the RSA
         Cryptosystem and Some Discrete Logarithm Schemes.  In H.C.
         Williams, editor, Advances in Cryptology - Crypto '85, volume
         218 of Lecture Notes in Computer Science, pp. 516 - 522.
         Springer Verlag, 1986.

   [17]  Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
         2246, January 1999.

Top      Up      ToC       Page 67 
   [18]  H. Dobbertin.  Cryptanalysis of MD4.  In D. Gollmann, editor,
         Fast Software Encryption '96, volume 1039 of Lecture Notes in
         Computer Science, pp. 55 - 72.  Springer Verlag, 1996.

   [19]  H. Dobbertin.  Cryptanalysis of MD5 Compress.  Presented at the
         rump session of Eurocrypt '96, May 1996.

   [20]  H. Dobbertin.  The First Two Rounds of MD4 are Not One-Way.  In
         S. Vaudenay, editor, Fast Software Encryption '98, volume 1372
         in Lecture Notes in Computer Science, pp. 284 - 292.  Springer
         Verlag, 1998.

   [21]  E. Fujisaki, T. Okamoto, D. Pointcheval and J. Stern.  RSA-OAEP
         is Secure under the RSA Assumption.  In J. Kilian, editor,
         Advances in Cryptology - Crypto 2001, volume 2139 of Lecture
         Notes in Computer Science, pp. 260 - 274.  Springer Verlag,
         2001.

   [22]  H. Garner.  The Residue Number System.  IRE Transactions on
         Electronic Computers, EC-8 (6), pp. 140 - 147, June 1959.

   [23]  M.L. Grell.  Re: Encoding Methods PSS/PSS-R.  Letter to IEEE
         P1363 working group, University of California, June 15, 1999.
         Available from
         http://grouper.ieee.org/groups/1363/P1363/patents.html.

   [24]  J. Haastad.  Solving Simultaneous Modular Equations of Low
         Degree.  SIAM Journal of Computing, volume 17, pp. 336 - 341,
         1988.

   [25]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
         August 2002.  Housley, R., "Cryptographic Message Syntax (CMS)
         Algorithms", RFC 3370, August 2002.

   [26]  IEEE Std 1363-2000: Standard Specifications for Public Key
         Cryptography.  IEEE, August 2000.

   [27]  IEEE P1363 working group.  IEEE P1363a D11: Draft Standard
         Specifications for Public Key Cryptography -- Amendment 1:
         Additional Techniques. December 16, 2002.  Available from
         http://grouper.ieee.org/groups/1363/.

   [28]  ISO/IEC 9594-8:1997: Information technology - Open Systems
         Interconnection - The Directory: Authentication Framework.
         1997.

Top      Up      ToC       Page 68 
   [29]  ISO/IEC FDIS 9796-2: Information Technology - Security
         Techniques - Digital Signature Schemes Giving Message Recovery
         - Part 2: Integer Factorization Based Mechanisms.  Final Draft
         International Standard, December 2001.

   [30]  ISO/IEC 18033-2: Information Technology - Security Techniques -
         Encryption Algorithms - Part 2: Asymmetric Ciphers.  V. Shoup,
         editor, Text for 2nd Working Draft, January 2002.

   [31]  J. Jonsson.  Security Proof for the RSA-PSS Signature Scheme
         (extended abstract).  Second Open NESSIE Workshop.  September
         2001.  Full version available from
         http://eprint.iacr.org/2001/053/.

   [32]  J. Jonsson and B. Kaliski.  On the Security of RSA Encryption
         in TLS.  In M. Yung, editor, Advances in Cryptology - CRYPTO
         2002, vol. 2442 of Lecture Notes in Computer Science, pp. 127 -
         142.  Springer Verlag, 2002.

   [33]  Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
         April 1992.

   [34]  B. Kaliski.  On Hash Function Identification in Signature
         Schemes.  In B. Preneel, editor, RSA Conference 2002,
         Cryptographers' Track, volume 2271 of Lecture Notes in Computer
         Science, pp. 1 - 16.  Springer Verlag, 2002.

   [35]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
         Specifications Version 2.0", RFC 2437, October 1998.

   [36]  J. Manger.  A Chosen Ciphertext Attack on RSA Optimal
         Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1
         v2.0. In J. Kilian, editor, Advances in Cryptology - Crypto
         2001, volume 2139 of Lecture Notes in Computer Science, pp. 260
         - 274.  Springer Verlag, 2001.

   [37]  A. Menezes, P. van Oorschot and S. Vanstone.  Handbook of
         Applied Cryptography.  CRC Press, 1996.

   [38]  National Institute of Standards and Technology (NIST).  FIPS
         Publication 180-1: Secure Hash Standard.  April 1994.

   [39]  National Institute of Standards and Technology (NIST).  Draft
         FIPS 180-2: Secure Hash Standard.  Draft, May 2001.  Available
         from http://www.nist.gov/sha/.

Top      Up      ToC       Page 69 
   [40]  J.-J. Quisquater and C. Couvreur.  Fast Decipherment Algorithm
         for RSA Public-Key Cryptosystem.  Electronics Letters, 18 (21),
         pp. 905 - 907, October 1982.

   [41]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
         1992.

   [42]  R. Rivest, A. Shamir and L. Adleman.  A Method for Obtaining
         Digital Signatures and Public-Key Cryptosystems.
         Communications of the ACM, 21 (2), pp. 120-126, February 1978.

   [43]  N. Rogier and P. Chauvaud.  The Compression Function of MD2 is
         not Collision Free.  Presented at Selected Areas of
         Cryptography '95.  Carleton University, Ottawa, Canada.  May
         1995.

   [44]  RSA Laboratories.  PKCS #1 v2.0: RSA Encryption Standard.
         October 1998.

   [45]  RSA Laboratories.  PKCS #7 v1.5: Cryptographic Message Syntax
         Standard.  November 1993.  (Republished as IETF RFC 2315.)

   [46]  RSA Laboratories.  PKCS #8 v1.2: Private-Key Information Syntax
         Standard.  November 1993.

   [47]  RSA Laboratories.  PKCS #12 v1.0: Personal Information Exchange
         Syntax Standard.  June 1999.

   [48]  V. Shoup.  OAEP Reconsidered.  In J. Kilian, editor, Advances
         in Cryptology - Crypto 2001, volume 2139 of Lecture Notes in
         Computer Science, pp. 239 - 259.  Springer Verlag, 2001.

   [49]  R. D. Silverman.  A Cost-Based Security Analysis of Symmetric
         and Asymmetric Key Lengths.  RSA Laboratories Bulletin No. 13,
         April 2000.  Available from
         http://www.rsasecurity.com.rsalabs/bulletins/.

   [50]  G. J. Simmons.  Subliminal communication is easy using the DSA.
         In T. Helleseth, editor, Advances in Cryptology - Eurocrypt
         '93, volume 765 of Lecture Notes in Computer Science, pp. 218-
         232.  Springer-Verlag, 1993.

Top      Up      ToC       Page 70 
Appendix G. About PKCS

   The Public-Key Cryptography Standards are specifications produced by
   RSA Laboratories in cooperation with secure systems developers
   worldwide for the purpose of accelerating the deployment of
   public-key cryptography.  First published in 1991 as a result of
   meetings with a small group of early adopters of public-key
   technology, the PKCS documents have become widely referenced and
   implemented.  Contributions from the PKCS series have become part of
   many formal and de facto standards, including ANSI X9 and IEEE P1363
   documents, PKIX, SET, S/MIME, SSL/TLS, and WAP/WTLS.

   Further development of PKCS occurs through mailing list discussions
   and occasional workshops, and suggestions for improvement are
   welcome.  For more information, contact:

      PKCS Editor
      RSA Laboratories
      174 Middlesex Turnpike
      Bedford, MA  01730 USA
      pkcs-editor@rsasecurity.com
      http://www.rsasecurity.com/rsalabs/pkcs

Appendix H. Corrections Made During RFC Publication Process

   The following corrections were made in converting the PKCS #1 v2.1
   document to this RFC:

   *  The requirement that the parameters in an AlgorithmIdentifier
      value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was
      changed to a recommendation that the parameters be omitted (while
      still allowing the parameters to be NULL). This is to align with
      the definitions originally promulgated by NIST. Implementations
      MUST accept AlgorithmIdentifier values both without parameters and
      with NULL parameters.

   *  The notes after RSADP and RSASP1 (Secs. 5.1.2 and 5.2.1) were
      corrected to refer to step 2.b rather than 2.a.

   *  References [25], [27] and [32] were updated to reflect new
      publication data.

   These corrections will be reflected in future editions of PKCS #1
   v2.1.

Security Considerations

   Security issues are discussed throughout this memo.

Top      Up      ToC       Page 71 
Acknowledgements

   This document is based on a contribution of RSA Laboratories, the
   research center of RSA Security Inc.  Any substantial use of the text
   from this document must acknowledge RSA Security Inc.  RSA Security
   Inc. requests that all material mentioning or referencing this
   document identify this as "RSA Security Inc. PKCS #1 v2.1".

Authors' Addresses

   Jakob Jonsson
   Philipps-Universitaet Marburg
   Fachbereich Mathematik und Informatik
   Hans Meerwein Strasse, Lahnberge
   DE-35032 Marburg
   Germany

   Phone: +49 6421 28 25672
   EMail: jonsson@mathematik.uni-marburg.de


   Burt Kaliski
   RSA Laboratories
   174 Middlesex Turnpike
   Bedford, MA 01730 USA

   Phone: +1 781 515 7073
   EMail: bkaliski@rsasecurity.com

Top      Up      ToC       Page 72 
Full Copyright Statement

   Copyright (C) The Internet Society 2003.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others provided that the above copyright notice and this paragraph
   are included on all such copies.  However, this document itself may
   not be modified in any way, such as by removing the copyright notice
   or references to the Internet Society or other Internet
   organizations, except as required to translate it into languages
   other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.