rfc2511.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/4 页

CertRequest ::= SEQUENCE {
    certReqId     INTEGER,          -- ID for matching request and reply
    certTemplate  CertTemplate,  -- Selected fields of cert to be issued
    controls      Controls OPTIONAL }   -- Attributes affecting issuance

CertTemplate ::= SEQUENCE {
    version      [0] Version               OPTIONAL,
    serialNumber [1] INTEGER               OPTIONAL,
    signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
    issuer       [3] Name                  OPTIONAL,
    validity     [4] OptionalValidity      OPTIONAL,
    subject      [5] Name                  OPTIONAL,
    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
    issuerUID    [7] UniqueIdentifier      OPTIONAL,
    subjectUID   [8] UniqueIdentifier      OPTIONAL,
    extensions   [9] Extensions            OPTIONAL }

  OptionalValidity ::= SEQUENCE {
      notBefore  [0] Time OPTIONAL,
      notAfter   [1] Time OPTIONAL } --at least one must be present

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

6. Controls Syntax

   The generator of a CertRequest may include one or more control values
   pertaining to the processing of the request.

   Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

   The following controls are defined (it is recognized that this list
   may expand over time):  regToken; authenticator; pkiPublicationInfo;
   pkiArchiveOptions; oldCertID; protocolEncrKey.







Myers, et. al.              Standards Track                     [Page 7]

RFC 2511                  Internet X.509 CRMF                 March 1999


6.1 Registration Token Control

   A regToken control contains one-time information (either based on a
   secret value or on knowledge) intended to be used by the CA to verify
   the identity of the subject prior to issuing a certificate.  Upon
   receipt of a certification request containing a value for regToken,
   the receiving CA verifies the information in order to confirm the
   identity claimed in the certification request.

   The value for regToken may be generated by the CA and provided out of
   band to the subscriber, or may otherwise be available to both the CA
   and the subscriber.  The security of any out-of-band exchange should
   be commensurate with the risk of the CA accepting an intercepted
   value from someone other than the intended subscriber.

   The regToken control would typically be used only for initialization
   of an end entity into the PKI, whereas the authenticator control (see
   Section 7.2) would typically be used for initial as well as
   subsequent certification requests.

   In some instances of use the value for regToken could be a text
   string or a numeric quantity such as a random number.  The value in
   the latter case could be encoded either as a binary quantity or as a
   text string representation of the binary quantity.  To ensure a
   uniform encoding of values regardless of the nature of the quantity,
   the encoding of regToken SHALL be UTF8.

6.2 Authenticator Control.

   An authenticator control contains information used in an ongoing
   basis to establish a non-cryptographic check of identity in
   communication with the CA.  Examples include:  mother's maiden name,
   last four digits of social security number, or other knowledge-based
   information shared with the subscriber's CA; a hash of such
   information; or other information produced for this purpose.  The
   value for an authenticator control may be generated by the subscriber
   or by the CA.

   In some instances of use the value for regToken could be a text
   string or a numeric quantity such as a random number.  The value in
   the latter case could be encoded either as a binary quantity or as a
   text string representation of the binary quantity.  To ensure a
   uniform encoding of values regardless of the nature of the quantity,
   the encoding of authenticator SHALL be UTF8.







Myers, et. al.              Standards Track                     [Page 8]

RFC 2511                  Internet X.509 CRMF                 March 1999


6.3 Publication Information Control

   The pkiPublicationInfo control enables subscribers to control the
   CA's publication of the certificate.  It is defined by the following
   syntax:

   PKIPublicationInfo ::= SEQUENCE {
        action     INTEGER {
                     dontPublish (0),
                     pleasePublish (1) },
        pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }


          -- pubInfos MUST NOT be present if action is "dontPublish"
          -- (if action is "pleasePublish" and pubInfos is omitted,
          -- "dontCare" is assumed)

   SinglePubInfo ::= SEQUENCE {
         pubMethod    INTEGER {
             dontCare    (0),
             x500        (1),
             web         (2),
             ldap        (3) },
         pubLocation  GeneralName OPTIONAL }

   If the dontPublish option is chosen, the requester indicates that the
   PKI should not publish the certificate (this may indicate that the
   requester intends to publish the certificate him/herself).

   If the dontCare method is chosen, or if the PKIPublicationInfo
   control is omitted from the request, the requester indicates that the
   PKI MAY publish the certificate using whatever means it chooses.

   If the requester wishes the certificate to appear in at least some
   locations but wishes to enable the CA to make the certificate
   available in other repositories, set two values of SinglePubInfo for
   pubInfos: one with x500, web or ldap value and one with dontCare.

   The pubLocation field, if supplied, indicates where the requester
   would like the certificate to be found (note that the CHOICE within
   GeneralName includes a URL and an IP address, for example).

6.4  Archive Options Control

   The pkiArchiveOptions control enables subscribers to supply
   information needed to establish an archive of the private key
   corresponding to the public key of the certification request.  It is
   defined by the following syntax:



Myers, et. al.              Standards Track                     [Page 9]

RFC 2511                  Internet X.509 CRMF                 March 1999


PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedKey,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key to be re-generated
      archiveRemGenPrivKey [2] BOOLEAN }
      -- set to TRUE if sender wishes receiver to archive the private
      -- key of a key pair which the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.

EncryptedKey ::= CHOICE {
      encryptedValue        EncryptedValue,
      envelopedData     [0] EnvelopedData }
      -- The encrypted private key MUST be placed in the envelopedData
      -- encryptedContentInfo encryptedContent OCTET STRING.

EncryptedValue ::= SEQUENCE {
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
      -- the intended algorithm for which the value will be used
      symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
      -- the symmetric algorithm used to encrypt the value
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- the (encrypted) symmetric key used to encrypt the value
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
      -- algorithm used to encrypt the symmetric key
      valueHint     [4] OCTET STRING         OPTIONAL,
      -- a brief description or identifier of the encValue content
      -- (may be meaningful only to the sending entity, and used only
      -- if EncryptedValue might be re-examined by the sending entity
      -- in the future)
        encValue       BIT STRING }

KeyGenParameters ::= OCTET STRING

   An alternative to sending the key is to send the information about
   how to re-generate the key using the KeyGenParameters choice (e.g.,
   for many RSA implementations one could send the first random numbers
   tested for primality). The actual syntax for this parameter may be
   defined in a subsequent version of this document or in another
   standard.











Myers, et. al.              Standards Track                    [Page 10]

RFC 2511                  Internet X.509 CRMF                 March 1999


6.5  OldCert ID Control

   If present, the OldCertID control specifies the certificate to be
   updated by the current certification request.  The syntax of its
   value is:

   CertId ::= SEQUENCE {
         issuer           GeneralName,
         serialNumber     INTEGER
     }

6.6  Protocol Encryption Key Control

   If present, the protocolEncrKey control specifies a key the CA is to
   use in encrypting a response to CertReqMessages.

   This control can be used when a CA has information to send to the
   subscriber that needs to be encrypted.  Such information includes a
   private key generated by the CA for use by the subscriber.

   The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo.

7.  Object Identifiers

   The OID id-pkix has the value

   id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
   dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

   -- arc for Internet X.509 PKI protocols and their components
   id-pkip  OBJECT IDENTIFIER :: { id-pkix pkip(5) }

   -- Registration Controls in CRMF
   id-regCtrl  OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
   id-regCtrl-regToken            OBJECT IDENTIFIER ::= { id-regCtrl 1 }
   id-regCtrl-authenticator       OBJECT IDENTIFIER ::= { id-regCtrl 2 }
   id-regCtrl-pkiPublicationInfo  OBJECT IDENTIFIER ::= { id-regCtrl 3 }
   id-regCtrl-pkiArchiveOptions   OBJECT IDENTIFIER ::= { id-regCtrl 4 }
   id-regCtrl-oldCertID           OBJECT IDENTIFIER ::= { id-regCtrl 5 }
   id-regCtrl-protocolEncrKey     OBJECT IDENTIFIER ::= { id-regCtrl 6 }

   -- Registration Info in CRMF
   id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
   id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
   --with syntax OCTET STRING
   id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
   --with syntax CertRequest




Myers, et. al.              Standards Track                    [Page 11]

RFC 2511                  Internet X.509 CRMF                 March 1999


8.  Security Considerations

   The security of CRMF delivery is reliant upon the security mechanisms
   of the protocol or process used to communicate with CAs.  Such
   protocol or process needs to ensure the integrity, data origin
   authenticity, and privacy of the message.  Encryption of a CRMF is
   strongly recommended if it contains subscriber-sensitive information
   and if the CA has an encryption certificate that is known to the end
   entity.

9. References

   [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
          Hashing for Message Authentication", RFC 2104, February 1997.

10. Acknowledgments

   The authors gratefully acknowledge the contributions of Barbara Fox,
   Warwick Ford, Russ Housley and John Pawling, whose review and
   comments significantly clarified and improved the utility of this
   specification.






























Myers, et. al.              Standards Track                    [Page 12]

RFC 2511                  Internet X.509 CRMF                 March 1999


11. Authors' Addresses

   Michael Myers
   VeriSign, Inc.
   1390 Shorebird Way
   Mountain View, CA  94019

   EMail: [e-mail]


   Carlisle Adams
   Entrust Technologies
   750 Heron Road, Suite E08
   Ottawa, Canada, K1V 1A7

   EMail: [e-mail]


   Dave Solo
   Citicorp
   666 Fifth Ave, 3rd Floor
   New York, Ny 10103

   EMail: [e-mail]