rfc3279.txt

RFC 的详细文档！

   Certificates conforming to [RFC 3280] 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, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms.  Conforming CAs
   MUST use the identified OIDs when issuing certificates containing





Polk, et al.                Standards Track                     [Page 7]

RFC 3279               Algorithms and Identifiers             April 2002


   public keys for these algorithms.  Conforming applications supporting
   any of these algorithms MUST, at a minimum, recognize the OID
   identified in this section.

2.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 MUST
   have ASN.1 type NULL for this algorithm identifier.

   The RSA public key MUST 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 [RFC 3280]).  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 or CRL issuer
   certificate which conveys an RSA public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;



Polk, et al.                Standards Track                     [Page 8]

RFC 3279               Algorithms and Identifiers             April 2002


      keyEncipherment;
      dataEncipherment;
      keyCertSign; and
      cRLSign.

   However, this specification RECOMMENDS that if keyCertSign or cRLSign
   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
   present.

2.3.2  DSA Signature Keys

   The Digital Signature Algorithm (DSA) is defined in the Digital
   Signature Standard (DSS) [FIPS 186].  The DSA OID supported by this
   profile is:

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

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

   If the DSA domain 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  }

   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used.  If the DSA
   algorithm parameters are omitted 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 domain parameters are omitted from the
   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using a signature algorithm other than DSA, then
   the subject's DSA domain parameters are distributed by other means.
   If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
   parameters component, the CA signed the subject with a signature
   algorithm other than DSA, and the subject's DSA parameters are not
   available through other means, then clients MUST reject the
   certificate.




Polk, et al.                Standards Track                     [Page 9]

RFC 3279               Algorithms and Identifiers             April 2002


   The DSA public key MUST 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;
      nonRepudiation;

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys a DSA public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyCertSign; and
      cRLSign.

2.3.3  Diffie-Hellman Key Exchange Keys

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

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

   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 }





Polk, et al.                Standards Track                    [Page 10]

RFC 3279               Algorithms and Identifiers             April 2002


   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 domain parameter generation process; and

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

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

   The Diffie-Hellman public key MUST 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

   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.

   If present, the keyUsage extension MUST assert keyAgreement and MAY
   assert either encipherOnly and decipherOnly.  The keyUsage extension
   MUST NOT assert both encipherOnly and decipherOnly.

2.3.4 KEA Public Keys

   This section identifies the preferred OID and parameters for the
   inclusion of a KEA public key in a certificate.  The Key Exchange
   Algorithm (KEA) is a key agreement algorithm.  Two parties may
   generate a "pairwise key" if and only if they share the same KEA
   parameters.  The KEA parameters are not included in a certificate;
   instead a domain identifier is supplied in the parameters field.




Polk, et al.                Standards Track                    [Page 11]

RFC 3279               Algorithms and Identifiers             April 2002


   When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
   identifier and parameters SHALL be as defined in [SDN.701r]:

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

   CAs MUST populate the parameters field of the AlgorithmIdentifier
   within the SubjectPublicKeyInfo field of each certificate containing
   a KEA public key with an 80-bit parameter identifier (OCTET STRING),
   also known as the domain identifier.  The domain identifier is
   computed in three steps:

      (1) the KEA domain parameters (p, q, and g) are DER encoded using
      the Dss-Parms structure;

      (2) a 160-bit SHA-1 hash is generated from the parameters; and

      (3) the 160-bit hash is reduced to 80-bits by performing an
      "exclusive or" of the 80 high order bits with the 80 low order
      bits.

   The resulting value is encoded such that the most significant byte of
   the 80-bit value is the first octet in the octet string.  The Dss-
   Parms is provided above in Section 2.3.2.

   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
   such that the most significant bit (MSB) of y becomes the MSB of the
   BIT STRING value field and the least significant bit (LSB) of y
   becomes the LSB of the BIT STRING value field.  This results in the
   following encoding:

      BIT STRING tag;
      BIT STRING length;
      0 (indicating that there are zero unused bits in the final octet
      of y); and
      BIT STRING value field including y.

   The key usage extension may optionally appear in a KEA certificate.
   If a KEA certificate includes the keyUsage extension, only the
   following values may be asserted:

      keyAgreement;
      encipherOnly; and
      decipherOnly.





Polk, et al.                Standards Track                    [Page 12]

RFC 3279               Algorithms and Identifiers             April 2002


   If present, the keyUsage extension MUST assert keyAgreement and MAY
   assert either encipherOnly and decipherOnly.  The keyUsage extension
   MUST NOT assert both encipherOnly and decipherOnly.

2.3.5 ECDSA and ECDH Keys

   This section identifies the preferred OID and parameter encoding for
   the inclusion of an ECDSA or ECDH public key in a certificate.  The
   Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
   [X9.62].  ECDSA is the elliptic curve mathematical analog of the
   Digital Signature Algorithm [FIPS 186].  The Elliptic Curve Diffie
   Hellman (ECDH) algorithm is a key agreement algorithm defined in
   [X9.63].

   ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
   key agreement algorithm as specified in [X9.42].  The ECDSA and ECDH
   specifications use the same OIDs and parameter encodings.  The ASN.1
   object identifiers used to identify these public keys are defined in
   the following arc:

   ansi-X9-62 OBJECT IDENTIFIER ::=
                             { iso(1) member-body(2) us(840) 10045 }

   When certificates contain an ECDSA or ECDH public key, the
   id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
   algorithm identifier is defined as follows:

     id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }

     id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

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

   ECDSA and ECDH require use of certain parameters with the public key.
   The parameters may be inherited from the issuer, implicitly included
   through reference to a "named curve," or explicitly included in the
   certificate.

      EcpkParameters ::= CHOICE {
        ecParameters  ECParameters,
        namedCurve    OBJECT IDENTIFIER,
        implicitlyCA  NULL }





Polk, et al.                Standards Track                    [Page 13]

RFC 3279               Algorithms and Identifiers             April 2002


   When the parameters are inherited, the parameters field SHALL contain
   implictlyCA, which is the ASN.1 value NULL.  When parameters are
   specified by reference, the parameters field SHALL contain the
   named-Curve choice, which is an object identifier.  When the
   parameters are explicitly included, they SHALL be encoded in the
   ASN.1 structure ECParameters:

      ECParameters ::= SEQUENCE {
         version   ECPVer,          -- version is always 1
         fieldID   FieldID,         -- identifies the finite field over
                                    -- which the curve is defined
         curve     Curve,           -- coefficients a and b of the
                                    -- elliptic curve
         base      ECPoint,         -- specifies the base point P
                                    -- on the elliptic curve
         order     INTEGER,         -- the order n of the base point
         cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
         }

      ECPVer ::= INTEGER {ecpVer1(1)}

      Curve ::= SEQUENCE {
         a         FieldElement,
         b         FieldElement,