view Side-By-Side changes

PKIX Working Group                                    C. Adams (Entrust)
April 2003                                            D. Solo (Citicorp)                               Soaring Hawk Consulting 
December 2004                                             
expires in six months                                      D. Kemp (DoD)                                       
 
 
                Internet X.509 Public Key Infrastructure 
               Certificate Request Message Format (CRMF)
                  <draft-ietf-pkix-rfc2511bis-06.txt> 
                  <draft-ietf-pkix-rfc2511bis-07.txt> 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 2026. 
    
   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   or will be disclosed, and any of which I become aware will be 
   disclosed, in accordance with RFC 3668. 
 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   Copyright (C) The Internet Society (2003). (2004). All Rights Reserved. 
    
Abstract 
 
   This document describes the Certificate Request Message Format
   (CRMF). (CRMF) 
   syntax and semantics.  This syntax is used to convey a request for a 
   certificate to a Certification Authority (CA), possibly via a 
   Registration Authority (RA), for the purposes of X.509 certificate 
   production.  The request will typically include a public key and 
   associated registration information.











Myers, et. al.             Expires Oct. 2003                    [Page 1]


Internet Draft                                                 Apr. 2003  This document does not define a 
   certificate request protocol 
    
Table Of Contents 






 
1.  Introduction and Terminology .............................. 2 
2.  Overview............................................... 3 
 2.1  Changes since RFC 2511................................. 3 
3. CertReqMessage Syntax..................................... 4 
4. Proof of Possession (POP).................................. 5 
 4.1 Signature Key POP...................................... 7 
 4.2 Key Encipherment Keys................................... 9 
 4.3 Key Agreement Keys.....................................10 
 4.4  Use of Password-Based MAC...............................10 
5.  CertRequest syntax.......................................12 
6. Controls Syntax..........................................14 
 6.1 Registration Token Control...............................14 
 6.2 Authenticator Control...................................15 
 6.3 Publication Information Control...........................15 
 6.4  Archive Options Control ................................17 
 6.5  OldCert ID Control ....................................19 
 6.6  Protocol Encryption Key Control..........................19 
7.  RegInfo Controls........................................19 
 7.1  utf8Pairs............................................19 
 7.2  certReq .............................................20 
8.  Object Identifiers.......................................20 
9.  Security Considerations...................................21 
10. References.............................................22 
 10.1  Normative References..................................22 
 10.2 Informative References.................................23 
11. Acknowledgments.........................................23 
12. Authors' Addresses.......................................23 
Appendix A. Use of RegInfo for Name-Value Pairs ..................24 
 A.1. Defined Names ........................................24 
 A.2 IssuerName, SubjectName and Validity Value Encoding ..........25 
Appendix B. ASN.1 Structures and OIDs ..........................26 
Appendix C. Why do Proof of Possession (POP).....................31 
Appendix D - Change History...................................33 
 D.1 Changes from -06 to -07.................................33 
Appendix E - Full Copyright Statement ..........................33 
 
1.  Introduction and Terminology 
 
   This document describes the Certificate Request Message Format 
   (CRMF).  This syntax  A Certificate Request Message object is used within a 
   protocol to convey a request for a certificate to a Certification 
   Authority (CA), possibly via a Registration Authority (RA), for the 
   purposes of X.509 certificate production.  The request will typically 
   include a public key and associated registration information. 






    
   The certificate request object defined in this document is not a 
   standalone protocol.  The information defined in this document is 
   designed to be used by an externally define Certificate Request 
   Protocol (CRP).  The referencing protocol is expected to define what 
   algorithms are used, what registration information and control 
   structures are defined.  Many of the requirements in this document 
   refer to the referencing Certificate Request Protocol (CRP). 
    
   Certificate requests may be submitted by an RA requesting a 
   certificate on behalf of a Subject, by a CA requesting a cross-
   certificate from another CA, or directly by an End Entity (EE). 
    
   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 
   in this document (in uppercase, as shown) are to be interpreted as 
   described in RFC 2119. 2119 [RFC2119]. 
    
2.  Overview 
 
   Construction of a certification request involves the following steps: 
    
   a)  A CertRequest value object is constructed.  This value object may include the 
   public key, all or a portion of the end-entity's (EE's) Subject name, other requested 
   certificate fields, and additional control information related to the 
   registration process.


   b)  A proof of possession (of  Depending on the private key corresponding to CRP this information can be 
   specified by the
       public key for which a certificate Subject and potentially modified by an RA, or be 
   specified by the RA based on knowledge of the Subject or 
   documentation presented by the Subject.  
    
   b)  If required, a proof of possession (of the private key 
   corresponding to the public key for which a certificate is being 
   requested) value may
       be calculated across the CertRequest value. is calculated.  
    
   c)  Additional registration information may can be combined with the 
   proof of possession value and the CertRequest structure to form a 
   CertReqMessage.  Additional registration information can be added by 
   both the Subject and an RA. 
    
   d)  The CertReqMessage is securely communicated to a CA. Specific 
   means of secure transport are beyond to be specified by each CRP that refers 
   to this document. 
    
2.1  Changes since RFC 2511 
 
   1.  Addition of an introduction section. 
    
   2.  Addition of the concept of a CRP and language relating to CRPs. 
    






   3.  In section 6.2 changed regToken to authenticator. 
    
   4.  Add information describing the contents of the EncryptedValue 
   structure. 
    
   5.  Changed name and contents of OID {id-regInfo 1}. 
    
   6.  Added text detailing what goes into the fields of the different 
   structures defined in the document. 
    
   7.  Replaced appendix A with a reference to [RFC 2875].  The only 
   difference is that the scope old text specified to use subject alt name 
   instead of subject name if subject name was empty.  This is not 
   possible for a CA certificate issued using PKIX.  It would however be 
   useful to update RFC 2875 to have this
       specification.















Myers, et. al.             Expires Oct. 2003                    [Page 2]


Internet Draft                                                 Apr. 2003 fall back position. 
    
   7.  Insert Appendix C describing why POP is necessary and what some 
   of the different POP attacks are. 
    
   8.  pop field in the CertReqMsg structure has been renamed to popo to 
   avoid confusion between POP and pop. 
    
   9.  The use of the EncryptedValue structure has been deprecated. 
    
3. CertReqMessage Syntax 
 
   A certificate request message is composed of the certificate request, 
   an optional proof of possession field and an optional registration 
   information field. 
    
   CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg 
    
   CertReqMsg ::= SEQUENCE { 
      certReq   CertRequest,
      pop 
      popo       ProofOfPossession  OPTIONAL, 
      -- content depends upon key type 
      regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL  
   } 
    
   The proof fields of possession field CertReqMsg have the following meaning: 
    
      certReq contains the template of the certificate being requested.  
      The template is filled in by (or on behalf of) the Subject.  Not 
      all fields within the template need to be specified. Details on 
      this field are found in section 5. 
    
      popo contains the value used to demonstrate that the entity
   to that 
      will be associated with identified as the Subject of the certificate is actually 






      in possession of the corresponding private key.  This field may be calculated across
   the contents of the certReq field and varies 
      in structure and content
   by based on the public key algorithm type and operational mode.

   The the 
      mode (encryption vs. signature) in which the algorithm is used, as 
      specified in the KeyUsage field of the certificate to be issued.  
      Details on this field are found in section 4. 
    
      regInfo field SHOULD only contain only supplementary information
   related 
      relating to the context of the certification request when certificate request, where such 
      information is required to fulfill a certification the request.  This information MAY 
      might include subscriber contact information, billing information 
      or other ancillary information useful to fulfillment of the certification 
      request. 
    
   Information directly related to certificate content SHOULD be 
   included in the certReq content.  However, inclusion of additional 
   certReq content by RAs may can invalidate the pop field. popo field (depending on 
   the details of the POP method used).  Data therefore intended for 
   certificate content MAY be provided in regInfo.

   See Section 8 and Appendix B for example 
    
   It is the responsibility of a referencing CRP to define the details 
   of what can be specified in the regInfo contents.

















Myers, et. al.             Expires Oct. 2003                    [Page 3]


Internet Draft                                                 Apr. 2003 field.  This document 
   describes one method of encoding the information found in this field.  
   Details on this encoding are found in Appendix A. 
    
4. Proof of Possession (POP) 
 
   In order to prevent certain attacks (see Appendix C) and to allow a 
   CA/RA to properly check the validity of the binding between an end entity a subject 
   and a key pair, the PKI management operations structures specified here make it 
   possible for an end entity a subject to prove that it has possession of (i.e., is 
   able to use) the private key corresponding to the public key for 
   which a certificate is requested.  A given CA/RA CRP is free to choose how 
   to enforce POP (e.g., out-of-band procedural means versus the CRMF in-
   band 
   in-band message) in its certification exchanges exchanges.  Within a given CRP, 
   CAs and RAs are free to choose from among the POP methods provided 
   (i.e., this may be is a policy issue).  However, it is MANDATED that CAs/RAs issue local to an RA/CA).  A CRP SHOULD 
   define either which POP methods are required, or specify a mechanism 
   for clients to discover the POP methods supported. 
    
   Any CRP referencing this document MUST enforce POP by some means because there means. 
   There are currently many non-PKIX operational protocols in use 
   (various electronic mail protocols are one example) that do not 
   explicitly check the binding between the end entity and the private 
   key.  Until operational protocols that do verify the binding (for 
   signature, encryption, and key agreement key pairs) exist, and are 
   ubiquitous, this binding can only cannot be assumed to have been verified by 
   the CA/RA. Therefore, one cannot truly know if the binding is not verified
   by of the CA/RA, certificates 
   public key and the identity in the Internet Public-Key Infrastructure
   end up being somewhat less meaningful. certificate is actually correct. 
    






   POP is accomplished in different ways depending on the type of key 
   for which a certificate is requested. If a key can be used for 
   multiple purposes (e.g., an a signing and decryption RSA key) then any 
   of the methods MAY be used.  Protocol designers need to be aware that 
   there can be hardware limitations on what POP methods may be usable, 
   e.g., if the private key is maintained in a hardware token. 
    
   This specification allows for cases where POP is validated by the CA, 
   the RA, or both.  Some policies may require the CA to verify POP during certification, 
   certificate issuance, in which case the RA MUST forward the end 
   entity's CertRequest and ProofOfPossession fields unaltered to the
   CA, and as an option MAY also 
   CA.  (In this case the RA could verify POP. the POP and reject failing 
   certificate requests rather than forwarding them to the CA.)  If the 
   CA is not required by policy to verify POP, then the RA SHOULD 
   forward the end entity's request and proof unaltered to the CA as 
   above.  If this is not possible (for example because the RA verifies 
   POP by an out-of-band method), then the RA MAY uses the raVerified 
   element to attest to the CA that the required proof has been 
   validated. If the CA CA/RA uses an out-of-band method to verify POP 
   (such as physical delivery of CA-generated CA/RA-generated private keys), keys) then the 
   ProofOfPossession field is not used.

4.1 Signature Keys

   For omitted. 
    
   ProofOfPossession ::= CHOICE { 
       raVerified        [0] NULL, 
       signature keys, the end entity can sign a value to prove
   possession         [1] POPOSigningKey, 
       keyEncipherment   [2] POPOPrivKey, 
       keyAgreement      [3] POPOPrivKey } 
    
   The fields of ProofOfPossession have the private key.









Myers, et. al.             Expires Oct. 2003                    [Page 4]


Internet Draft                                                 Apr. 2003


4.2 Key Encipherment Keys

   For key encipherment keys, following meaning: 
    
      raVerified indicates that the end entity can provide RA has performed the private key
   to POP required on 
      the CA/RA, or can be certificate request.  This field is used by an RA when 1) the 
      CA is not required to decrypt a value in order do its own POP verification and 2) the RA 
      needs to prove
   possession change the contents of the private key. Decrypting certReq field.  CRPs MUST 
      provide a value can be achieved
   either directly or indirectly.

   The direct method is for the RA/CA to issue a random challenge RA to
   which sign the ProofOfPossession.  A 
      requestor MUST NOT set this field and an immediate response by RA/CA MUST NOT accept a 
      ProofOfPossession where the end entity requestor sets this field. 
       
      signature is required. used for performing POP with signature keys.  The indirect method 
      details of this field are covered in section 4.1. 
       
      keyEncipherment is to issue a certificate which used for performing POP with key encipherment 
      encryption based keys (i.e. RSA).  The details of this field are 
      covered in section 4.2. 
       
      keyAgreement is encrypted used for
   the end entity (and have the end entity demonstrate its ability to
   decrypt performing POP with key agreement type 
      encryption keys (i.e. DH).  The details of this certificate field are covered 
      in section 4.3. 
    






4.1 Signature Key POP 
 
   POP for a confirmation message). This allows a CA
   to issue signature key is accomplished by performing a certificate in signature 
   operation on a form which can only be used by the
   intended end entity.

4.3 Key Agreement Keys

   For key agreement keys, the end entity can use any piece of data containing the three
   methods given in Section 5.2 identity for encryption keys.  For which the direct 
   certificate is desired. 
    
   There are three cases that need to be looked at when doing a POP for 
   a signature key: 
    
   1.  The certificate subject has not yet established an authenticated 
   identity with a CA/RA but has a password and
   indirect methods, identity string from the end entity 
   CA/RA.  In this case the POPOSigningKeyInput structure would be 
   filled out using the publicKeyMAC choice for authInfo and the PKI management entity (i.e.,
   CA or RA) must establish a shared secret key in order 
   password and identity would be used to prove that
   the end entity has possession of compute the private publicKeyMAC 
   value.  The public key (i.e., in order to
   decrypt for the encrypted certificate or to construct the response to the
   issued challenge).  Note that this need not impose any restrictions
   on the keys that can being requested would be certified by a given CA -- 
   placed in particular, for
   Diffie-Hellman keys both the end entity may freely choose its algorithm
   parameters -- provided that POPOSigningKeyInput and the CA can generate a short-term (or
   one-time) key pair with Certificate Template 
   structures.  The signature field is computed over the appropriate parameters when necessary. DER encoded 
   POPOSigningKeyInput structure. 
    
   2.  The end entity may also MAC CA/RA has established an authenticated identity for the 
   certificate request (using a shared
   secret subject, but the requestor is not placing it into the 
   certificate request. [[[QUESTION: Can somebody explain why this would 
   occur?]]]  In this case the POPOSigningKeyInput structure would be 
   filled out using the sender choice for authInfo.  The public key derived from a Diffie-Hellman computation) as a fourth
   alternative for demonstrating POP.  This option may be used only if 
   the CA already has a DH certificate that is known to being requested would be placed in both the end entity 
   POPOSigningKeyInput and if the EE Certificate Template structures.  The 
   signature field is willing to use computed over the CA's DH parameters.

4.4 Proof of Possession Syntax

   ProofOfPossession ::= CHOICE {
       raVerified        [0] NULL,
       -- used if DER encoded POPOSigningKeyInput 
   structure. 
    
   3.  The certificate subject places its name in the RA has already verified that Certificate 
   Template structure along with the requester public key.  In this case the 
   poposkInput field is in
       -- possession of omitted from the private key POPOSigningKey structure.  The 
   signature         [1] POPOSigningKey,
       keyEncipherment   [2] POPOPrivKey,
       keyAgreement      [3] POPOPrivKey } field is computed over the DER encoded certificate template 
   structure. 
    
   POPOSigningKey ::= SEQUENCE { 
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,




Myers, et. al.             Expires Oct. 2003                    [Page 5]


Internet Draft                                                 Apr. 2003 
       algorithmIdentifier     AlgorithmIdentifier, 
       signature               BIT STRING }
       -- 
    
    
   The signature (using "algorithmIdentifier") is on the
       -- DER-encoded value fields of poposkInput.  NOTE: If POPOSigningKey have the CertReqMsg
       -- certReq CertTemplate following meaning: 
    
      poposkInput contains the subject and publicKey values,
       -- then poposkInput MUST data to be omitted and the signature signed, when present.  This 
      field MUST be
       -- computed on the DER-encoded value of CertReqMsg certReq.  If
       -- present when the CertReqMsg certReq CertTemplate certificate template does not 
      contain both the 
       -- public key value and a subject values (i.e., if it name value. 
       






      algorithmIdentifier identifiers the signature algorithm and an 
      associated parameters used to produce the POP value. 
       
      signature contains only one 
       -- the POP value produce.  If poposkInput is 
      present, the signature is computed using the DER encoded value of these, or neither), then 
      poposkInput.  If poposkInput MUST be present and
       -- MUST be signed. is absent, the signature is computed 
      using the DER encoded value of certReq. 
    
    
   POPOSigningKeyInput ::= SEQUENCE { 
       authInfo            CHOICE { 
           sender              [0] GeneralName, 
           -- used only if an authenticated identity has been 
           -- established for the sender (e.g., a DN from a 
           -- previously-issued and currently-valid certificate) 
           publicKeyMAC        PKMACValue }, 
           -- used if no authenticated GeneralName currently exists for 
           -- the sender; publicKeyMAC contains a password-based MAC 
           -- on the DER-encoded value of publicKey 
       publicKey           SubjectPublicKeyInfo }  -- from CertTemplate 
    
   The fields of POPOSigningKeyInput have the following meaning: 
    
      sender contains an authenticated identity that has previously been 
      established for the subject. 
       
      publicKeyMAC contains a computed value using a shared secret 
      between the CA/RA and the certificate requestor. 
       
      publicKey contains a copy of the public key from the certificate 
      template.  This MUST be exactly the same value as is contained in 
      the certificate template. 
    
   PKMACValue ::= SEQUENCE { 
      algId  AlgorithmIdentifier,
      -- 
      value  BIT STRING } 
    
   The fields of PKMACValue have the following meaning: 
    
      algId identifiers the algorithm used to compute the MAC value.  
      All implementations MUST support id-PasswordBasedMAC.  The details 
      on this algorithm are presented in section 4.4. 
       
      value shall be PasswordBasedMac
      --     {1 2 840 113533 7 66 13}
      -- contains the parameter computed MAC value.  The MAC value is PBMParameter
      value  BIT STRING } computed 
      over the DER encoded public key of the certificate subject. 
       
   The CA/RA identifies the shared secret to be used by looking at 1) 
   the general name field in the certificate request or 2) either the 
   regToken (see section 6.1) or authToken (see section 6.2) controls. 
    






    
4.2 Key Encipherment Keys 
 
[[[QUESTION:  Can anyone to tell me how the identity of the requesting 
entity is bound into the POP proof here?]]] 
 
   POP for key encipherment keys is accomplished by one of three 
   different methods.  The private key can be provided to the CA/RA, an 
   encrypted challenge from the CA/RA can be decrypted (direct method) 
   or the created certificate can be returned encrypted and used as the 
   challenge response (indirect method). 
    
   POPOPrivKey ::= CHOICE { 
       thisMessage       [0] BIT STRING,
       -- posession is proven in this message (which contains the private
       -- key itself (encrypted for the CA)) 
       subsequentMessage [1] SubsequentMessage,
       -- possession will be proven in a subsequent message 
       dhMAC             [2] BIT STRING } 
       -- for keyAgreement (only), possession is proven in this message 
       -- (which contains a MAC (over the DER-encoded value of the 
       -- certReq parameter in CertReqMsg, which must include both 
   subject 
       -- and publicKey) based on a key derived from the end entity's 
       -- private DH key and the CA's public DH key); 
       -- the dhMAC value MUST be calculated as per the directions given 
       -- in Appendix A. RFC 2875 for static DH proof of possesion. 
    
   SubsequentMessage ::= INTEGER {




Myers, et. al.             Expires Oct. 2003                    [Page 6]


Internet Draft                                                 Apr. 2003 
       encrCert (0),
       -- requests that resulting certificate be encrypted for the
       -- end entity (following which, POP will be proven in a
       -- confirmation message) 
       challengeResp (1) }
       -- requests that CA/RA engage in challenge-response exchange with
       -- end entity in order to prove 
    
   The fields of POPOPrivKey have the following meaning: 
    
      thisMessage contains the encrypted private key possession

   It is expected that protocols for which incorporate this specification
   will include the confirmation and challenge-response messages
   necessary to a complete protocol.

4.4.1  Use of Password-Based MAC

   The following algorithm SHALL be used when publicKeyMAC 
      certificate is used in
   POPOSigningKeyInput to prove the authenticity of a request.

   PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 recommended)
         iterationCount      INTEGER,
         -- number be issued.  The possession of times the OWF private key is applied
         mac                 AlgorithmIdentifier
         -- 
      proved by providing it to the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
   }     -- or HMAC [RFC2104, RFC2202]) CA/RA. [[[ BLOCKING ISSUE:  The process 
      contents of using PBMParameter to compute publicKeyMAC and this structure is not currently defined so
   authenticate it cannot 
      be correctly filled out!!!! ]]]] 
       
      subsequentMessage is used to indicate that the origin of POP will be 
      completed by decrypting a public key certification request
   consists of two stages. The first stage uses shared secret
   information to produce message from the CA/RA and a MAC key. response 
      returned.  The second stage MACs the public
   key in question using this MAC key to produce an authenticated value.

   Initialization type of message to be decrypted is indicated by the first stage of algorithm assumes 
      value used. 
       
         encrCert indicates that the existence
   of a shared secret distributed certificate issued is to be 
         returned in a trusted fashion between CA/RA and
   end-entity. an encrypted form.  The salt value requestor is appended required to 
         decrypt the shared secret certificate and prove success to the
   one way function (owf) is applied iterationCount times, where CA/RA.  The 
         details of this are provided by the
   salted secret CRP. 
          
         challengeResponse indicates that a challenge message is to be 
         send from the input CA/RA to the first iteration and, for each
   successive iteration, requestor.  The details of the input is set 






         challenge message and the response are details to be provided 
         by the output of the
   previous iteration, yielding a CRP. 
       
      dhMAC is used for key K.

   In agreement keys.  It contains a computed MAC 
      that is obtained by using the second stage, K requestor's private key and the 
      CA/RA public key key.  Details are inputs to HMAC as
   documented covered in [HMAC] to produce a value for publicKeyMAC as follows:

   publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )

   where ipad section 4.3. 
    
   It is expected that protocols that incorporate this specification 
   will include the confirmation and opad are defined in [RFC2104].





Myers, et. al.             Expires Oct. 2003                    [Page 7]


Internet Draft                                                 Apr. 2003


   The AlgorithmIdentifier challenge-response messages 
   necessary for owf SHALL be SHA-1 {1 3 14 3 2 26} and a complete protocol. 
    
4.3 Key Agreement Keys 
 
   POP for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.

5.  CertRequest syntax key agreement keys is accomplished by one of four different 
   methods.  The CertRequest syntax consists first three are identical to those presented above for 
   key encryption keys.  The fourth method takes advantage of the fact 
   that a request identifier, a template
   of certificate content, shared secret is produced and an optional sequence of control that value can be used to MAC 
   information.

   CertRequest ::= SEQUENCE {
      certReqId     INTEGER,        -- ID 
    
   When the direct or indirect encryption methods presented above are 
   used, the CA/RA will need to create an ephemeral key for matching those cases 
   where the encryption algorithm parameters do not match between the 
   CA/RA and the requestor. 
    
   The end entity may also MAC the certificate request (using a shared 
   secret key derived from a Diffie-Hellman computation) as a fourth 
   alternative for demonstrating POP.  This option may be used only if 
   the CA/RA already has a DH certificate that is known to the end 
   entity and reply
      certTemplate  CertTemplate, --Selected fields of cert if the Subject is able to use the CA/RA's DH parameters.  
   Details on this may 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, found in [RFC 2875].  All implementations MUST 
   support the static DH Proof-of-Possession (section 3).  NOTE: If 
   either the 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 issuer name in the processing of CA certificate is empty, 
   then the request.

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

   The following controls are defined (it alternative name should be used in its place. 
    
   [[[ISSUE:  This is recognized that this list
   may expand over time):  regToken; authenticator; pkiPublicationInfo;
   pkiArchiveOptions; oldCertID; protocolEncrKey.








Myers, et. al.             Expires Oct. 2003                    [Page 8]


Internet Draft                                                 Apr. 2003


6.1 Registration Token Control

   A regToken control contains one-time information (either based on a
   secret value or on knowledge) intended only defined for DH key agreement pairs.  There 
   needs to be used by the CA a way to verify
   the identity of the subject prior extend this to issuing a certificate.  Upon
   receipt other algorithms.]]] 
    
    
4.4  Use of Password-Based MAC 
 
   This MAC algorithm was designed to take a certification request containing shared secret (a password) 
   and use it to compute a check value for regToken,
   the receiving CA verifies the information in order to confirm over a piece of information.  The 
   assumption being that without the
   identity claimed in password the certification request.

   The correct check value for regToken may 
   cannot be generated by the CA and provided out of
   band to computed.  The algorithm computes the subscriber, or may otherwise be available one way function 
   multiple times in order to both the CA
   and slow down any dictionary attacks against 
   the subscriber. password value. 
    






   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 algorithm identifier and parameter structure used for initial as well as
   subsequent certification requests.

   In some instances Password-
   Based MAC is: 
    
      id-PasswordBasedMAC OBJECT IDENTIFIER ::=  
                                         { 1 2 840 113533 7 66 13} 
    
      PBMParameter ::= SEQUENCE { 
         salt                OCTET STRING, 
         owf                 AlgorithmIdentifier, 
         iterationCount      INTEGER, 
         mac                 AlgorithmIdentifier 
         ) 
    
   The fields of use PEMParameter have the value for regToken could be a text
   string or a numeric quantity such as following meaning: 
    
      salt contains a random number.  The randomly generated value used in computing 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 key 
      of the nature of MAC process. [[[QUESTION What should the quantity, length be?]]]  
       
      owf identifies the encoding of regToken SHALL be UTF8.

6.2 Authenticator Control.

   An authenticator control contains information algorithm and associated parameters used in an ongoing
   basis to establish a non-cryptographic check of identity 
      compute the key used in
   communication with the CA.  Examples include:  mother's maiden name,
   last four digits MAC process.  All implementations MUST 
      support SHA-1. 
       
      iterationCount identifiers the number of social security number, or other knowledge-based
   information shared with times 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 is applied 
      during the subscriber
   or by key computation process. [[[QUESTION: What should the CA.

   In some instances 
      recommended number of use iterations be?]]] 
       
      mac identifies the value for authenticator could algorithm and associated parameters of the MAC 
      function to be a text
   string or a numeric quantity such as a random number. used.  All implementations MUST support HMAC-SHA1 
      [HMAC]. All implementations SHOULD support DES-MAC and Triple-DES-
      MAC [PKCS11]. 
    
   The value in following is pseudo code for the latter case could be encoded either as a binary quantity or as a
   text algorithm: 
    
   Inputs: 
          pw an octet string representation of containing the binary quantity.  To ensure a
   uniform encoding of values regardless of user's password 
          data an octet string containing the nature of value to be MAC-ed 
          iteration count Iter 
    
   Output: 
          MAC an octet string containing the quantity, resultant MAC value. 
    
   1.  Generate a random salt value S 
    
   2.  Append the encoding of authenticator SHALL be UTF8.








Myers, et. al.             Expires Oct. 2003                    [Page 9]


Internet Draft                                                 Apr. 2003


6.3 Publication Information Control

   The pkiPublicationInfo control enables subscribers salt to control the
   CA's publication of pw.  K = pw || salt. 
    
   3.  Hash the certificate.  It value of K.   K = HASH(K) 
    
   4.  If Iter is greater than zero.  Iter = Iter - 1. Goto step 3. 
    






   5.  Compute an HMAC as documented in [HMAC]. 
    
       MAC = HASH( K XOR opad, HASH( K XOR ipad, data) ) 
    
       Where opad and ipad are defined by the following
   syntax:

   PKIPublicationInfo in [HMAC]. 
    
    
5.  CertRequest syntax 
 
   The CertRequest syntax consists of a request identifier, a template 
   of certificate content, and an optional sequence of control 
   information. 
    
   CertRequest ::= SEQUENCE {
        action     INTEGER {
                     dontPublish (0),
                     pleasePublish (1) },
        pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }


          -- pubInfos MUST NOT be present if action is "dontPublish" 
      certReqId     INTEGER,        -- (if action is "pleasePublish" ID for matching request and pubInfos is omitted, reply 
      certTemplate  CertTemplate, --Selected fields of cert to be issued 
      controls      Controls OPTIONAL } -- "dontCare" is assumed)

   SinglePubInfo Attributes affecting issuance 
    
   CertTemplate ::= SEQUENCE {
         pubMethod    INTEGER {
             dontCare    (0),
             x500        (1),
             web         (2),
             ldap        (3) },
         pubLocation  GeneralName 
      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 }

   If the dontPublish option is chosen, 
    
   OptionalValidity ::= SEQUENCE { 
      notBefore  [0] Time OPTIONAL, 
      notAfter   [1] Time OPTIONAL } --at least one must be present 
    
   Time ::= CHOICE { 
      utcTime        UTCTime, 
      generalTime    GeneralizedTime } 
    
   The fields of CertRequest have the requester indicates following meaning: 
    
      certReqId contains an integer value that the
   PKI should not publish is used by the 
      certificate (this may indicate that the
   requester intends requestor to publish the associate a specific certificate him/herself).

   If request 
      with a certificate response. 
       
      certTemplate contains a template of an X.509 certificate.  The 
      requestor fills in those fields for which specific values are 
      desired.  Details on the dontCare method is chosen, or if fields are given below. 
       






      controls contains attributes that are not part of the PKIPublicationInfo certificate, 
      but control is omitted from the request, context in which the requester indicates that certificate is to be issued.  
      Details on the
   PKI MAY publish controls defined in this document can be found in 
      section 6.  Other documents may define other controls.  CRPs are 
      responsible for specifying which controls are required. 
     
   The fields of CertTemplate have the certificate using whatever means it chooses.

   If following meaning: 
    
      version MUST be 2 if supplied.  It SHOULD be omitted. 
       
      serialNumber MUST be omitted.  This field is assigned by the requester wishes CA 
      during certificate creation. 
       
      signingAlg MUST be omitted.  This field is assigned by the CA 
      during certificate to appear creation. 
       
      issuer is normally omitted.  It would be filled in at least some
   locations but wishes to enable with the CA 
      that the requestor desires to make issue the certificate
   available in other repositories, set two values of SinglePubInfo for
   pubInfos: situations 
      where an RA is servicing more than one with x500, web CA. 
       
      validity is normally omitted.  It can be used to request that 
      certificates either start at some point in the future or ldap value and one with dontCare.

   The pubLocation field, if supplied, indicates expire at 
      some specific time.  A case where the requester this field would like commonly be 
      used is when a cross certificate is issued for a CA.  In this case 
      the validity of an existing certificate to would be found (note placed in this 
      field so that the CHOICE within
   GeneralName includes a URL and an IP address, for example).

6.4  Archive Options Control new certificate would have the same validity 
      period as the existing certificate.  If validity is not omitted 
      then at least one of the sub-fields MUST be specified.  The pkiArchiveOptions control enables subscribers to supply
   information needed to establish an archive sub-
      fields are as follows: 
          
         notBefore contains the requested start time of the private key
   corresponding to certificate.  
         The time follows the public key same rules as the notBefore time in 
         [PROFILE]. 
          
         notAfter contains the requested expiration time of the certification request.  It 
         certificate.  The time follows the same rules as the notAfter 
         time in [PROFILE]. 
       
      subject is
   defined filled in with the suggested name for the requestor.  
      This would normally be filled in by a name that has previously 
      been issued to the following syntax:




Myers, et. al.             Expires Oct. 2003                   [Page 10]


Internet Draft                                                 Apr. 2003

   PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedKey,
      -- requestor by the actual value of CA. 
       
      publicKey contains the private public key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters for which allow the private key to certificate is 
      being created.  This field MUST be re-generated
      archiveRemGenPrivKey [2] BOOLEAN }
      -- set to TRUE filled in if the requestor 
      generates its own key.  The field is omitted if sender wishes receiver to archive the private
      -- key of a key pair which is 
      generated by 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 RA/CA. 
       
      issuerUID MUST be placed omitted.  This field has been deprecated in the envelopedData
      -- encryptedContentInfo encryptedContent OCTET STRING.

   EncryptedValue ::= SEQUENCE {
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
      -- the intended algorithm for which the value will 
      [PROFILE]. 
       
      subjectUID MUST be used
      symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
      -- omitted.  This field has been deprecated in 
      [PROFILE]. 
       






      extensions contains extensions that the symmetric algorithm used requestor wants to encrypt have 
      placed in the value
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- certificate.  These extensions would generally deal 
      with things such as setting the (encrypted) symmetric key used to encrypt the value
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
      -- algorithm used usage to encrypt keyEncipherment. 
    
   With the symmetric key
      valueHint     [4] OCTET STRING         OPTIONAL,
      -- a brief description or identifier exception of the encValue content
      -- (may be meaningful only to publicKey field, the sending entity, and used only
      -- if EncryptedValue might CA/RA is permitted to 
   alter any requested field.  The returned certificate needs to be re-examined 
   checked by the sending entity
      -- in the future)
      encValue       BIT STRING }
   -- When EncryptedValue is used to carry a private key (as opposed requestor to
   -- a certificate), implementations MUST support see if the encValue field
   -- containing an encrypted PrivateKeyInfo as defined fields have been set in [PKCS11],
   -- section 12.11. If encValue contains some other format/encoding 
   -- for the private key, an 
   acceptable manner. CA/RA SHOULD use the first octet template fields if possible. 
    
   There are cases where all fields of valueHint MAY be used 
   -- to indicate the format/encoding (but note that template can be omitted.  If 
   the possible values 
   -- of this octet are not specified key generation is being done at this time).  In all cases, the 
   -- intendedAlg field MUST be used to indicate at least the OID of 
   -- the intended algorithm of CA/RA and the private key, unless this information 
   -- identity proof 
   is known placed in a priori to both sender and receiver by some other means.

   KeyGenParameters ::= OCTET STRING

   An alternative to sending different location (such as the key is id-regCtrl-regToken 
   below), then there are no fields that needs to send be specified by the information about
   how 
   certificate requestor. 
    
6. Controls Syntax 
 
   The generator of a CertRequest may include one or more control values 
   pertaining to re-generate the key using the KeyGenParameters choice (e.g.,
   for many RSA implementations one could send processing of the first random numbers
   tested for primality). request. 
    
   Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 
    
   The actual syntax for following controls are defined by this parameter document:  regToken; 
   authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; 
   protocolEncrKey.  Each CRP MUST define the set of controls supported 
   by that protocol.  Additional controls may be defined in a subsequent version of this document by additional 
   RFCs or in another
   standard.



Myers, et. al.             Expires Oct. 2003                   [Page 11]


Internet Draft                                                 Apr. 2003


6.5  OldCert ID Control

   If present, by the OldCertID CRP protocol itself.  
    
6.1 Registration Token Control 
 
   A regToken control specifies the certificate contains one-time information (either based on a 
   secret value or on knowledge) intended to be
   updated used 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, CA to verify 
   the protocolEncrKey control specifies a key identity of the CA is subject prior to
   use in encrypting issuing a response to CertReqMessages.

   This control can be used when certificate.  Upon 
   receipt of a certification request containing a value for regToken, 
   the receiving CA has verifies the information in order to send to confirm the
   subscriber that needs to 
   identity claimed in the certification request. 
    
   The value for regToken may be encrypted.  Such information includes a
   private key generated by the CA for use by and provided out of 
   band to the subscriber, or may otherwise be available to both the CA 
   and the subscriber.  The encoding security of protocolEncrKey SHALL any out-of-band exchange should 
   be SubjectPublicKeyInfo.

7.  Object Identifiers commensurate with the risk that the CA will tolerate with regard 
   to accepting an intercepted value from someone other than the 
   intended subscriber. 
    
   The OID id-pkix has 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

   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 regToken could be a text 
   string or a numeric quantity such as a random number.  The value in CRMF
   id-regCtrl  OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) } 
   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. 
    
   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-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
   --with syntax UTF8STRING
   id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
   --with syntax CertRequest





Myers, et. al.             Expires Oct. 2003                   [Page 12]


Internet Draft                                                 Apr. 2003


8.  Security Considerations

   The security of CRMF delivery  
    
   [[[QUESTION:: If binary value, what happens if this is reliant upon not a valid 
   UTF8 string? Good question!   Also an issue if the security mechanisms binary value has a 
   zero octet in the middle of it.  Most encoders would stop at the protocol or process used zero 
   octet and not get the full value.]]] 
    
   [[[QUESTION:  Is this considered to communicate with CAs.  Such
   protocol or process needs be interoperable?  I cannot 
   create a client that knows how to ensure compute the integrity, data origin
   authenticity, and privacy value of the message.  Encryption this field.  
   Should it be obsoleted in favor of a CRMF is
   strongly recommended if it couple of different fields?]]] 
    
6.2 Authenticator Control. 
 
   An authenticator control contains subscriber-sensitive information
   and if the CA has used in an encryption certificate that is known ongoing 
   basis to establish a non-cryptographic check of identity in 
   communication with the end
   entity.

9. Normative References

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

   [PKCS11] RSA Laboratories, The Public-Key Cryptography Standards -
          "PKCS #11 v2.11:  Cryptographic Token Interface Standard", RSA 
          Security Inc., June 2001.


10. Acknowledgments

   The authors gratefully acknowledge the contributions CA.  Examples include:  mother's maiden name, 
   last four digits of Barbara Fox,
   Warwick Ford, Russ Housley and John Pawling, whose review and
   comments significantly clarified and improved social security number, or other knowledge-based 
   information shared with the utility subscriber's CA; a hash of such 
   information; or other information produced for this
   specification. purpose.  The members of the ca-talk mailing list also 
   provided significant input with respect to interoperability testing.

























Myers, et. al.             Expires Oct. 2003                   [Page 13]


Internet Draft                                                 Apr. 2003


11. Authors' Addresses

   Michael Myers
   TraceRoute Security, Inc.

   EMail: myers@coastside.net


   Carlisle Adams
   Entrust, Inc.
   1000 Innovation Drive,
   Ottawa, Canada, K2K 3E7

   EMail: cadams@entrust.com


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

   EMail: david.solo@citicorp.com


   David Kemp
   National Security Agency
   Suite 6734
   9800 Savage Road
   Fort Meade, MD 20755

   EMail: dpkemp@missi.ncsc.mil





















Myers, et. al.             Expires Oct. 2003                   [Page 14]


Internet Draft                                                 Apr. 2003


Appendix A. Constructing "dhMAC"

   This Appendix describes the method 
   value for computing an authenticator control may be generated by the bit string
   "dhMAC" in subscriber 
   or by the proof-of-possession POPOPrivKey structure CA. 
    
   In some instances of use the value for Diffie-
   Hellman certificate requests.

   1. The entity generates authenticator could be a DH public/private key-pair. text 
   string or a numeric quantity such as a random number.  The DH parameters used to calculate the public SHOULD be those
       specified value in 
   the CA's DH certificate.

       From CA's DH certificate:
          CApub = g^x mod p   (where g and p are the established DH
                               parameters and x is latter case could be encoded either as a binary quantity or as a 
   text string representation of the CA's private
                               DH component)
       For entity E:
          DH private value = y
          Epub = DH public value = g^y mod p

   2. The MACing process will then consist binary quantity.  To ensure a 
   uniform encoding of values regardless of the following steps.

   a) The value nature of the certReq field is DER encoded, yielding a binary
      string. This will quantity, 
   the encoding of authenticator SHALL be UTF8. 
    
   id-regCtrl-authenticator       OBJECT IDENTIFIER ::= { id-regCtrl 2 } 
    
   [[[See comments on section 6.1]]] 
    
   [[[Text needs better description of the 'text' referred to in [HMAC], difference between the data 
   Authenticator Control and the regToken.]]] 
    
6.3 Publication Information Control 
 
   The pkiPublicationInfo control enables subscribers to
      which HMAC-SHA1 is applied.

   b) A shared DH secret is computed, as follows,
                      shared secret = Kec = g^xy mod p

      [This is done by influence the entity E as CApub^y and by 
   CA/RA's publication of the CA as Epub^x,
      where CApub certificate.  This control is retrieved from the CA's DH certificate considered 






   to be advisory and Epub is
      retrieved from the actual certification request.]

   c)  A key K can be ignored by CAs/RAs.  It is derived from defined by the shared secret Kec and the subject 
   following OID and
      issuer names in the CA's certificate as follows:

      K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)

      where "|" means concatenation.  If subjectName in the CA
      certificate is an empty syntax: 
    
   id-regCtrl-pkiPublicationInfo  OBJECT IDENTIFIER ::= { id-regCtrl 3 } 
    
   PKIPublicationInfo ::= SEQUENCE then DER-encoded-subjectAltName
      should be used instead; similarly, if issuerName is an empty { 
        action     INTEGER { 
                     dontPublish (0), 
                     pleasePublish (1) }, 
        pubInfos  SEQUENCE then DER-encoded-issuerAltName should be used instead.

   d) Compute HMAC-SHA1 over SIZE (1..MAX) OF SinglePubInfo OPTIONAL } 
    
    
   SinglePubInfo ::= SEQUENCE { 
         pubMethod    INTEGER { 
             dontCare    (0), 
             x500        (1), 
             web         (2), 
             ldap        (3) }, 
         pubLocation  GeneralName OPTIONAL } 
    
   The fields of PKIPublicationInfo have the data 'text' as per [RFC2104] as:
         SHA1(K XOR opad, SHA1(K XOR ipad, text))








Myers, et. al.             Expires Oct. 2003                   [Page 15]


Internet Draft                                                 Apr. 2003

      where,
         opad (outer pad) = following meaning: 
    
      action indicates whether or not the byte 0x36 repeated 64 times requestor wishes the CA/RA to 
      publish the certificate.  The values and
         ipad (inner pad) = their means are: 
    
         dontPublish indicates that the byte 0x5C repeated 64 times.


      Namely,

         (1) Append zeros requester wishes the CA/RA not 
         to publish the end of K certificate (this may indicate that the 
         requester intends to create a 64 byte string
             (e.g., if K publish the certificate him/herself).  If 
         dontPublish is of length 16 bytes it will used, the pubInfos field MUST be appended with
             48 zero bytes 0x00).
         (2) XOR (bitwise exclusive-OR) omitted. 
          
         pleasePublish indicates that the 64 byte string computed in
             step (1) with ipad.
         (3) Append requestor wishes the data stream 'text' CA/RA to 
         publish the 64 byte string
             resulting from step (2).
         (4) Apply SHA1 to certificate. 
          
      pubInfos holds the stream generated in step (3).
         (5) XOR (bitwise exclusive-OR) locations where the 64 byte string computed in
             step (1) with opad.
         (6) Append requestor desires the SHA1 result from step (4) CA/RA 
      to publish the 64 byte string
             resulting from step (5).
         (7) Apply SHA1 certificate.  This field is omitted if the 
      dontPublish choice is selected.  If the requestor wants to specify 
      some locations for the stream generated in step (6) certificate to be published, and output to allow 
      the result.

          Sample code is also provided CA/RA to publish in other locations would specify multiple 
      values of the SinglePubInfo structure, one of which would be 
      dontCare. 
          
   The fields of SinglePubInfo have the following meaning: 
    
      pubMethod indicates the address type for the location at which the 
      requestor desires the certificate to be placed by the CA/RA. 
       
         dontCare indicates that the CA/RA can publish the certificate 
         in whatever locations it choses.  If dontCare is used, the 
         pubInfos field MUST be omitted. 
          






         x500 indicates that the requestor wishes for the CA/RA to 
         publish the certificate in [RFC2104, RFC2202].

   e) The output of (d) is encoded as a BIT STRING (the value "dhMAC").

   3. specific location.  The proof-of-possession process requires location 
         is indicated in the CA x500 field of pubLocation. 
          
         ldap indicates that the requestor wishes for the CA/RA to carry out
      steps (a) through (d) and then simply compare 
         publish the result certificate in a specific location.  The location 
         is indicated in the ldap field of step
      (d) with what it received as pubLocation. 
          
         web indicates that the "dhMAC" value. If they match then requestor wishes for the following CA/RA to 
         publish the certificate in a specific location.  The location 
         is indicated in the http field of pubLocation. 
          
      pubLocation contains the address at which the certificate is to be 
      placed.  The choice in the general name field is dictated by the 
      pubMethod selection in this structure. 
       
    
   Publication locations can be concluded.

       1) supplied in any order.  All locations 
   are to be processed by the CA for purposes of publication. 
    
    
6.4  Archive Options Control 
 
   The Entity possesses pkiArchiveOptions control enables subscribers to supply 
   information needed to establish an archive of the private key 
   corresponding to the public key in of the certification request (because it needed the
          private key to calculate request.  It is 
   defined by the shared secret).

       2) Only following OID and syntax: 
    
   id-regCtrl-pkiArchiveOptions   OBJECT IDENTIFIER ::= { id-regCtrl 4 } 
    
   PKIArchiveOptions ::= CHOICE { 
      encryptedPrivKey     [0] EncryptedKey, 
      -- the intended CA can actually verify actual value of the request (because private key 
      keyGenParameters     [1] KeyGenParameters, 
      -- parameters which allow the CA requires its own private key to compute the same shared
          secret).  This helps be re-generated 
      archiveRemGenPrivKey [2] BOOLEAN } 
      -- set to protect from rogue CAs.

References

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

   [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
             SHA-1", RFC 2202, September 1997.

Acknowledgements

   The details of this Appendix were provided by Hemma Prafullchandra.

Myers, et. al.             Expires Oct. 2003                   [Page 16]


Internet Draft                                                 Apr. 2003



Appendix B. Use of RegInfo for Name-Value Pairs

   The "value" field of the id-regInfo-utf8Pairs string (with "tag"
   field equal TRUE if sender wishes receiver to 12 and appropriate "length" field) will contain a
   series of UTF8 name/value pairs.

   This Appendix lists some common examples of such pairs for archive the
   purpose of promoting interoperability among independent
   implementations private 
      -- key of this specification.  It is recognized a key pair that the receiver generates in response to 
      -- this
   list is not exhaustive and will grow with time and implementation
   experience.

B.1. Example Name/Value Pairs

   When regInfo is used request; set to convey one or more name-value pairs (via id-
   regInfo-utf8Pairs), the first and subsequent pairs SHALL be
   structured as follows:

      [name?value][%name?value]*%

   This string FALSE if no archival is then encoded into a UTF8STRING and desired. 
    
   EncryptedKey ::= CHOICE { 
      encryptedValue        EncryptedValue, 
      envelopedData     [0] EnvelopedData } 
      -- The encrypted private key MUST be placed into in the
   regInfo SEQUENCE.

   Reserved characters are encoded using envelopedData 
      -- encryptedContentInfo encryptedContent OCTET STRING. 
    
   EncryptedValue ::= SEQUENCE { 
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL, 
      -- the %xx mechanism of [RFC1738],
   unless they are used intended algorithm for their reserved purposes.

   The following table defines a recommended set of named elements.
   The value in the column "Name Value" is which the exact text string that value will appear in the regInfo.

      Name Value
      ----------
      version be used 






      symmAlg       [1] AlgorithmIdentifier  OPTIONAL, 
      -- version of this variation of regInfo use
      corp_company the symmetric algorithm used to encrypt the value 
      encSymmKey    [2] BIT STRING           OPTIONAL, 
      -- company affiliation 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 subscriber
      org_unit the encValue content 
      -- organizational unit
      mail_firstName (may be meaningful only to the sending entity, and used only 
      -- personal name component
      mail_middleName if EncryptedValue might be re-examined by the sending entity 
      -- personal name component
      mail_lastName in the future) 
      encValue       BIT STRING } 
   -- personal name component
      mail_email When EncryptedValue is used to carry a private key (as opposed to 
   -- subscriber's email address
      jobTitle a certificate), implementations MUST support the encValue field 
   -- job title of subscriber
      employeeID containing an encrypted PrivateKeyInfo as defined in [PKCS11], 
   -- employee identification number or string
      mailStop section 12.11. If encValue contains some other format/encoding  
   -- mail stop
      issuerName for the private key, the first octet of valueHint MAY be used  
   -- to indicate the format/encoding (but note that the possible values  
   -- name of CA
      subjectName this octet are not specified at this time).  In all cases, the  
   -- name intendedAlg field MUST be used to indicate at least the OID of Subject
      validity  
   -- validity interval






Myers, et. al.             Expires Oct. 2003                   [Page 17]


Internet Draft                                                 Apr. 2003



   For example:

      version?1%corp_company?Acme, Inc.%org_unit?Engineering%
      mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
      mail_email?john@acme.com%

B.1.1. IssuerName, SubjectName and Validity Value Encoding

   When they appear in id-regInfo-utf8Pairs syntax as named elements, the encoding intended algorithm of values for issuerName, subjectName and validity SHALL
   use the following syntax.  The characters [] indicate an optional
   field, ::= and | have their usual BNF meanings, private key, unless this information  
   -- is known a priori to both sender and all receiver by some other symbols
   (except spaces which are insignificant) outside non-terminal names
   are terminals.  Alphabetics are case-sensitive.

      issuerName  ::= <names>
      subjectName ::= <names>
      <names>     ::= <name> | <names>:<name>

      <validity>  ::= validity ? [<notbefore>]-[<notafter>]
      <notbefore> ::= <time>
      <notafter> means. 
    
   KeyGenParameters ::= <time>

   Where <time> is UTC time in OCTET STRING 
    
   The fields of PKIArchiveOptions have the form YYYYMMDD[HH[MM[SS]]].  HH, MM,
   and SS default following meaning: 
    
      encryptedPrivKey contains an encrypted version of the private key. 
       
      keyGenParameters contains the information needed by the requestor 
      to 00 and are omitted if at regenerate the and of value 00.

   Example validity encoding:

      validity?-19991231%

   is a validity interval with no value private key.  As an example, for notBefore many RSA 
      implementations one could send the first random number(s) tested 
      for primality.  [[[QUESTION:  What needs to be said here about the 
      fact that 1) the structure is absent and a value of
   December 31, 1999 2) the structure is not 
      explicitly encrypted for notAfter.

   Each name comprises a single character name form identifier followed protection as it travels on the 
      network!!!]]] 
       
      archiveRemGenPrivKey indicates that the requestor desires that the 
      key generated by a name value the CA/RA on the requestor's behalf be archived. 
    
   The fields of one or UTF8 characters. Within a name value, when
   it EncryptedKey have the following meaning: 
    
      encryptedValue is necessary to disambiguate a character which longer used.  This field has formatting
   significance at an outer level, been depreciated 
      along with the escape sequence %xx SHALL be
   used, where xx represents EncryptedValue structure. 
       
      envelopedData contains the hex encrypted value for of the encoding concerned.
   The percent symbol private key.  
      [[[QUESTION:  What key is represented by %%.

      <name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>

   Name forms and value formats this supposed to be encrypted for?  The 
      CA/RA archive key or some key of the user's?]]]  [[[QUESTION: Is 
      the encrypted content OID straight forward?]]] Details on 
      constructing an EnvelopedData structure are found in [CMS].  The 






      data to be encrypted MUST be a PrivateKeyInfo structure as follows:

   X.500 directory name form (identifier "X"):






Myers, et. al.             Expires Oct. 2003                   [Page 18]


Internet Draft                                                 Apr. 2003


   <xname> ::= <rdns>
      <rdns>  ::= <rdn> | <rdns> , <rdn>
      <rdn>   ::= <avas>
      <avas>  ::= <ava> | <avas> + <ava>
      <ava> defined 
      in [PKCS11] section 12.11. 
    
    
6.5  OldCert ID Control 
 
   If present, the OldCertID control specifies the certificate to be 
   updated by the current certification request.  The OID and syntax is: 
    
   id-regCtrl-oldCertID           OBJECT IDENTIFIER ::= <attyp> = <avalue>
      <attyp> { id-regCtrl 5 } 
    
   CertId ::= OID.<oid> | <stdat>

   Standard attribute type <stdat> is an alphabetic attribute type
   identifier from SEQUENCE { 
         issuer           GeneralName, 
         serialNumber     INTEGER 
     } 
    
6.6  Protocol Encryption Key Control 
 
   If present, the following set:

      C      (country)
      L      (locality)
      ST     (state or province)
      O      (organization)
      OU     (organizational unit)
      CN     (common name)
      STREET (street address)
      E      (E-mail address).

   <avalue> protocolEncrKey control specifies a key the CA is to 
   use in encrypting a name component response to CertReqMessages.  The OID for this 
   control is id-regCtrl-protocolEncrKey.  The parameter structure for 
   this field is SubjectPublicKeyInfo.  (This structure is defined in the form of 
   [CERTIFICATE].) 
    
   id-regCtrl-protocolEncrKey     OBJECT IDENTIFIER ::= { id-regCtrl 6 } 
    
   This control is used when a UTF8 character string
   of 1 CA has information to send to 64 characters, with the restriction 
   subscriber that in needs to be encrypted.  Such information includes a 
   private key generated by the IA5 subset of
   UTF8 only CA for use by the characters of ASN.1 PrintableString subscriber. 
    
   [[[QUESTION:  Does the bulk algorithm need to be specified as 
   well?]]] 
    
7.  RegInfo Controls 
 
   This section documents the controls that are to be placed in the 
   regInfo field of the CertReqMsg structure. 
    
7.1  utf8Pairs 
    
   This control is used to convey text based information from the 
   Subject to an RA to a CA issuing a certificate.  The OID for this 
   structure is id-regInfo-utf8Paris and has a type of UTF8String. 
    
      id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 } 
    






   The name is terminated by the question mark character ('?').  The 
   value is terminated by the percent character '%'.  Name value pairs 
   can be repeated.  Thus the syntax is: 
    
      Name?Value%[Name?Value%]* 
    
   The characters '?' and '%' are encoded using the %xx mechanism of 
   [RFC1738] if they are not being used for their reserve purposes. 
    
   [[[QUESTION:  How do I distinguish which of two purposes the '%' 
   character is currently being used for?]]] 
    
   This control can appear multiple times in the regInfo structure.  
   Resolution of conflicts of information is a matter of local policy on 
   the RA/CA. 
    
   Appendix A contains a set of common names and data formats 
   corresponding to fields that commonly appear in certificates and 
   directories. 
    
7.2  certReq 
    
   This control is designed to deal with the problem where an RA needs 
   to modify the certificate template proposed by a Subject, but the 
   Subject used the certificate template as part of its POP calculation.  
   In this case the RA can place a new certificate template in the 
   regInfo sequence. 
    
   This control has the OID id-regInfo-certReq and the structure 
   CertRequest.  There can only be one instance of this attribute in the 
   regInfo sequence.  If this control exists in the regInfo structure 
   then the certificate template in the request is ignored.  The RA MUST 
   copy all data from the core template to this attribute. 
    
      id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 } 
    
 
8.  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) } 
    
   -- arc for Registration Controls in CRMF 






   id-regCtrl  OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) } 
    
   -- arc for Registration Info in CRMF 
   id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) } 
    
    
9.  Security Considerations 
 
   Enrollment protocols, by their very nature, involve large amounts of 
   private information.  This can include private keys, identity 
   numbers, credit card numbers and the like.  The security of any CRP 
   is based on the security mechanisms of the protocol and/or process 
   used to communicate between CAs, RAs and EEs.  All protocols must 
   provide for masking, either via encryption or off-line processing, of 
   all subscriber-sensitive information. 
    
   Many enrollment protocols provide for the initial establishment of 
   identity between the CA/RA and the EE by the use of a token.  
   Generally this token is delivered using an out-of-band delivery 
   method (such as the governmental mail system).  The security of any 
   out-of-band exchange needs to be commensurate with the risk that the 
   CA/RA will tolerate with regard to interception of the token by a 
   third party. 
    
   Implementation must implement Proof-of-Possession (POP) values during 
   certificate enrollment processes.  A good POP algorithm needs to 
   provide proof of two things: 1) that the key is tied to a specific 
   user and 2) that the user has use of the key in question.  Failure to 
   implement POP allows for people to create certificates where the 
   public key and the name values do not correctly bind.  This allows 
   for impersonation on signature keys and interception of encrypted 
   messages. 
     
   Implementations must use high entropy random number generators in 
   producing private keys. Implementations must randomly generate 
   content-encryption keys, message-authentication keys, initialization 
   vectors (IVs), salt, and padding.  The use of inadequate pseudo-
   random number generators (PRNGs) to generate cryptographic keys can 
   result in little or no security.  An attacker may find it much easier 
   to reproduce the PRNG environment that produced the keys, searching 
   the resulting small set of possibilities, rather than brute force 
   searching the whole key space.  The generation of quality random 
   numbers is difficult.  RFC 1750 [RANDOM] offers important guidance in 
   this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality   
   PRNG technique. 
    






   Implementations must protect private keys.  The compromise of a 
   signer's private key permits third parties to masquerade as the 
   signer.  The compromise of a decryption private key allows for 
   interception of messages by a third party. 
    
   One feature of the certificate message request syntax is for the key 
   generation to be performed remotely from the creation of the 
   certificate request.  This feature should never be used for 
   generation of signing keys.  If signing keys are generated for the 
   user, then an element of repudiation comes into play.  The user can 
   claim that an item was signed by the entity that generated the key as 
   well as any entity that might have seen the key value during transfer 
   from the generator the to EE.  Care must be taken to protect 
   encryption keys by the remote key generator to protect againist 
   interception of the keys by a third party.  This means that the 
   encryption algorithms used need to be secure, and content encryption 
   key or key encryption key must be used to mask the private key during 
   transport back to the user.  CRP protocols must never assume that a 
   signature key generated by the user can be used to decrypt the 
   package that an encryption private key is transported in. 
    
   This document describes a method by which key escrow may be done.  
   There are several issues that need to be taken into account when 
   doing key escrow.  First, the client must be able to correctly 
   identify the entity to which a key is to be escrowed or the CRP must 
   provide a method by which the client can discover this information.  
   A CRP cannot assume that the key escrow agent and the CA are the same 
   entity and thus have the same names.  Second, the algorithms used 
   mask the private key or other key generation information during 
   transport to the escrow agent need to be commensurate with the value 
   of the data being protected by the key. Third, the escrow agent needs 
   to provide sufficient safeguards that an escrowed key is returned 
   only to entities that should be able to obtain the private key.  This 
   generally should be restricted to the entity that escrowed the data.  
   Fourth, the escrow data base needs to be stored in a secure manner.  
   One common method for doing this is to re-encrypt the data to keys 
   that only the escrow agent has access to.  In this case one may need 
   to escrow the escrow agent key as well.  Access to either the escrow 
   agent or the archived key would amount to access to all private keys 
   that have been escrowed with that agent. 
    
10. References 
 
10.1  Normative References 
    
   [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed- 
          Hashing for Message Authentication", RFC 2104, February 1997. 
    






   [PKCS11] RSA Laboratories, The Public-Key Cryptography Standards - 
          "PKCS #11 v2.11:  Cryptographic Token Interface Standard", RSA  
          Security Inc., June 2001. 
    
   [STDWORDS]  Bradner, S., "Key Words for Use in RFCs to Indicate 
               Requirement Levels", BCP 14, RFC 2119, March 1997. 
    
   [PROFILE]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 
               X.509 Public Key Infrastructure Certificate and 
               Certificate Revocation List (CRL) Profile", RFC 3280, 
               April 2002. 
    
   [CMS]       Housley, R, "Cryptographic Message Syntax (CMS)",  
               RFC 3369, August 2002 
    
   [RFC 2875] Prafullchandra, H., J. Schaad, "Diffie-Hellman Proof-of- 
              Possession Algorithms" RFC 2875, June 2000. 
    
10.2 Informative References 
 
    
   [RANDOM]    Eastlake, D., Crocker, S. and J. Schiller, "Randomness 
               Recommendations for Security, RFC 1750, December 1994.  
    
   [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 
             SHA-1", RFC 2202, September 1997. 
    
   [RFC1738]  Berners-Lee, T., Masinter, L. and M.  McCahill, 
             "Uniform Resource Locators (URL)", RFC 1738, December 1994. 
    
11. Acknowledgments 
 
   The working group would like to thank Michael Myers, Carlisle Adams, 
   Dave Solo and David Kemp who authored the original version of this 
   document. 
    
   The working group also gratefully acknowledges 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.  The members of the ca-talk mailing list also 
   provided significant input with respect to interoperability testing. 
    
   The text of Appendix C (Why do POP) was taken from an e-mail message 
   by Al Arsenault and was originally part of the PKIX Roadmap document. 
    
12. Authors' Addresses 
 
   Jim Schaad 






   Soaring Hawk Consulting 
   PO Box 675 
   Gold Bar, WA 98251 
    
   EMail: jimsch@exmsft.com 
    
    
Appendix A. Use of RegInfo for Name-Value Pairs 
 
   The "value" field of the id-regInfo-utf8Pairs string (with "tag" 
   field equal to 12 and appropriate "length" field) will contain a 
   series of UTF8 name/value pairs. 
    
   This Appendix lists some common examples of such pairs for the 
   purpose of promoting interoperability among independent 
   implementations of this specification.  It is recognized that this 
   list is not exhaustive and will grow with time and implementation 
   experience. 
    
A.1. Defined Names 
    
   The following table defines a recommended set of named elements. The 
   value in the column "Name Value" is the exact text string that will 
   appear in the regInfo. 
    
      Name Value 
      ---------- 
      version            -- version of this variation of regInfo use 
      corp_company       -- company affiliation of subscriber 
      org_unit           -- organizational unit 
      mail_firstName     -- personal name component 
      mail_middleName    -- personal name component 
      mail_lastName      -- personal name component 
      mail_email         -- subscriber's email address 
      jobTitle           -- job title of subscriber 
      employeeID         -- employee identification number or string 
      mailStop           -- mail stop 
      issuerName         -- name of CA 
      subjectName        -- name of Subject 
      validity           -- validity interval 
    
   For example: 
    
      version?1%corp_company?Example, Inc.%org_unit?Engineering% 
      mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% 
      mail_email?john@example.com% 
    






A.2 IssuerName, SubjectName and Validity Value Encoding 
 
   When they appear in id-regInfo-utf8Pairs syntax as named elements, 
   the encoding of values for issuerName, subjectName and validity SHALL 
   use the following syntax.  The characters [] indicate an optional 
   field, ::= and | have their usual BNF meanings, and all other symbols 
   (except spaces which are insignificant) outside non-terminal names 
   are terminals.  Alphabetics are case-sensitive. 
    
      issuerName  ::= <names> 
      subjectName ::= <names> 
      <names>     ::= <name> | <names>:<name> 
    
      <validity>  ::= validity ? [<notbefore>]-[<notafter>] 
      <notbefore> ::= <time> 
      <notafter>  ::= <time> 
    
   Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]].  HH, MM, 
   and SS default to 00 and are omitted if at the and of value 00. 
    
   Example validity encoding: 
    
      validity?-19991231% 
    
   is a validity interval with no value for notBefore and a value of 
   December 31, 1999 for notAfter. 
    
   Each name comprises a single character name form identifier followed 
   by a name value of one or UTF8 characters. Within a name value, when 
   it is necessary to disambiguate a character which has formatting 
   significance at an outer level, the escape sequence %xx SHALL be 
   used, where xx represents the hex value for the encoding concerned. 
   The percent symbol is represented by %%. 
    
      <name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname> 
    
   Name forms and value formats are as follows: 
    
   X.500 directory name form (identifier "X"): 
    
      <xname> ::= <rdns> 
      <rdns>  ::= <rdn> | <rdns> , <rdn> 
      <rdn>   ::= <avas> 
      <avas>  ::= <ava> | <avas> + <ava> 
      <ava>   ::= <attyp> = <avalue> 
      <attyp> ::= OID.<oid> | <stdat> 
    






   Standard attribute type <stdat> is an alphabetic attribute type 
   identifier from the following set: 
    
      C      (country) 
      L      (locality) 
      ST     (state or province) 
      O      (organization) 
      OU     (organizational unit) 
      CN     (common name) 
      STREET (street address) 
      E      (E-mail address). 
    
   <avalue> is a name component in the form of a UTF8 character string 
   of 1 to 64 characters, with the restriction that in the IA5 subset of 
   UTF8 only the characters of ASN.1 PrintableString may be used. 
    
   Other name form (identifier "O"): 
      <oname> ::= <oid> , <utf8string> 
    
   E-mail address (rfc822name) name form (identifier "E"): 
      <ename> ::= <ia5string> 
    
   DNS name form (identifier "D"): 
      <dname> ::= <ia5string> 
    
    
   URI name form (identifier "U"): 
      <uname> ::= <ia5string> 
    
   IP address (identifier "I"): 
      <iname> ::= <oid>

   For example:

      issuerName?XOU=Our CA,O=Acme,C=US%
      subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%

References

   [RFC1738]  Berners-Lee, T., Masinter, L. <oid> 
    
   For example: 
    
      issuerName?XOU=Our CA,O=Example,C=US% 
      subjectName?XCN=John Smith, O=Example, C=US, E=john@example.com% 
    
Appendix B. ASN.1 Structures and OIDs 
 
PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(XX)} 
 
DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 
 
IMPORTS 
  -- Directory Authentication Framework (X.509) 
     Version, AlgorithmIdentifier, Name, Time, 
     SubjectPublicKeyInfo, Extensions, UniqueIdentifier 






        FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 
            internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
            id-pkix1-explicit(18)} -- found in [PROFILE] 
 
  -- Certificate Extensions (X.509) 
     GeneralName 
        FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 
               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
               id-pkix1-implicit(19)}  -- found in [PROFILE] 
 
  -- Cryptographic Message Syntax 
     EnvelopedData 
        FROM CryptographicMessageSyntax { iso(1) member-body(2) 
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
             modules(0) cms-2001(14) };  -- found in [CMS] 
 
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg 
 
CertReqMsg ::= SEQUENCE { 
 certReq   CertRequest, 
 popo       ProofOfPossession  OPTIONAL, 
 -- content depends upon key type 
 regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL } 
 
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 
 
Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 
 
AttributeTypeAndValue ::= SEQUENCE { 
 type         OBJECT IDENTIFIER, 
 value        ANY DEFINED BY type } 
 
ProofOfPossession ::= CHOICE { 
 raVerified        [0] NULL, 
 -- used if the RA has already verified that the requester is in 






 -- possession of the private key 
 signature         [1] POPOSigningKey, 
 keyEncipherment   [2] POPOPrivKey, 
 keyAgreement      [3] POPOPrivKey } 
 
POPOSigningKey ::= SEQUENCE { 
 poposkInput           [0] POPOSigningKeyInput OPTIONAL, 
 algorithmIdentifier   AlgorithmIdentifier, 
 signature             BIT STRING } 
 -- The signature (using "algorithmIdentifier") is on the 
 -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg 
 -- certReq CertTemplate contains the subject and M.  McCahill,
             "Uniform Resource Locators (URL)", RFC 1738, December 1994.





Myers, et. al.             Expires Oct. 2003                   [Page 19]


Internet Draft                                                 Apr. 2003


Appendix C. ASN.1 Structures publicKey values, 
 -- then poposkInput MUST be omitted and OIDs

PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}

DEFINITIONS IMPLICIT TAGS the signature MUST be 
 -- computed on the DER-encoded value of CertReqMsg certReq.  If 
 -- the CertReqMsg certReq CertTemplate does not contain both the  
 -- public key and subject values (i.e., if it contains only one  
 -- of these, or neither), then poposkInput MUST be present and 
 -- MUST be signed.   
 
 
POPOSigningKeyInput ::=
BEGIN

IMPORTS SEQUENCE { 
 authInfo            CHOICE { 
     sender              [0] GeneralName, 
     -- Directory Authentication Framework (X.509)
        Version, AlgorithmIdentifier, Name, Time,
        SubjectPublicKeyInfo, Extensions, UniqueIdentifier
           FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
               id-pkix1-explicit-88(1)} used only if an authenticated identity has been 
     -- Certificate Extensions (X.509) established for the sender (e.g., a DN from a 
     -- previously-issued and currently-valid certificate 
     publicKeyMAC        PKMACValue }, 
     -- used if no authenticated GeneralName
           FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
                  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                  id-pkix1-implicit-88(2)} currently exists for 
     -- Cryptographic Message Syntax
        EnvelopedData
           FROM CryptographicMessageSyntax { iso(1) member-body(2)
                us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
                modules(0) cms(1) };

CertReqMessages the sender; publicKeyMAC contains a password-based MAC 
     -- on the DER-encoded value of publicKey 
 publicKey           SubjectPublicKeyInfo }  -- from CertTemplate 
 
PKMACValue ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg { 
algId  AlgorithmIdentifier, 
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13} 
-- parameter value is PBMParameter 
value  BIT STRING } 
 
PBMParameter ::= SEQUENCE { 
   salt                OCTET STRING, 
   owf                 AlgorithmIdentifier, 
   -- AlgId for a One-Way Function (SHA-1 recommended) 
   iterationCount      INTEGER, 
   -- number of times the OWF is applied 
   mac                 AlgorithmIdentifier 
   -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 
}   -- or HMAC [HMAC, RFC2202]) 
 
POPOPrivKey ::= CHOICE { 
 thisMessage       [0] BIT STRING, 
 -- posession is proven in this message (which contains the private 
 -- key itself (encrypted for the CA)) 
 subsequentMessage [1] SubsequentMessage, 
 -- possession will be proven in a subsequent message 






 dhMAC             [2] BIT STRING } 
 -- for keyAgreement (only), possession is proven in this message 
 -- (which contains a MAC (over the DER-encoded value of the 
 -- certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL, parameter in CertReqMsg, which MUST include both subject 
 -- content depends upon and publicKey) based on a key type
    regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL derived from the end entity's 
 -- private DH key and the CA's public DH key); 
 
 -- the dhMAC value MUST be calculated as per the directions given 
 -- in Appendix A. 
 
SubsequentMessage ::= INTEGER { 
 encrCert (0), 
 -- requests that resulting certificate be encrypted for the 
 -- end entity (following which, POP will be proven in a 
 -- confirmation message) 
 challengeResp (1) }

CertRequest 
 -- requests that CA engage in challenge-response exchange with 
 -- end entity in order to prove private key possession 
 
-- Object identifier assignments -- 
 
id-pkix  OBJECT IDENTIFIER  ::= SEQUENCE {
    certReqId     INTEGER, iso(1) identified-organization(3) 
dod(6) internet(1) security(5) mechanisms(5) 7 } 
 
-- ID arc for matching request Internet X.509 PKI protocols and reply
    certTemplate  CertTemplate,  -- Selected fields of cert to be issued
    controls      Controls OPTIONAL }   -- Attributes affecting issuance

CertTemplate their components 
 
id-pkip  OBJECT IDENTIFIER ::= 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,




Myers, et. al.             Expires Oct. 2003                   [Page 20]


Internet Draft                                                 Apr. 2003


    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
    issuerUID    [7] UniqueIdentifier      OPTIONAL,
    subjectUID   [8] UniqueIdentifier      OPTIONAL,
    extensions   [9] Extensions            OPTIONAL id-pkix 5 }

OptionalValidity 
 
-- Registration Controls in CRMF 
id-regCtrl OBJECT IDENTIFIER ::= SEQUENCE {
    notBefore  [0] Time OPTIONAL,
    notAfter   [1] Time OPTIONAL id-pkip 1 } --at least one MUST 
 
-- The following definition may be present

Controls uncommented for use with 
-- ASN.1 compilers which do not understand UTF8String. 
 
-- UTF8String ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue [UNIVERSAL 12] IMPLICIT OCTET STRING 
 
id-regCtrl-regToken OBJECT IDENTIFIER ::= SEQUENCE {
    type         OBJECT IDENTIFIER,
    value        ANY DEFINED BY type id-regCtrl 1 }

ProofOfPossession 
 
--with syntax: 
RegToken ::= UTF8String 
 
id-regCtrl-authenticator OBJECT IDENTIFIER ::= CHOICE {
    raVerified        [0] NULL,
    -- used if the RA has already verified that the requester is in
    -- possession of the private key
    signature         [1] POPOSigningKey,
    keyEncipherment   [2] POPOPrivKey,
    keyAgreement      [3] POPOPrivKey id-regCtrl 2 }

POPOSigningKey 
--with syntax: 
Authenticator ::= UTF8String 
 
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= SEQUENCE {
    poposkInput           [0] POPOSigningKeyInput OPTIONAL,
    algorithmIdentifier   AlgorithmIdentifier,
    signature             BIT STRING id-regCtrl 3 } 
--with syntax: 
 
PKIPublicationInfo ::= SEQUENCE { 
action     INTEGER { 
             dontPublish (0), 
             pleasePublish (1) }, 
pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } 
  -- The signature (using "algorithmIdentifier") is on the
    -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
    -- certReq CertTemplate contains the subject and publicKey values,
    -- then poposkInput MUST be omitted and the signature pubInfos MUST NOT be
    -- computed on the DER-encoded value of CertReqMsg certReq.  If
    -- the CertReqMsg certReq CertTemplate does not contain both the 
    -- public key and subject values (i.e., present if it contains only one action is "dontPublish" 






  -- of these, or neither), then poposkInput MUST be present (if action is "pleasePublish" and pubInfos is omitted, 
  -- MUST be signed.  


POPOSigningKeyInput "dontCare" is assumed) 
 
SinglePubInfo ::= SEQUENCE {
    authInfo            CHOICE 
 pubMethod    INTEGER {
        sender              [0] GeneralName,
        -- used only if an authenticated identity has been
        -- established for the sender (e.g., a DN from a
        -- previously-issued and currently-valid certificate
        publicKeyMAC        PKMACValue 
     dontCare    (0), 
     x500        (1), 
     web         (2), 
     ldap        (3) },
        -- used if no authenticated 
 pubLocation  GeneralName currently exists for
        -- the sender; publicKeyMAC contains a password-based MAC
        -- on the DER-encoded value of publicKey




Myers, et. al.             Expires Oct. 2003                   [Page 21]


Internet Draft                                                 Apr. 2003


    publicKey           SubjectPublicKeyInfo OPTIONAL }  -- from CertTemplate

PKMACValue 
 
id-regCtrl-pkiArchiveOptions     OBJECT IDENTIFIER ::= SEQUENCE {
   algId  AlgorithmIdentifier,
   -- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
   -- parameter value is PBMParameter
   value  BIT STRING id-regCtrl 4 }

PBMParameter 
--with syntax: 
PKIArchiveOptions ::= SEQUENCE CHOICE {
      salt                OCTET STRING,
      owf                 AlgorithmIdentifier,
      -- AlgId for a One-Way Function (SHA-1 recommended)
      iterationCount      INTEGER, 
 encryptedPrivKey     [0] EncryptedKey, 
 -- number the actual value of times the OWF is applied
      mac                 AlgorithmIdentifier 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 MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} receiver generates in response to 
 -- or HMAC [RFC2104, RFC2202])

POPOPrivKey this request; set to FALSE if no archival is desired. 
 
EncryptedKey ::= CHOICE {
    thisMessage 
 encryptedValue        EncryptedValue, 
 envelopedData     [0] BIT STRING, EnvelopedData } 
 -- posession is proven The encrypted private key MUST be placed in this message (which contains the private envelopedData 
 -- key itself (encrypted encryptedContentInfo encryptedContent OCTET STRING. 
 
EncryptedValue ::= SEQUENCE { 
 intendedAlg   [0] AlgorithmIdentifier  OPTIONAL, 
 -- the intended algorithm for which the CA))
    subsequentMessage [1] SubsequentMessage,
    -- possession value will be proven in a subsequent message
    dhMAC used 
 symmAlg       [1] AlgorithmIdentifier  OPTIONAL, 
 -- the symmetric algorithm used to encrypt the value 
 encSymmKey    [2] BIT STRING }
    -- for keyAgreement (only), possession is proven in this message           OPTIONAL, 
 -- (which contains a MAC (over the DER-encoded value of the
    -- certReq parameter in CertReqMsg, which MUST include both subject
    -- and publicKey) based on a (encrypted) symmetric key derived from used to encrypt the end entity's value 
 keyAlg        [3] AlgorithmIdentifier  OPTIONAL, 
 -- private DH key and algorithm used to encrypt the CA's public DH key); symmetric key 
 valueHint     [4] OCTET STRING         OPTIONAL, 
 -- a brief description or identifier of the dhMAC value MUST encValue content 
 -- (may be calculated as per meaningful only to the directions given
    -- in Appendix A.

SubsequentMessage ::= INTEGER {
    encrCert (0), sending entity, and used only 
 -- requests that resulting certificate if EncryptedValue might be encrypted for re-examined by the
    -- end sending entity (following which, POP will be proven in a 
 -- confirmation message)
    challengeResp (1) in the future) 
 encValue       BIT STRING } 
 -- requests that CA engage in challenge-response exchange with the encrypted value itself 
-- end entity in order When EncryptedValue is used to prove carry a private key possession

-- Object identifier assignments --

id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 } (as opposed to 
-- arc for Internet X.509 PKI protocols and their components




Myers, et. al.             Expires Oct. 2003                   [Page 22]


Internet Draft                                                 Apr. 2003


id-pkip  OBJECT IDENTIFIER ::= { id-pkix 5 } a certificate), implementations MUST support the encValue field 
-- Registration Controls containing an encrypted PrivateKeyInfo as defined in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 } [PKCS11], 
-- section 12.11. If encValue contains some other format/encoding  
-- The following definition may be uncommented for use with the private key, the first octet of valueHint MAY be used  
-- ASN.1 compilers which do not understand UTF8String. to indicate the format/encoding (but note that the possible values  
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String

id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String

id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:

PKIPublicationInfo ::= SEQUENCE {
   action     INTEGER {
                dontPublish (0),
                pleasePublish (1) },
   pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } of this octet are not specified at this time).  In all cases, the  
-- pubInfos intendedAlg field MUST NOT be present if action is "dontPublish" used to indicate at least the OID of  
-- (if action is "pleasePublish" and pubInfos is omitted, the intended algorithm of the private key, unless this information  






-- "dontCare" is assumed)

SinglePubInfo known a priori to both sender and receiver by some other means. 
 
KeyGenParameters ::= OCTET STRING 
 
 
id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 } 
--with syntax: 
OldCertId ::= CertId 
 
CertId ::= SEQUENCE {
    pubMethod 
 issuer           GeneralName, 
 serialNumber     INTEGER {
        dontCare    (0),
        x500        (1),
        web         (2),
        ldap        (3) },
    pubLocation  GeneralName OPTIONAL }

id-regCtrl-pkiArchiveOptions 
 
id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 4 6 } 
--with syntax:
PKIArchiveOptions 
ProtocolEncrKey ::= CHOICE {
    encryptedPrivKey     [0] EncryptedKey, SubjectPublicKeyInfo 
 
-- the actual value Registration Info in CRMF 
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 } 
 
id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 } 
--with syntax 
UTF8Pairs ::= UTF8String 
 
 
id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 } 
--with syntax 
CertReq ::= CertRequest 
 
END 
    
Appendix C. Why do Proof of Possession (POP). 
    
   Proof of Possession, or POP, means that the private key
    keyGenParameters     [1] KeyGenParameters,
    -- parameters which allow CA is adequately 
   convinced that the private entity requesting a certificate containing a 
   public key Y has access to be re-generated
    archiveRemGenPrivKey [2] BOOLEAN }
    -- set to TRUE if sender wishes receiver to archive the private
    -- key X corresponding to that 
   public key.   
    
   POP is important because it provides an appropriate level of 
   assurance in the correct operation of the PKI as a key pair which whole.  At its 
   lowest level, POP counters the receiver generates in response to




Myers, et. al.             Expires Oct. 2003                   [Page 23]


Internet Draft                                                 Apr. 2003


    -- this request; set "self-inflicted denial of service"; 
   that is, an entity voluntarily getting a certificate that cannot be 
   used to FALSE if no archival sign or encrypt/decrypt information.  However, as the 
   following two examples demonstrate, POP also counters less direct, 
   but more severe, threats: 
    
      POP for signing keys: it is desired.

EncryptedKey ::= CHOICE {
    encryptedValue        EncryptedValue,
    envelopedData     [0] EnvelopedData }
    -- The encrypted important to provide POP for keys used 
      to sign material, in order to provide non-repudiation of 
      transactions.  For example, suppose Alice legitimately has private 
      key MUST X and its corresponding public key Y.  Alice has a certificate 
      from Charlie, a CA, containing Y.  Alice uses X to sign a 
      transaction T.  Without POP, Mal could also get a certificate from 






      Charlie containing the same public key, Y.  Now, there are two 
      possible threats: Mal could claim to have been the real signer of 
      T; or Alice can falsely deny signing T, claiming that it was 
      instead Mal.  Since no one can reliably prove that Mal did or did 
      not ever possess X, neither of these claims can be placed in refuted, and 
      thus the envelopedData
    -- encryptedContentInfo encryptedContent OCTET STRING.


EncryptedValue ::= SEQUENCE {
    intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
    -- service provided by and the intended algorithm for which confidence in the value PKI has 
      been defeated.  (Of course, if Mal really did possess X, Alice's 
      private key, then no POP mechanism in the world will help, but 
      that is a different problem.)   
       
      Note that one level of protection can be used
    symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
    -- gained by having Alice, 
      as the symmetric algorithm used to encrypt true signer of the value
    encSymmKey    [2] BIT STRING           OPTIONAL,
    -- transaction; include in the (encrypted) symmetric key used signed 
      information her certificate or an identifier of her certificate 
      (e.g., a hash of her certificate).  This might make it more 
      difficult for Mal to encrypt the value
    keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
    -- algorithm used claim authorship; he would have to encrypt assert 
      that he incorrectly included Alice's certificate, rather than his 
      own.  However, it would not stop Alice from falsely repudiating 
      her actions. Since the symmetric key
    valueHint     [4] OCTET STRING         OPTIONAL,
    -- certificate itself is a brief description public item, Mal 
      indeed could have inserted Alice's certificate or identifier of the encValue content
    -- (may be meaningful only to into 
      the sending entity, signed transaction, and used only
    -- if EncryptedValue might be re-examined by thus its presence does not indicate 
      that Alice was the sending entity
    -- one who participated in the future)
    encValue       BIT STRING }
    -- now-repudiated 
      transaction. The only reliable way to stop this attack is to 
      require that Mal prove he possesses X before his certificate is 
      issued. 
       
      For signing keys used only for authentication, and not for non-
      repudiation, the encrypted value itself
-- When EncryptedValue threat is lower because users may not care about 
      Alice's after-the-fact repudiation, and thus POP becomes less 
      important.  However, POP SHOULD still be done wherever feasible in 
      this environment, by either off-line or on-line means.  
       
      POP for key management keys:  Similarly, POP for key management 
      keys (that is, keys used to carry a private for either key (as opposed agreement or key exchange) 
      can help to
-- a certificate), implementations MUST support prevent undermining confidence in the encValue field
-- containing an encrypted PrivateKeyInfo as defined PKI.  Suppose 
      that Al is a new instructor in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding 
-- for the private key, Computer Science Department of 
      a local University.  Al has created a draft final exam for the first octet 
      Introduction to Networking course he is teaching.  He wants to 
      send a copy of valueHint MAY be used 
-- the draft final to indicate Dorothy, the format/encoding (but note that Department Head, 
      for her review prior to giving the possible values 
-- exam.  This exam will of this octet are not specified at this time).  In all cases, the 
-- intendedAlg field MUST course 
      be used encrypted, as several students have access to indicate at least the OID computer 
      system.  However, a quick search of 
-- the intended algorithm of certificate repository 
      (e.g., search the private key, unless repository for all records with 
      subjectPublicKey=Dorothy's-value) turns up the fact that several 
      students have certificates containing the same public key 
      management key as Dorothy.  At this information 
-- is known a priori to both sender and receiver point, if no POP has been done 
      by some other means.

















Myers, et. al.             Expires Oct. 2003                   [Page 24]


Internet Draft                                                 Apr. 2003


KeyGenParameters ::= OCTET STRING

id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId

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

id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo

-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }

id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String

id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest

END


























Myers, et. al.             Expires Oct. 2003                   [Page 25]


Internet Draft                                                 Apr. 2003



APPENDIX D - Full Copyright Statement

   Copyright (C) The Internet Society 2001. All Rights Reserved.
   This document and translations the CA, Al has no way of knowing whether all of the students 
      have simply created these certificates without knowing the 
      corresponding private key (and thus it may be copied and furnished is safe to
   others, and derivative works that comment on send the 
      encrypted exam to Dorothy), or otherwise explain whether the students have somehow 
      acquired Dorothy's private key (and thus it
   or assist in its implementation may is certainly not safe 
      to send the exam).  Thus, the service to be prepared, copied, published
   and distributed, provided by the 
      PKI allowing users to communicate with one another, with 
      confidence in whole who they are communicating with - has been totally 
      defeated. If the CA is providing POP, then either no students will 






      have such certificates, or in part, without restriction of any
   kind, provided Al can know with certainty that the above copyright notice 
      students do indeed know Dorothy's private key, and act 
      accordingly. 
    
Appendix D - Change History 
    
D.1 Changes from -06 to -07 
    
   1.  The editor of the document changed.  When this paragraph are
   included occurred a huge 
       number of textual re-writes were applied based on all such copies and derivative works. However, this how the new 
       editor felt that a document itself may not should be modified in any way, such as by removing
   the copyright notice or references to laid out based on his prior 
       experience.  This means that massive parts of the Internet Society or other
   Internet organizations, except as needed for document cannot 
       be diff-ed against the purpose of develop-
   ing Internet standards in which case previous document to see what happened. 
   2.  Comments from the procedures for copyrights
   defined in IESG review were responded to by the Internet Standards process shall be followed, or editor. 
   3.  Section 2.1 - Changes since RFC 2511 was added as required for 
       all updated RFC documents 
   4.  Added Appendix C - Why POP? 
   5.  Defined and added a Certificate Request Protocol to translate it into languages other than English.

   The limited permissions granted above are perpetual refer to this 
       document and will not to impose restrictions and requirements on such a 
       protocol. 
   6.  Rename the CertReqMsg field pop to popo so that pop and POP would 
       no longer potentially be
   revoked by confused. 
   7.  Added support for DES-MAC and Triple-DES-MAC to Password Based 
       MACs. 
   8.  Greatly expanded the Security Considerations Section 
    
Appendix E - Full Copyright Statement 
 
   Copyright (C) The Internet Society or its successors or assigns. (year). This document is 
   Subject to the rights, licenses and restrictions contained in BCP 78, 
   and except as set forth therein, the authors retain all their 
   rights." 
    
   This document and the information contained herein is are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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.



























Myers, et. al.             Expires Oct. 2003                   [Page 26] 
       
          

----