Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5272

Certificate Management over CMS (CMC)

Pages: 83
Proposed Standard
Errata
Obsoletes:  2797
Updated by:  6402
Part 4 of 4 – Pages 65 to 83
First   Prev   None

Top   ToC   RFC5272 - Page 65   prevText

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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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   ToC   RFC5272 - 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.