tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5272

 
 
 

Certificate Management over CMS (CMC)

Part 4 of 4, p. 65 to 83
Prev RFC Part

 


prevText      Top      Up      ToC       Page 65 
Appendix A.  ASN.1 Module

 EnrollmentMessageSyntax
 { iso(1) identified-organization(3) dod(4) internet(1)
 security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }

 DEFINITIONS IMPLICIT TAGS ::=
 BEGIN

 -- EXPORTS All --
 -- The types and values defined in this module are exported for use
 -- in the other ASN.1 modules.  Other applications may use them for
 -- their own purposes.

 IMPORTS

   -- PKIX Part 1 - Implicit    From [PKIXCERT]
      GeneralName, CRLReason, ReasonFlags
      FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-pkix1-implicit(19)}

   -- PKIX Part 1 - Explicit    From [PKIXCERT]
      AlgorithmIdentifier, Extension, Name, CertificateSerialNumber
      FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-pkix1-explicit(18)}

   -- Cryptographic Message Syntax   FROM [CMS]
      ContentInfo, Attribute, IssuerAndSerialNumber
        FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             modules(0) cms-2004(24)}

 -- CRMF                         FROM [CRMF]
    CertReqMsg, PKIPublicationInfo, CertTemplate
    FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6)
           internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-crmf2005(36)};

   -- Global Types
      UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
        -- The content of this type conforms to RFC 2279.

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

 id-cmc OBJECT IDENTIFIER ::= {id-pkix 7}   -- CMC controls
 id-cct OBJECT IDENTIFIER ::= {id-pkix 12}  -- CMC content types

 -- The following controls have the type OCTET STRING

 id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
 id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
 id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
 id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
 id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
 id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
 id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}

 -- The following controls have the type UTF8String

 id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}

 -- The following controls have the type INTEGER

 id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}

 -- The following controls have the type OCTET STRING

 id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
 id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}

  -- This is the content type used for a request message in the protocol

 id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }

 PKIData ::= SEQUENCE {
     controlSequence    SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
     reqSequence        SEQUENCE SIZE(0..MAX) OF TaggedRequest,
     cmsSequence        SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
     otherMsgSequence   SEQUENCE SIZE(0..MAX) OF OtherMsg
 }

  bodyIdMax INTEGER ::= 4294967295

  BodyPartID ::= INTEGER(0..bodyIdMax)

Top      Up      ToC       Page 67 
 TaggedAttribute ::= SEQUENCE {
     bodyPartID         BodyPartID,
     attrType           OBJECT IDENTIFIER,
     attrValues         SET OF AttributeValue
 }

  AttributeValue ::= ANY

  TaggedRequest ::= CHOICE {
      tcr               [0] TaggedCertificationRequest,
      crm               [1] CertReqMsg,
      orm               [2] SEQUENCE {
          bodyPartID            BodyPartID,
          requestMessageType    OBJECT IDENTIFIER,
          requestMessageValue   ANY DEFINED BY requestMessageType
      }
  }

  TaggedCertificationRequest ::= SEQUENCE {
      bodyPartID            BodyPartID,
      certificationRequest  CertificationRequest
  }

  CertificationRequest ::= SEQUENCE {
    certificationRequestInfo  SEQUENCE {
      version                   INTEGER,
      subject                   Name,
      subjectPublicKeyInfo      SEQUENCE {
        algorithm                 AlgorithmIdentifier,
        subjectPublicKey          BIT STRING },
      attributes                [0] IMPLICIT SET OF Attribute },
    signatureAlgorithm        AlgorithmIdentifier,
    signature                 BIT STRING
  }

 TaggedContentInfo ::= SEQUENCE {
     bodyPartID              BodyPartID,
     contentInfo             ContentInfo
 }

 OtherMsg ::= SEQUENCE {
     bodyPartID        BodyPartID,
     otherMsgType      OBJECT IDENTIFIER,
     otherMsgValue     ANY DEFINED BY otherMsgType }

Top      Up      ToC       Page 68 
 --  This defines the response message in the protocol
 id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }

 ResponseBody ::= PKIResponse

 PKIResponse ::= SEQUENCE {
     controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
     cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
     otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg

 }

 -- Used to return status state in a response

 id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}

 CMCStatusInfo ::= SEQUENCE {
     cMCStatus       CMCStatus,
     bodyList        SEQUENCE SIZE (1..MAX) OF BodyPartID,
     statusString    UTF8String OPTIONAL,
     otherInfo        CHOICE {
       failInfo         CMCFailInfo,
       pendInfo         PendInfo } OPTIONAL
 }

 PendInfo ::= SEQUENCE {
     pendToken        OCTET STRING,
     pendTime         GeneralizedTime
 }

 CMCStatus ::= INTEGER {
     success         (0),
     failed          (2),
     pending         (3),
     noSupport       (4),
     confirmRequired (5),
     popRequired     (6),
     partial                (7)
 }

 -- Note:
 -- The spelling of unsupportedExt is corrected in this version.
 -- In RFC 2797, it was unsuportedExt.

Top      Up      ToC       Page 69 
 CMCFailInfo ::= INTEGER {
     badAlg          (0),
     badMessageCheck (1),
     badRequest      (2),
     badTime         (3),
     badCertId       (4),
     unsupportedExt  (5),
     mustArchiveKeys (6),
     badIdentity     (7),
     popRequired     (8),
     popFailed       (9),
     noKeyReuse      (10),
     internalCAError (11),
     tryLater        (12),
     authDataFail    (13)
 }

 -- Used for RAs to add extensions to certification requests
 id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}

 AddExtensions ::= SEQUENCE {
     pkiDataReference    BodyPartID,
     certReferences      SEQUENCE OF BodyPartID,
     extensions          SEQUENCE OF Extension
 }


 id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
 id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}

 EncryptedPOP ::= SEQUENCE {
     request       TaggedRequest,
     cms             ContentInfo,
     thePOPAlgID     AlgorithmIdentifier,
     witnessAlgID    AlgorithmIdentifier,
     witness         OCTET STRING
 }

 DecryptedPOP ::= SEQUENCE {
     bodyPartID      BodyPartID,
     thePOPAlgID     AlgorithmIdentifier,
     thePOP          OCTET STRING
 }

  id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}

Top      Up      ToC       Page 70 
  LraPopWitness ::= SEQUENCE {
      pkiDataBodyid   BodyPartID,
      bodyIds         SEQUENCE OF BodyPartID
  }

 --
 id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}

 GetCert ::= SEQUENCE {
     issuerName      GeneralName,
     serialNumber    INTEGER }

 id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}

 GetCRL ::= SEQUENCE {
     issuerName    Name,
     cRLName       GeneralName OPTIONAL,
     time          GeneralizedTime OPTIONAL,
     reasons       ReasonFlags OPTIONAL }

 id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}

 RevokeRequest ::= SEQUENCE {
     issuerName            Name,
     serialNumber          INTEGER,
     reason                CRLReason,
     invalidityDate         GeneralizedTime OPTIONAL,
     passphrase            OCTET STRING OPTIONAL,
     comment               UTF8String OPTIONAL }

 id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}

 CMCCertId ::= IssuerAndSerialNumber

 -- The following is used to request V3 extensions be added to a
 -- certificate

 id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs-9(9) 14}

 ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension

 -- The following exists to allow Diffie-Hellman Certification Requests
 -- Messages to be well-formed

 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}

 NoSignatureValue ::= OCTET STRING

Top      Up      ToC       Page 71 
 --  Unauthenticated attribute to carry removable data.
 --    This could be used in an update of "CMC Extensions: Server Side
 --    Key Generation and Key Escrow" (February 2005) and in other
 --    documents.

 id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}

 CMCUnsignedData ::= SEQUENCE {
     bodyPartPath        BodyPartPath,
     identifier          OBJECT IDENTIFIER,
     content             ANY DEFINED BY identifier
 }

 --  Replaces CMC Status Info
 --

 id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}

 CMCStatusInfoV2 ::= SEQUENCE {
    cMCStatus             CMCStatus,
    bodyList              SEQUENCE SIZE (1..MAX) OF
                                   BodyPartReference,
    statusString          UTF8String OPTIONAL,
    otherInfo             CHOICE {
      failInfo               CMCFailInfo,
      pendInfo               PendInfo,
      extendedFailInfo       SEQUENCE {
         failInfoOID            OBJECT IDENTIFIER,
         failInfoValue          AttributeValue
      }
    } OPTIONAL
 }

 BodyPartReference ::= CHOICE {
    bodyPartID           BodyPartID,
    bodyPartPath         BodyPartPath
 }

 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

Top      Up      ToC       Page 72 
 --  Allow for distribution of trust anchors
 --

 id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}

 PublishTrustAnchors ::= SEQUENCE {
     seqNumber      INTEGER,
     hashAlgorithm  AlgorithmIdentifier,
     anchorHashes     SEQUENCE OF OCTET STRING
 }

 id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}

 AuthPublish ::= BodyPartID

 --   These two items use BodyPartList
 id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
 id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}

 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

 --
 id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}

 CMCPublicationInfo ::= SEQUENCE {
     hashAlg                      AlgorithmIdentifier,
     certHashes                   SEQUENCE OF OCTET STRING,
     pubInfo                          PKIPublicationInfo
 }

 id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}

 ModCertTemplate ::= SEQUENCE {
     pkiDataReference             BodyPartPath,
     certReferences               BodyPartList,
     replace                      BOOLEAN DEFAULT TRUE,
     certTemplate                 CertTemplate
 }

 -- Inform follow on servers that one or more controls have already been
 -- processed

 id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}

 ControlsProcessed ::= SEQUENCE {
     bodyList              SEQUENCE SIZE(1..MAX) OF BodyPartReference
 }

Top      Up      ToC       Page 73 
 --  Identity Proof control w/ algorithm agility

 id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }

 IdentifyProofV2 ::= SEQUENCE {
     proofAlgID       AlgorithmIdentifier,
     macAlgId         AlgorithmIdentifier,
     witness          OCTET STRING
 }

 id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
 PopLinkWitnessV2 ::= SEQUENCE {
     keyGenAlgorithm   AlgorithmIdentifier,
     macAlgorithm      AlgorithmIdentifier,
     witness           OCTET STRING
 }

 END

Top      Up      ToC       Page 74 
Appendix B.  Enrollment Message Flows

   This section is informational.  The purpose of this section is to
   present, in an abstracted version, the messages that would flow
   between the client and server for several different common cases.

B.1.  Request of a Signing Certificate

   This section looks at the messages that would flow in the event that
   an enrollment is occurring for a signing-only key.  If the
   certificate was designed for both signing and encryption, the only
   difference would be the key usage extension in the certification
   request.

   Message #2 from client to server:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-identityProof, computed value}
           {103, id-cmc-senderNonce, 10001}
         reqSequence
           certRequest
             certReqId = 201
             certTemplate
               subject = My Proposed DN
               publicKey = My Public Key
               extensions
                 {id-ce-subjectPublicKeyIdentifier, 1000}
                 {id-ce-keyUsage, digitalSignature}
     SignedData.SignerInfos
       SignerInfo
         sid.subjectKeyIdentifier = 1000

Top      Up      ToC       Page 75 
   Response from server to client:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {102, id-cmc-statusInfoV2, {success, 201}}
           {103, id-cmc-senderNonce, 10005}
           {104, id-cmc-recipientNonce, 10001}
     certificates
       Newly issued certificate
       Other certificates
     SignedData.SignerInfos
       Signed by CA

B.2.  Single Certification Request, But Modified by RA

   This section looks at the messages that would flow in the event that
   an enrollment has one RA in the middle of the data flow.  That RA
   will modify the certification request before passing it on to the CA.

   Message from client to RA:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-identityProof, computed value}
           {103, id-cmc-senderNonce, 10001}
         reqSequence
           certRequest
             certReqId = 201
             certTemplate
               subject = My Proposed DN
               publicKey = My Public Key
               extensions
                 {id-ce-subjectPublicKeyIdentifier, 1000}
                 {id-ce-keyUsage, digitalSignature}
     SignedData.SignerInfos
       SignerInfo
         sid.subjectKeyIdentifier = 1000

Top      Up      ToC       Page 76 
   Message from RA to CA:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           { 102, id-cmc-batchRequests, { 1, 2} }
           { 103, id-cmc-addExtensions,
             { {1, 201, {id-ce-certificatePolicies, anyPolicy}}
               {1, 201, {id-ce-subjectAltName, {extension data}}
               {2, XXX, {id-ce-subjectAltName, {extension data}}}
                     The Value XXX is not known here; it would
                     reference into the second client request,
                     which is not displayed above.
         cmsSequence
           { 1, <Message from client to RA #1> }
           { 2, <Message from client to RA #2> }
     SignedData.SignerInfos
       SignerInfo
         sid = RA key.

Top      Up      ToC       Page 77 
   Response from CA to RA:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {102, id-cmc-BatchResponse, {999, 998}}

           {103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
         cmsSequence
           { bodyPartID = 999
             contentInfo
               ContentInfo.contentType = id-signedData
               ContentInfo.content
                 SignedData.encapContentInfo
                   eContentType = id-ct-PKIResponse
                   eContent
                     controlSequence
                      {102, id-cmc-statusInfoV2, {success, 201}}
                 certificates
                   Newly issued certificate
                   Other certificates
                 SignedData.SignerInfos
                   Signed by CA
           }
           { bodyPartID = 998,
             contentInfo
               ContentInfo.contentType = id-signedData
               ContentInfo.content
                 SignedData.encapContentInfo
                   eContentType = id-ct-PKIResponse
                   eContent
                     controlSequence
                       {102, id-cmc-statusInfoV2, {failure, badAlg}}
                 certificates
                   Newly issued certificate
                   Other certificates
                 SignedData.SignerInfos
                   Signed by CA
           }
         SignedData.SignerInfos
           Signed by CA

Top      Up      ToC       Page 78 
   Response from RA to client:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {102, id-cmc-statusInfoV2, {success, 201}}
     certificates
       Newly issued certificate
       Other certificates
     SignedData.SignerInfos
       Signed by CA

B.3.  Direct POP for an RSA Certificate

   This section looks at the messages that would flow in the event that
   an enrollment is done for an encryption only certificate using an
   direct POP method.  For simplicity, it is assumed that the
   certification requester already has a signing-only certificate.

   The fact that a second round-trip is required is implicit rather than
   explicit.  The server determines this based on the fact that no other
   POP exists for the certification request.

Top      Up      ToC       Page 79 
   Message #1 from client to server:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-transactionId, 10132985123483401}
           {103, id-cmc-senderNonce, 10001}
           {104, id-cmc-dataReturn, <packet of binary data identifying
                                     where the key in question is.>}
         reqSequence
           certRequest
             certReqId = 201
             certTemplate
               subject = <My DN from my signing cert>
               publicKey = My Public Key
               extensions
                 {id-ce-keyUsage, keyEncipherment}
             popo
               keyEncipherment
                 subsequentMessage
     SignedData.SignerInfos
       SignerInfo
         Signed by requester's signing cert

   Response #1 from server to client:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
           {102, id-cmc-transactionId, 10132985123483401}
           {103, id-cmc-senderNonce, 10005}
           {104, id-cmc-recipientNonce, 10001}
           {105, id-cmc-encryptedPOP, {
              request {
                certRequest
                  certReqId = 201
                   certTemplate
                     subject = <My DN from my signing cert>
                     publicKey = My Public Key
                     extensions
                       {id-ce-keyUsage, keyEncipherment}

Top      Up      ToC       Page 80 
                   popo
                     keyEncipherment
                     subsequentMessage
              }
              cms
                contentType = id-envelopedData
                content
                  recipientInfos.riid.issuerSerialNumber = <NULL, 201>
                  encryptedContentInfo
                    eContentType = id-data
                    eContent = <Encrypted value of 'y'>
              thePOPAlgID = HMAC-SHA1
              witnessAlgID = SHA-1
              witness <hashed value of 'y'>}}
           {106, id-cmc-dataReturn, <packet of binary data identifying
                                     where the key in question is.>}
     certificates
       Other certificates (optional)
     SignedData.SignerInfos
       Signed by CA

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-transactionId, 10132985123483401}
           {103, id-cmc-senderNonce, 100101}
           {104, id-cmc-dataReturn, <packet of binary data identifying
                                     where the key in question is.>}
           {105, id-cmc-recipientNonce, 10005}
           {107, id-cmc-decryptedPOP, {
             bodyPartID 201,
             thePOPAlgID HMAC-SHA1,
             thePOP <HMAC computed value goes here>}}
         reqSequence
           certRequest
             certReqId = 201
             certTemplate
               subject = <My DN from my signing cert>
               publicKey = My Public Key
               extensions
                 {id-ce-keyUsage, keyEncipherment}
             popo
               keyEncipherment
                 subsequentMessage

Top      Up      ToC       Page 81 
     SignedData.SignerInfos
       SignerInfo
         Signed by requester's signing cert

   Response #2 from server to client:

   ContentInfo.contentType = id-signedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {101, id-cmc-transactionId, 10132985123483401}
           {102, id-cmc-statusInfoV2, {success, 201}}
           {103, id-cmc-senderNonce, 10019}
           {104, id-cmc-recipientNonce, 100101}
           {105, id-cmc-dataReturn, <packet of binary data identifying
                                     where the key in question is.>}
     certificates
       Newly issued certificate
       Other certificates
     SignedData.SignerInfos
       Signed by CA

Appendix C.  Production of Diffie-Hellman Public Key Certification
             Requests

   Part of a certification request is a signature over the request;
   Diffie-Hellman is a key agreement algorithm and cannot be used to
   directly produce the required signature object.  [DH-POP] provides
   two ways to produce the necessary signature value.  This document
   also defines a signature algorithm that does not provide a POP value,
   but can be used to produce the necessary signature value.

C.1.  No-Signature Signature Mechanism

   Key management (encryption/decryption) private keys cannot always be
   used to produce some type of signature value as they can be in a
   decrypt-only device.  Certification requests require that the
   signature field be populated.  This section provides a signature
   algorithm specifically for that purposes.  The following object
   identifier and signature value are used to identify this signature
   type:

      id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}

      NoSignatureValue ::= OCTET STRING

Top      Up      ToC       Page 82 
   The parameters for id-alg-noSignature MUST be present and MUST be
   encoded as NULL.  NoSignatureValue contains the hash of the
   certification request.  It is important to realize that there is no
   security associated with this signature type.  If this signature type
   is on a certification request and the Certification Authority policy
   requires proof-of-possession of the private key, the POP mechanism
   defined in Section 6.7 MUST be used.

Authors' Addresses

   Jim Schaad
   Soaring Hawk Consulting
   PO Box 675
   Gold Bar, WA  98251

   Phone: (425) 785-1031
   EMail: jimsch@nwlink.com


   Michael Myers
   TraceRoute Security, Inc.

   EMail: mmyers@fastq.com

Top      Up      ToC       Page 83 
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.