home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2314.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  15.4 KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       B. Kaliski
  8. Request for Comments: 2314                       RSA Laboratories East
  9. Category: Informational                                     March 1998
  10.  
  11.  
  12.                  PKCS #10: Certification Request Syntax
  13.                               Version 1.5
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard of any kind.  Distribution of this
  19.    memo is unlimited.
  20.  
  21. Copyright Notice
  22.  
  23.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  24.  
  25. Overview
  26.  
  27.    This document describes a syntax for certification requests.
  28.  
  29. 1. Scope
  30.  
  31.    A certification request consists of a distinguished name, a public
  32.    key, and optionally a set of attributes, collectively signed by the
  33.    entity requesting certification. Certification requests are sent to a
  34.    certification authority, who transforms the request to an X.509
  35.    public-key certificate, or a PKCS #6 extended certificate. (In what
  36.    form the certification authority returns the newly signed certificate
  37.    is outside the scope of this document. A PKCS #7 message is one
  38.    possibility.)
  39.  
  40.    The intention of including a set of attributes is twofold: to provide
  41.    other information about a given entity, such as the postal address to
  42.    which the signed certificate should be returned if electronic mail is
  43.    not available, or a "challenge password" by which the entity may
  44.    later request certificate revocation; and to provide attributes for a
  45.    PKCS #6 extended certificate. A non-exhaustive list of attributes is
  46.    given in PKCS #9.
  47.  
  48.    Certification authorities may also require non-electronic forms of
  49.    request and may return non-electronic replies. It is expected that
  50.    descriptions of such forms, which are outside the scope of this
  51.    document, will be available from the certification authority.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Kaliski                      Informational                      [Page 1]
  59.  
  60. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  61.  
  62.  
  63.    The preliminary intended application of this document is to support
  64.    PKCS #7 cryptographic messages, but is expected that other
  65.    applications will be developed.
  66.  
  67. 2. References
  68.  
  69.    PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption
  70.              Standard. Version 1.5, November 1993.
  71.  
  72.    PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
  73.              Syntax. Version 1.5, November 1993.
  74.  
  75.    PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
  76.              Syntax. Version 1.5, November 1993.
  77.  
  78.    PKCS #9   RSA Laboratories. PKCS #9: Selected Attribute
  79.              Types. Version 1.1, November 1993.
  80.  
  81.    RFC 1424  Kaliski, B., "Privacy Enhancement for
  82.              Internet Electronic Mail: Part IV: Key
  83.              Certification and Related Services," RFC 1424,
  84.              February 1993.
  85.  
  86.    X.208     CCITT. Recommendation X.208: Specification of
  87.              Abstract Syntax Notation One (ASN.1). 1988.
  88.  
  89.    X.209     CCITT. Recommendation X.209: Specification of
  90.              Basic Encoding Rules for Abstract Syntax Notation
  91.              One (ASN.1). 1988.
  92.  
  93.    X.500     CCITT. Recommendation X.500: The Directory--
  94.              Overview of Concepts, Models and
  95.              Services. 1988.
  96.  
  97.    X.501     CCITT. Recommendation X.501: The Directory--
  98.              Models. 1988.
  99.  
  100.    X.509     CCITT. Recommendation X.509: The Directory--
  101.              Authentication Framework. 1988.
  102.  
  103. 3. Definitions
  104.  
  105.    For the purposes of this document, the following definitions apply.
  106.  
  107.    AlgorithmIdentifier: A type that identifies an algorithm (by object
  108.    identifier) and any associated parameters. This type is defined in
  109.    X.509.
  110.  
  111.  
  112.  
  113.  
  114. Kaliski                      Informational                      [Page 2]
  115.  
  116. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  117.  
  118.  
  119.    Attribute: A type that contains an attribute type (specified by
  120.    object identifier) and one or more attribute values. This type is
  121.    defined in X.501.
  122.  
  123.    ASN.1: Abstract Syntax Notation One, as defined in X.208.
  124.  
  125.    BER: Basic Encoding Rules, as defined in X.209.
  126.  
  127.    Certificate: A type that binds an entity's distinguished name to a
  128.    public key with a digital signature. This type is defined in X.509.
  129.    This type also contains the distinguished name of the certificate
  130.    issuer (the signer), an issuer- specific serial number, the issuer's
  131.    signature algorithm identifier, and a validity period.
  132.  
  133.    DER: Distinguished Encoding Rules for ASN.1, as defined in X.509,
  134.    Section 8.7.
  135.  
  136.    Name: A type that uniquely identifies or "distinguishes" objects in a
  137.    X.500 directory. This type is defined in X.501.  In an X.509
  138.    certificate, the type identifies the certificate issuer and the
  139.    entity whose public key is certified.
  140.  
  141. 4. Symbols and abbreviations
  142.  
  143.    No symbols or abbreviations are defined in this document.
  144.  
  145. 5. General overview
  146.  
  147.    The next section specifies certification request syntax.
  148.  
  149.    This document exports one type, CertificationRequest.
  150.  
  151. 6. Certification request syntax
  152.  
  153.    This section gives the syntax for certification requests.
  154.  
  155.    A certification request consists of three parts: "certification
  156.    request information," a signature algorithm identifier, and a digital
  157.    signature on the certification request information. The certification
  158.    request information consists of the entity's distinguished name, the
  159.    entity's public key, and a set of attributes providing other
  160.    information about the entity.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Kaliski                      Informational                      [Page 3]
  171.  
  172. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  173.  
  174.  
  175.    The process by which a certification request is constructed involves
  176.    the following steps:
  177.  
  178.         1.   A CertificationRequestInfo value containing a
  179.              distinguished name, a public key, and optionally a set of
  180.              attributes is constructed by an entity.
  181.  
  182.         2.   The CertificationRequestInfo value is signed with
  183.              the entity's private key. (See Section 6.2.)
  184.  
  185.         3.   The CertificationRequestInfo value, a signature
  186.              algorithm identifier, and the entity's signature are
  187.              collected together into a CertificationRequest value,
  188.              defined below.
  189.  
  190.    A certification authority fulfills the request by verifying the
  191.    entity's signature, and, if it is valid, constructing a X.509
  192.    certificate from the distinguished name and public key, as well as an
  193.    issuer name, serial number, validity period, and signature algorithm
  194.    of the certification authority's choice. If the certification request
  195.    contains a PKCS #9 extended-certificate-attributes attribute, the
  196.    certification authority also constructs a PKCS #6 extended
  197.    certificate from the X.509 certificate and the extended-certificate-
  198.    attributes attribute value.
  199.  
  200.    In what form the certification authority returns the new certificate
  201.    is outside the scope of this document. One possibility is a PKCS #7
  202.    cryptographic message with content type signedData, following the
  203.    degenerate case where there are no signers. The return message may
  204.    include a certification path from the new certificate to the
  205.    certification authority. It may also include other certificates such
  206.    as cross-certificates that the certification authority considers
  207.    helpful, and it may include certificate-revocation lists (CRLs).
  208.    Another possibility is that the certification authority inserts the
  209.    new certificate into a central database.
  210.  
  211.    This section is divided into two parts. The first part describes the
  212.    certification-request-information type CertificationRequestInfo, and
  213.    the second part describes the top-level type CertificationRequest.
  214.  
  215.    Notes.
  216.  
  217.         1.   An entity would typically send a certification
  218.              request after generating a public-key/private-key pair, but
  219.              may also do so after a change in the entity's distinguished
  220.              name.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Kaliski                      Informational                      [Page 4]
  227.  
  228. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  229.  
  230.  
  231.         2.   The signature on the certification request
  232.              prevents an entity from requesting a certificate with
  233.              another party's public key. Such an attack would give the
  234.              entity the minor ability to pretend to be the originator of
  235.              any message signed by the other party. This attack is
  236.              significant only if the entity does not know the message
  237.              being signed, and the signed part of the message does not
  238.              identify the signer. The entity would still not be able to
  239.              decrypt messages intended for the other party, of course.
  240.  
  241.         3.   How the entity sends the certification request to
  242.              a certification authority is outside the scope of this
  243.              document. Both paper and electronic forms are possible.
  244.  
  245.         4.   This document is not compatible with the
  246.              certification request syntax for Privacy-Enhanced Mail, as
  247.              described in RFC 1424. The syntax in this document differs
  248.              in three respects: It allows a set of attributes; it does
  249.              not include issuer name, serial number, or validity period;
  250.              and it does not require an "innocuous" message to be
  251.              signed. The syntax in this document is designed to minimize
  252.              request size, an important constraint for those
  253.              certification authorities accepting requests on paper.
  254.  
  255. 6.1 CertificationRequestInfo
  256.  
  257.    Certification request information shall have ASN.1 type
  258.    CertificationRequestInfo:
  259.  
  260.    CertificationRequestInfo ::= SEQUENCE {
  261.      version Version,
  262.      subject Name,
  263.      subjectPublicKeyInfo SubjectPublicKeyInfo,
  264.      attributes [0] IMPLICIT Attributes }
  265.  
  266.    Version ::= INTEGER
  267.  
  268.    Attributes ::= SET OF Attribute
  269.  
  270.    The fields of type CertificationRequestInfo have the following
  271.    meanings:
  272.  
  273.         o    version is the version number, for compatibility
  274.              with future revisions of this document. It shall be 0 for
  275.              this version of the document.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Kaliski                      Informational                      [Page 5]
  283.  
  284. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  285.  
  286.  
  287.         o    subject is the distinguished name of the
  288.              certificate subject (the entity whose public key is to be
  289.              certified).
  290.  
  291.         o    subjectPublicKeyInfo contains information about
  292.              the public key being certified. The information identifies
  293.              the entity's public-key algorithm (and any associated
  294.              parameters); examples of public-key algorithms include
  295.              X.509's rsa and PKCS #1's rsaEncryption. The information
  296.              also includes a bit-string representation of the entity's
  297.              public key.  For both public-key algorithms just mentioned,
  298.              the bit string contains the BER encoding of a value of
  299.              X.509/PKCS #1 type RSAPublicKey.
  300.  
  301.         o    attributes is a set of attributes providing
  302.              additional information about the subject of the
  303.              certificate. Some attribute types that might be useful here
  304.              are defined in PKCS #9. An example is the challenge-
  305.              password attribute, which specifies a password by which the
  306.              entity may request that the certificate revocation. Another
  307.              example is the extended-certificate-attributes attribute,
  308.              which specifies attributes for a PKCS #6 extended
  309.              certificate.
  310.  
  311. 6.2 CertificationRequest
  312.  
  313.    A certification request shall have ASN.1 type CertificationRequest:
  314.  
  315.    CertificationRequest ::= SEQUENCE {
  316.      certificationRequestInfo CertificationRequestInfo,
  317.      signatureAlgorithm SignatureAlgorithmIdentifier,
  318.      signature Signature }
  319.  
  320.    SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
  321.  
  322.    Signature ::= BIT STRING
  323.  
  324.    The fields of type CertificationRequest have the following meanings:
  325.  
  326.         o    certificateRequestInfo is the "certification
  327.              request information." It is the value being
  328.              signed.
  329.  
  330.         o    signatureAlgorithm identifies the signature
  331.              algorithm (and any associated parameters) under
  332.              which the certification-request information is
  333.              signed. Examples include PKCS #1's
  334.              md2WithRSAEncryption and md5WithRSAEncryption.
  335.  
  336.  
  337.  
  338. Kaliski                      Informational                      [Page 6]
  339.  
  340. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  341.  
  342.  
  343.         o    signature is the result of signing the
  344.              certification request information with the
  345.              certification request subject's private key.
  346.  
  347.    The signature process consists of two steps:
  348.  
  349.         1.   The value of the certificationRequestInfo field is
  350.              DER encoded, yielding an octet string.
  351.  
  352.         2.   The result of step 1 is signed with the
  353.              certification request subject's private key under
  354.              the specified signature algorithm, yielding a bit
  355.              string, the signature.
  356.  
  357.    Note. The syntax for CertificationRequest could equivalently be
  358.    written with the X.509 SIGNED macro:
  359.  
  360.    CertificationRequest ::= SIGNED CertificateRequestInfo
  361.  
  362. Security Considerations
  363.  
  364.    Security issues are discussed throughout this memo.
  365.  
  366. Revision history
  367.  
  368.    Version 1.0
  369.  
  370.    Version 1.0 is the initial version.
  371.  
  372. Acknowledgements
  373.  
  374.    This document is based on a contribution of RSA Laboratories, a
  375.    division of RSA Data Security, Inc.  Any substantial use of the text
  376.    from this document must acknowledge RSA Data Security, Inc. RSA Data
  377.    Security, Inc.  requests that all material mentioning or referencing
  378.    this document identify this as "RSA Data Security, Inc. PKCS #10".
  379.  
  380. Author's Address
  381.  
  382.    Burt Kaliski
  383.    RSA Laboratories East
  384.    20 Crosby Drive
  385.    Bedford, MA  01730
  386.  
  387.    Phone: (617) 687-7000
  388.    EMail: burt@rsa.com
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Kaliski                      Informational                      [Page 7]
  395.  
  396. RFC 2314         PKCS #10: Certification Request Syntax       March 1998
  397.  
  398.  
  399. Full Copyright Statement
  400.  
  401.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  402.  
  403.    This document and translations of it may be copied and furnished to
  404.    others, and derivative works that comment on or otherwise explain it
  405.    or assist in its implementation may be prepared, copied, published
  406.    and distributed, in whole or in part, without restriction of any
  407.    kind, provided that the above copyright notice and this paragraph are
  408.    included on all such copies and derivative works.  However, this
  409.    document itself may not be modified in any way, such as by removing
  410.    the copyright notice or references to the Internet Society or other
  411.    Internet organizations, except as needed for the purpose of
  412.    developing Internet standards in which case the procedures for
  413.    copyrights defined in the Internet Standards process must be
  414.    followed, or as required to translate it into languages other than
  415.    English.
  416.  
  417.    The limited permissions granted above are perpetual and will not be
  418.    revoked by the Internet Society or its successors or assigns.
  419.  
  420.    This document and the information contained herein is provided on an
  421.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  422.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  423.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  424.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  425.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Kaliski                      Informational                      [Page 8]
  451.  
  452.