idnits 2.17.00 (12 Aug 2021) /tmp/idnits3717/draft-ietf-pkix-2797-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 1) being 162 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([PKCS10], [RFC2119], [PKCS7], [CMS], [SMIMEV3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 357: '...ributes. Unrecognized OIDs MUST result...' RFC 2119 keyword, line 373: '... noSupport MUST be returned for the r...' RFC 2119 keyword, line 494: '... object SHOULD be for the same identi...' RFC 2119 keyword, line 502: '... Servers MUST be able to understand a...' RFC 2119 keyword, line 504: '... bodies. Clients MUST produce a PKCS10...' (100 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 47 has weird spacing: '... and serv...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 17 looks like a reference -- Missing reference section? 'CMS' on line 844 looks like a reference -- Missing reference section? 'PKCS10' on line 47 looks like a reference -- Missing reference section? 'SMIMEV3' on line 48 looks like a reference -- Missing reference section? 'PKCS7' on line 55 looks like a reference -- Missing reference section? 'RFC 2119' on line 66 looks like a reference -- Missing reference section? 'CRMF' on line 177 looks like a reference -- Missing reference section? 'PKIXCERT' on line 542 looks like a reference -- Missing reference section? 'PXIXCERT' on line 611 looks like a reference -- Missing reference section? 'DH-POP' on line 963 looks like a reference -- Missing reference section? 'HMAC' on line 1765 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group J. Schaad 2 Internet Draft Soaring Hawk Consulting 3 M. Myers 4 February 2002 TraceRoute Security 5 Expires: August 2002 X. Liu 6 Cisco 7 J. Weinstein 9 Certificate Management Messages over CMS 11 draft-ietf-pkix-2797-bis-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Comments or suggestions for improvement may be made on the "ietf- 34 pkix" mailing list, or directly to the author. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 This document defines a Certificate Management protocol using CMS 43 (CMC). This protocol addresses two immediate needs within the 44 Internet PKI community: 46 1. The need for an interface to public key certification products 47 and services based on [CMS] and [PKCS10], and 48 2. The need in [SMIMEV3] for a certificate enrollment protocol for 49 DSA-signed certificates with Diffie-Hellman public keys. 51 A small number of additional services are defined to supplement the 52 core certificate request service. 54 Throughout this specification the term CMS is used to refer to both 55 [CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a 56 superset of the PKCS7. In general, the use of PKCS7 in this document 57 is aligned to the Cryptographic Message Syntax [CMS] that provides a 58 superset of the PKCS7 syntax. The term CMC refers to this 60 specification. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 66 this document are to be interpreted as described in [RFC 2119]. 68 1. Protocol Requirements 70 - The protocol is to be based as much as possible on the existing 71 CMS, PKCS#10 and CRMF specifications. 72 - The protocol must support the current industry practice of a 73 PKCS#10 request followed by a PKCS#7 response as a subset of the 74 protocol. 76 - The protocol needs to easily support the multi-key enrollment 77 protocols required by S/MIME and other groups. 78 - The protocol must supply a way of doing all operations in a 79 single-round trip. When this is not possible the number of round 80 trips is to be minimized. 81 - The protocol will be designed such that all key generation can 82 occur on the client. 83 - The mandatory algorithms must superset the required algorithms 84 for S/MIME. 86 - The protocol will contain POP methods. Optional provisions for 87 multiple-round trip POP will be made if necessary. 88 - The protocol will support deferred and pending responses to 89 certificate request for cases where external procedures are required 90 to issue a certificate. 91 - The protocol needs to support arbitrary chains of local 92 registration authorities as intermediaries between certificate 93 requesters and issuers. 95 2. Protocol Overview 97 An enrollment transaction in this specification is generally 98 composed of a single round trip of messages. In the simplest case 99 an enrollment request is sent from the client to the server and an 100 enrollment response is then returned from the server to the client. 101 In some more complicated cases, such as delayed certificate issuance 102 and polling for responses, more than one round trip is required. 104 This specification supports two different request messages and two 105 different response messages. 107 Public key certification requests can be based on either the PKCS10 108 or CRMF object. The two different request messages are (a) the bare 109 PKCS10 (in the event that no other services are needed), and (b) the 110 PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a 111 PKIData object. 113 Public key certification responses are based on the CMS signedData 114 object. The response may be either (a) a degenerate CMS signedData 115 object (in the event no other services are needed), or (b) a 116 ResponseBody object wrapped in a CMS signedData object. 118 No special services are provided for doing either renewal (new 119 certificates with the same key) or re-keying (new certificates on 120 new keys) of clients. Instead a renewal/re-key message looks the 121 same as any enrollment message, with the identity proof being 122 supplied by existing certificates from the CA. 124 A provision exists for Local Registration Authorities (LRAs) to 125 participate in the protocol by taking client enrollment messages, 126 wrapping them in a second layer of enrollment message with 127 additional requirements or statements from the LRA and then passing 128 this new expanded request on to the Certification Authority. 130 This specification makes no assumptions about the underlying 131 transport mechanism. The use of CMS is not meant to imply an email- 132 based transport. 134 Optional services available through this specification are 135 transaction management, replay detection (through nonces), deferred 136 certificate issuance, certificate revocation requests and 137 certificate/CRL retrieval. 139 2.1 Terminology 141 There are several different terms, abbreviations and acronyms used 143 in this document that we define here for convenience and consistency 145 of usage: 147 "End-Entity" (EE) refers to the entity that owns a key pair and for 149 whom a certificate is issued. 151 "LRA" or "RA" refers to a (Local) Registration Authority. A 153 registration authority acts as an intermediary between an End-Entity 155 and a Certification Authority. Multiple RAs can exist between the 157 End-Entity and the Certification Authority. 159 "CA" refers to a Certification Authority. A Certification Authority 161 is the entity that performs the actual issuance of a certificate. 163 "Client" refers to an entity that creates a PKI request. In this 165 document both RAs and End-Entities can be clients. 167 "Server" refers to the entities that process PKI requests and create 169 PKI responses. CAs and RAs can be servers in this document. 171 "PKCS#10" refers the Public Key Cryptography Standard #10. This is 173 one of a set of standards defined by RSA Laboratories in the 1980s. 175 PKCS#10 defines a Certificate Request Message syntax. 177 "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. 179 We are using certificate request message format defined in this 181 document as part of our management protocol. 183 "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This 185 document provides for basic cryptographic services including 187 encryption and signing with and without key management. 189 "POP" is an acronym for "Proof of Possession". POP refers to a 191 value that can be used to prove that the private key corresponding 193 to a public key is in the possession and can be used by an end- 195 entity. 197 "Transport wrapper" refers to the outermost CMS wrapping layer. 199 2.2 Protocol Flow Charts 200 Figure 1 shows the Simple Enrollment Request and Response messages. 202 The contents of these messages are detailed in Sections 4.1 and 4.3 204 below. 206 Simple PKI Request Simple PKI Response 208 ------------------------- -------------------------- 210 +----------+ +------------------+ 212 | PKCS #10 | | CMS "certs-only" | 214 +----------+--------------+ | message | 216 | | +------------------+------+ 218 | Certificate Request | | | 220 | | | CMS Signed Data, | 222 | Subject Name | | no signerInfo | 224 | Subject Public Key Info | | | 226 | (K_PUB) | | signedData contains one | 228 | Attributes | | or more certificates in | 230 | | | the "certificates" | 232 +-----------+-------------+ | portion of the | 234 | signed with | | signedData. | 236 | matching | | | 238 | K_PRIV | | encapsulatedContentInfo | 240 +-------------+ | is empty. | 242 | | 244 +--------------+----------+ 246 | unsigned | 248 +----------+ 250 Figure 1: Simple PKI Request and Response Messages 252 Full PKI Request Full PKI Response 254 ----------------------- ------------------------ 256 +----------------+ +----------------+ 258 | CMS signedData | | CMS signedData | 260 | object | | object | 262 +----------------+--------+ +----------------+--------+ 264 | | | | 266 | PKIData object | | ResponseBody object | 268 | | | | 270 | Sequence of: | | Sequence of: | 272 | * | | * | 274 | *| | * | 276 | * | | * | 278 | * | | | 280 | | | where * == zero or more | 282 | where * == zero or more | | | 284 | | | All certificates issued | 286 | Certificate requests | | as part of the response | 288 | are CRMF or PKCS#10 | | are included in the | 290 | objects. Attributes are | | "certificates" portion | 292 | (OID, ANY defined by | | of the signedData. | 294 | OID) pairs. | | Relevant CA certs and | 296 | | | CRLs can be included as | 298 +-------+-----------------+ | well. | 299 | used may be pre-| +---------+---------------+ 301 | existing or | | signed by the | 303 | identified in | | CA or an LRA | 305 | the request) | +---------------+ 307 +-----------------+ 309 Figure 2: Full PKI Request and Response Messages 311 Figure 2 shows the Full Enrollment Request and Response messages. 313 The contents of these messages are detailed in Sections 4.2 and 4.4 315 below. 317 3. Protocol Elements 319 This section covers each of the different elements that may be used 321 to construct enrollment request and enrollment response messages. 323 Section 4 will cover how to build the enrollment request and 325 response messages. 327 3.1 PKIData Object 329 The new content object PKIData has been defined for this protocol. 331 This new object is used as the body of the full PKI request message. 333 The new body is identified by: 335 id-cct-PKIData ::= {id-pkix id-cct(12) 2 } 337 The ASN.1 structure corresponding to this new content type is: 339 PKIData ::= SEQUENCE { 341 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 343 reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, 345 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 347 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 349 } 351 -- controlSequence consists of a sequence of control attributes. 353 The control attributes defined in this document are found in section 355 5. As control sequences are defined by OIDs, other parties can 357 define additional control attributes. Unrecognized OIDs MUST result 359 in no part of the request being successfully processed. 361 -- reqSequence consists of a sequence of requests. The requests can 363 be a CertificateRequest (PKCS10 request), a CertReqMsg or an 365 externally defined request (orm). Details on the first two request 367 types are found in sections 3.3.1 and 3.3.2 respectively. If an 369 externally defined request message is present, but the server does 371 not understand the request (or will not process it), a CMCStatus of 373 noSupport MUST be returned for the request item and no requests 375 processed. 377 -- cmsSequence consists of a sequence of [CMS] message objects. 379 This protocol uses EnvelopedData, SignedData, EncryptedData and 381 AuthenticatedData. See section 3.6 for more details. 383 -- otherMsgSequence allows for other arbitrary data items to be 385 placed into the enrollment protocol. The {OID, any} pair of values 387 allows for arbitrary definition of material. Data objects are 389 placed here while control objects are placed in the controlSequence 391 field. See section 3.7 for more details. 393 Processing of this object by a recipient is as follows: 395 1. All control attributes should be examined and processed in an 397 appropriate manner. The appropriate processing may be either to do 399 complete processing at this time, ignore the control attribute or to 401 place the control attribute on a to-do list for later processing. 403 2. An implicit control attribute is then processed for each item in 405 the reqSequence. Again this may be either immediate processing or 407 addition to a to-do list for later processing. 409 No processing is required for cmsSequence or otherMsgSequence 411 members of the element. If items are present and are not referenced 413 by a control sequence, they are to be ignored. 415 3.2 ResponseBody Object 417 The new content object ResponseBody has been defined for this 419 protocol. This new object is used as the body of the full PKI 421 response message. The new body is identified by: 423 id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 } 425 The ASN.1 structure corresponding to this body content type is: 427 ResponseBody ::= SEQUENCE { 429 controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 431 cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, 433 otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg 435 } 437 -- controlSequence consists of a sequence of control attributes. 439 The control attributes defined in this document are found in section 441 3.5. Other parties can define additional control attributes. 443 -- cmsSequence consists of a sequence of [CMS] message objects. 445 This protocol only uses EnvelopedData, SignedData, EncryptedData and 447 AuthenticatedData. See section 3.6 for more details. 449 -- otherMsgSequence allows for other arbitrary items to be placed 451 into the enrollment protocol. The {OID, any} pair of values allows 453 for arbitrary definition of material. Data objects are placed here 455 while control objects are placed in the controlSequence field. See 457 section 3.7 for more details. 459 Processing of this object by a recipient is as follows: 461 1. All control attributes should be examined and processed in an 462 complete processing at this time, ignore the control attribute or to 464 place the control attribute on a to-do list for later processing. 466 2. Additional processing of non-element items includes the saving of 468 certificates and CRLs present in wrapping layers. This type of 470 processing is based on the consumer of the element and should not be 472 relied on by generators. 474 No processing is required for cmsSequence or otherMsgSequence 476 members of the element. If items are present and are not referenced 478 by a control sequence, they are to be ignored. 480 3.3 Certification Requests (PKCS10/CRMF) 482 Certification Requests are based on either PKCS10 or CRMF messages. 484 Section 3.3.1 specifies mandatory and optional requirements for 486 clients and servers dealing with PKCS10 request messages. Section 488 3.3.2 specifies mandatory and optional requirements for clients and 490 servers dealing with CRMF request messages. 492 All certificate requests directly encoded into a single PKIData 494 object SHOULD be for the same identity. RAs that batch processing 496 are expected to place the signed PKIData sequences received into the 498 cmsSequence of the PKIData object it generates. 500 3.3.1 PKCS10 Request Body 502 Servers MUST be able to understand and process PKCS10 request 504 bodies. Clients MUST produce a PKCS10 request body when using the 506 Simple Enrollment Request message. Clients MAY produce a PKCS10 508 request body when using the Full Enrollment Request message. 510 When producing a PKCS10 request body, clients MUST produce a PKCS10 512 message body containing a subject name and public key. Some 514 certification products are operated using a central repository of 516 information to assign subject names upon receipt of a public key for 518 certification. To accommodate this mode of operation, the subject 520 name in a CertificationRequest MAY be NULL, but MUST be present. 522 CAs that receive a CertificationRequest with a NULL subject name MAY 524 reject such requests. If rejected and a response is returned, the 526 CA MUST respond with the failInfo attribute of badRequest. 528 The client MAY incorporate one or more standard X.509 v3 extensions 530 in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq 532 attribute is defined as 534 ExtensionReq ::= SEQUENCE OF Extension 536 where Extension is imported from [PKIXCERT] and ExtensionReq is 538 identified by {pkcs-9 14}. 540 Servers MUST be able to process all extensions defined, but not 542 prohibited, in [PKIXCERT]. Servers are not required to be able to 544 process other V3 X.509 extensions transmitted using this protocol, 545 extensions. Servers are not required to put all client-requested 547 extensions into a certificate. Servers are permitted to modify 549 client-requested extensions. Servers MUST NOT alter an extension so 551 as to invalidate the original intent of a client-requested 553 extension. (For example changing key usage from key exchange to 555 signing.) If a certification request is denied due to the inability 557 to handle a requested extension and a response is returned, the 559 server MUST respond with the failInfo attribute of unsupportedExt. 561 3.3.2 CRMF Request Body 563 Servers MUST be able to understand and process CRMF request body. 565 Clients MAY produce a CRMF message body when using the Full 567 Enrollment Request message. 569 This memo imposes the following additional changes on the 571 construction and processing of CRMF messages: 573 - When CRMF message bodies are used in the Full Enrollment Request 575 message, each CRMF message MUST include both the subject and 577 publicKey fields in the CertTemplate. As in the case of PKCS10 579 requests, the subject may be encoded as NULL, but MUST be present. 581 - When both CRMF and CMC controls exist with equivalent 583 functionality, the CMC control SHOULD be used. The CMC control MUST 585 override the CRMF control. 587 - The regInfo field MUST NOT be used on a CRMF message. Equivalent 589 functionality is provided in the regInfo control attribute (section 591 5.12). 593 - The indirect method of proving POP is not supported in this 595 protocol. One of the other methods (including the direct method 597 described in this document) MUST be used instead if POP is desired. 599 The value of encrCert in SubsequentMessage MUST NOT be used. 601 - Since the subject and publicKeyValues are always present, the 603 POPOSigningKeyInput MUST NOT be used when computing the value for 605 POPSigningKey. 607 A server is not required to use all of the values suggested by the 609 client in the certificate template. Servers MUST be able to process 611 all extensions defined, but not prohibited in [PXIXCERT]. Servers 613 are not required to be able to process other V3 X.509 extension 615 transmitted using this protocol, nor are they required to be able to 617 process other, private extensions. Servers are permitted to modify 619 client-requested extensions. Servers MUST NOT alter an extension so 621 as to invalidate the original intent of a client-requested 623 extension. (For example change key usage from key exchange to 625 signing.) If a certificate request is denied due to the inability 627 to handle a requested extension, the server MUST respond with a 629 failInfo attribute of unsupportedExt. 631 3.3.3 Production of Diffie-Hellman Public Key Certification Requests 633 Part of a certification request is a signature over the request; 635 Diffie-Hellman is a key agreement algorithm and cannot be used to 637 directly produce the required signature object. [DH-POP] provides 638 also defines a signature algorithm that does not provide a POP 640 value, but can be used to produce the necessary signature value. 642 3.3.3.1 No-Signature Signature Mechanism 644 Key management (encryption/decryption) private keys cannot always be 646 used to produce some type of signature value as they can be in a 648 decrypt only device. Certification requests require that the 650 signature field be populated. This section provides a signature 652 algorithm specifically for that purposes. The following object 654 identifier and signature value are used to identify this signature 656 type: 658 id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} 660 NoSignatureValue ::= OCTET STRING 662 The parameters for id-alg-noSignature MUST be present and MUST be 664 encoded as NULL. NoSignatureValue contains the hash of the 666 certification request. It is important to realize that there is no 668 security associated with this signature type. If this signature 670 type is on a certification request and the Certification Authority 672 policy requires proof-of-possession of the private key, the POP 674 mechanism defined in section 5.7 MUST be used. 676 3.3.3.2 Diffie-Hellman POP Discrete Logarithm Signature 678 CMC compliant implementations MUST support section 4 of [DH-POP]. 680 3.3.3.3 Diffie-Hellman MAC signature 682 CMC compliant implementations MAY support section 3 of [DH-POP]. 684 3.4 Body Part Identifiers 686 Each element of a PKIData or PKIResponse message has an associated 688 body part identifier. The Body Part Identifier is a 4-octet integer 690 encoded in the certReqIds field for CertReqMsg objects (in a 692 TaggedRequest) or in the bodyPartId field of the other objects. The 694 Body Part Identifier MUST be unique within a single PKIData or 696 PKIResponse object. Body Part Identifiers can be duplicated in 698 different layers (for example a CMC message embedded within 700 another). The Body Part Id of zero is reserved to designate the 702 current PKIData object. This value is used in control attributes 704 such as the Add Extensions Control in the pkiDataReference field to 706 refer to a request in the current PKIData object. 708 Some control attribute, such as the CMC Status Info attribute, will 710 also use Body Part Identifiers to refer to elements in the previous 712 message. This allows an error to be explicit about the attribute or 714 request to which the error applies. 716 3.5 Control Attributes 718 The overall control flow of how a message is processed in this 719 consists of an object identifier and a value based on the object 721 identifier. 723 Servers MUST fail the processing of an entire PKIData message if any 725 included control attribute is not recognized. The response MUST be 727 the error badRequest and bodyList MUST contain the bodyPartID of the 729 invalid or unrecognized control attribute(s). 731 The syntax of a control attribute is 733 TaggedAttribute ::= SEQUENCE { 735 bodyPartID BodyPartId, 737 attrType OBJECT IDENTIFIER, 739 attrValues SET OF AttributeValue 741 } 743 -- bodyPartId is a unique integer that is used to reference this 745 control attribute. The id of 0 is reserved for use as the reference 747 to the current PKIData object. 749 -- attrType is the OID defining the associated data in attrValues 751 -- attrValues contains the set of data values used in processing 753 the control attribute. 755 The set of control attributes that are defined by this memo are 757 found in section 5. 759 3.6 Content Info objects 761 The cmsSequence field of the PKIRequest and PKIResponse messages 763 contains zero or more tagged content info objects. The syntax for 765 this structure is 767 TaggedContentInfo ::= SEQUENCE { 769 bodyPartID BodyPartId, 771 contentInfo ContentInfo 773 } 775 -- bodyPartId is a unique integer that is used to reference this 777 content info object. The id of 0 is reserved for use as the 779 reference to the current PKIData object. 781 -- contentInfo contains a ContentInfo object (defined in [CMS]). 783 The three contents used in this location are SignedData, 785 EnvelopedData and Data. 787 EnvelopedData provides for shrouding of data. Data allows for 789 general transport of unstructured data. 791 The SignedData object from [CMS] is also used in this specification 793 to provide for authentication as well as serving as the general 795 transport wrapper of requests and responses. 797 3.6.1 Signed Data 798 The signedData object is used in two different locations when 800 constructing enrollment messages. The signedData object is used as 802 a wrapper for a PKIData as part of the enrollment request message. 804 The signedData object is also used as the outer part of an 806 enrollment response message. 808 As part of processing a message the signature(s) MUST be verified. 810 If the signature does not verify, and the body contains anything 812 other than a status response, a new message containing a status 814 response MUST be returned using a CMCFailInfo with a value of 816 badMessageCheck and a bodyPart of 0. 818 For the enrollment response the signedData wrapper allows the server 820 to sign the returning data, if any exists, and to carry the 822 certificates and CRLs for the enrollment request. If no data is 824 being returned beyond the certificates, no signerInfo objects are 826 placed in the signedData object. 828 3.6.2 Enveloped Data 830 EnvelopedData is the primary method of providing confidentiality for 832 sensitive information in this protocol. The protocol currently uses 834 EnvelopedData to provide encryption of an entire request (see 836 section 4.5). The envelopedData object would also be used to wrap 838 private key material for key archival. If the decryption on an 840 envelopedData failes, the response is a CMCFailInfo with a value of 842 badMessageCheck and a bodyPart of 0. 844 Servers MUST implement envelopedData according to [CMS]. There is 846 an ambiguity (about encrypting content types other than id-data) in 848 the PKCS7 specification that has lead to non-interoperability. 850 3.6.3 Authenticated Data 852 AuthenticatedData is used for providing origination authentication 854 in those circumstances where a shared-secret exists, but a PKI trust 856 anchor has not yet been established. This is currently only used 858 for the publishAutenticatedData control (section 5.2.16). This 860 control is uses the PKIData body so that new controls with 862 additional policy type information could be included as well. 864 3.7 Other Message Bodies 866 The other message body portion of the message allows for arbitrary 868 data objects to be carried as part of a message. This is intended 870 to contain data that is not already wrapped in a CMS contentInfo 872 object. The data is ignored unless a control attribute references 874 the data by bodyPartId. 876 OtherMsg ::= SEQUENCE { 878 bodyPartID BodyPartID, 880 otherMsgType OBJECT IDENTIFIER, 882 otherMsgValue ANY DEFINED BY otherMsgType } 884 -- bodyPartID contains the unique id of this object 885 -- otherMsgType contains the OID defining both the usage of this 887 body part and the syntax of the value associated with this body part 889 -- otherMsgValue contains the data associated with the message body 891 part. 893 3.8 Unsigned Attributes 895 There is sometimes a need to include data in an enrollment message 897 designed to be removed during processing. An example of this is the 899 inclusion of an encrypted private key, where a key archive agent 901 removes the encrypted private key before sending it on to the CA. 903 One side effect of this desire is the fact that every RA which 905 encapsulates this information needs to move the data so that it is 907 not covered by the RA signature. (A client request, encapsulated by 909 an RA cannot have the unsigned attribute removed by the key archive 911 agent without breaking the RA's signature.) This attribute 913 addresses that problem. 915 This attribute is used to contain the information that is not 917 directly signed by a user. When an RA finds a message that has this 919 attribute in the unsigned or unauthenticated attribute fields of the 921 CMS objects it is aggregating, they are removed from the embedded 923 CMS objects and propagated up to the RA CMS object. 925 id-cmc-UnsignedData OBJECT IDENTIFIER ::= {} 927 CMCUnsignedData ::= SEQUENCE { 929 bodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID, 931 identifier OBJECT IDENTIFIER, 933 content ANY DEFINED BY identifier 935 } 937 There MUST be at most one CMCUnsignedData attribute in the 939 UnsignedAttribute sequence of a SignerInfo structure. If the 941 attribute appears in one SignerInfo in a sequence, it MUST appear 943 the same in all SignerInfo items and MUST have the same value. 945 4. PKI Messages 947 This section discusses the details of putting together the different 949 enrollment request and response messages. 951 4.1 Simple Enrollment Request 953 The simplest form of an enrollment request is a plain PKCS10 955 message. If this form of enrollment request is used for a private 957 key that is capable of generating a signature, the PKCS10 MUST be 959 signed with that private key. If this form of the enrollment 961 request is used for a D-H key, then the D-H POP mechanism described 963 in [DH-POP] MUST be used. 965 Servers MUST support the Simple Enrollment Request message. If the 967 Simple Enrollment Request message is used, servers MUST return the 969 Simple Enrollment Response message (see Section 4.3) if the 970 Full Enrollment Response MAY be returned or no response MAY be 972 returned. 974 The Simple Enrollment Request message MUST NOT be used if a proof- 976 of-identity needs to be included. 978 Many advanced services specified in this memo are not supported by 980 the Simple Enrollment Request message. 982 4.2 Full PKI Request 984 The Full Enrollment Request provides the most functionality and 986 flexibility. Clients SHOULD use the Full Enrollment Request message 988 when enrolling. Servers MUST support the Full Enrollment Request 990 message. An enrollment response (full or simple as appropriate) 992 MUST be returned to all Full Enrollment Requests. 994 The Full Enrollment Request message consists of a PKIData object 996 wrapped in a signedData CMS object. The objects in the PKIData are 998 ordered as follows: 1000 1. All Control Attributes, 1002 2. All certification requests, 1004 3. All CMS objects, 1006 4. All other messages. 1008 Each object in the PKIData sequence is identified by a Body Part 1010 Identifier. If duplicate ids are found, the server MUST return the 1012 error badRequest with a bodyPartID of 0. 1014 The signedData object wrapping the PKIData may be signed either by 1016 the private key material of the signature certification request, or 1018 by a previously certified signature key. If the private key of a 1020 signature certification request is being used, then: 1022 a) the certification request containing the corresponding public key 1024 MUST include a Subject Key Identifier extension, 1026 b) the subjectKeyIdentifier form of signerInfo MUST be used, and 1028 c) the value of the subjectKeyIdentifier form of signerInfo MUST be 1030 the Subject Key Identifier specified in the corresponding 1032 certification request. 1034 (The subjectKeyIdentifier form of signerInfo is used here because no 1036 certificates have yet been issued for the signing key.) If the 1038 request key is used for signing, there MUST be only one signerInfo 1040 object in the signedData object. 1042 When creating a message to renew a certificate, the following should 1044 be taken into consideration: 1046 1. The identification and identityProof control statements are not 1048 required. The same information is provided by the use of an 1050 existing certificate from the CA when signing the enrollment 1052 message. 1054 2. CAs and LRAs may impose additional restrictions on the signing 1056 certificate used. They may require that the most recently issued 1057 3. A renewal message may occur either by creating a new set of keys, 1059 or by re-using an existing set of keys. Some CAs may prevent re-use 1061 of keys by policy. In this case the CA MUST return NOKEYREUSE as 1063 the failure code. 1065 4.3 Simple Enrollment Response 1067 Servers SHOULD use the simple enrollment response message whenever 1069 possible. Clients MUST be able to process the simple enrollment 1071 response message. The simple enrollment response message consists 1073 of a signedData object with no signerInfo objects on it. The 1075 certificates requested are returned in the certificate bag of the 1077 signedData object. 1079 Clients MUST NOT assume the certificates are in any order. Servers 1081 SHOULD include all intermediate certificates needed to form complete 1083 chains to one or more self-signed certificates, not just the newly 1085 issued certificate(s). The server MAY additionally return CRLs in 1087 the CRL bag. Servers MAY include the self-signed certificates. 1089 Clients MUST NOT implicitly trust included self-signed 1091 certificate(s) merely due to its presence in the certificate bag. In 1093 the event clients receive a new self-signed certificate from the 1095 server, clients SHOULD provide a mechanism to enable the user to 1097 explicitly trust the certificate. 1099 4.4 Full PKI Response 1101 Servers MUST return full PKI response messages if a) a full PKI 1103 request message failed or b) additional services other than 1105 returning certificates are required. Servers MAY return full PKI 1107 responses with failure information for simple PKI requests. 1109 Following section 4.3 above, servers returning only certificates and 1111 a success status to the client SHOULD use the simple PKI response 1113 message. 1115 Clients MUST be able to process a full PKI response message. 1117 The full enrollment response message consists of a signedData object 1119 encapsulating a responseBody object. In a responseBody object all 1121 Control Attributes MUST precede all CMS objects. The certificates 1123 granted in an enrollment response are returned in the certificates 1125 field of the immediately encapsulating signedData object. 1127 Clients MUST NOT assume the certificates are in any order. Servers 1129 SHOULD include all intermediate certificates needed to form complete 1131 chains one ore more self-signed certificates, not just the newly 1133 issued certificate(s). The server MAY additionally return CRLs in 1135 the CRL bag. Servers MAY include the self-signed certificates. 1137 Clients MUST NOT implicitly trust included self-signed 1139 certificate(s) merely due to its presence in the certificate bag. In 1141 the event clients receive a new self-signed certificate from the 1143 server, clients SHOULD provide a mechanism to enable the user to 1145 explicitly trust the certificate. 1147 4.5 Application of Encryption to a PKI Message 1148 There are occasions where a PKI request or response message must be 1150 encrypted in order to prevent any information about the enrollment 1152 from being accessible to unauthorized entities. This section 1154 describes the means used to encrypt a PKI message. This section is 1156 not applicable to a simple enrollment message. 1158 Confidentiality is provided by wrapping the PKI message (a 1160 signedData object) in a CMS EnvelopedData object. The nested 1162 content type in the EnvelopedData is id-signedData. Note that this 1164 is different from S/MIME where there is a MIME layer placed between 1166 the encrypted and signed data objects. It is recommended that if an 1168 enveloped data layer is applied to a PKI message, a second signing 1170 layer be placed outside of the enveloped data layer. The following 1172 figure shows how this nesting would be done: 1174 Normal Option 1 Option 2 1176 ------ -------- -------- 1178 SignedData EnvelopedData SignedData 1180 PKIData SignedData EnvelopedData 1182 PKIData SignedData 1184 PKIData 1186 Options 1 and 2 provide the benefit of preventing leakage of 1188 sensitive data by encrypting the information. LRAs can remove the 1190 enveloped data wrapping, and replace or forward without further 1192 processing. Section 6 contains more information about LRA 1194 processing. 1196 PKI Messages MAY be encrypted or transmitted in the clear. Servers 1198 MUST provided support for all three versions. 1200 Alternatively, an authenticated, secure channel could exist between 1202 the parties requiring encryption. Clients and servers MAY use such 1204 channels instead of the technique described above to provide secure, 1206 private communication of PKI request and response messages. 1208 5. Control Attributes 1210 Control attributes are carried as part of both PKI requests and 1212 responses. Each control attribute is encoded as a unique Object 1214 Identifier followed by that data for the control attribute. The 1216 encoding of the data is based on the control attribute object 1218 identifier. Processing systems would first detect the OID and 1220 process the corresponding attribute value prior to processing the 1222 message body. 1224 The following table lists the names, OID and syntactic structure for 1226 each of the control attributes documented in this memo. 1228 Control Attribute OID Syntax 1230 ----------------- ---------- -------------- 1232 cMCStatusInfo id-cmc 1 CMCStatusInfo 1234 identification id-cmc 2 UTF8String 1236 identityProof id-cmc 3 OCTET STRING 1237 transactionId id-cmc 5 INTEGER 1239 senderNonce id-cmc 6 OCTET STRING 1241 recipientNonce id-cmc 7 OCTET STRING 1243 addExtensions id-cmc 8 AddExtensions 1245 encryptedPOP id-cmc 9 EncryptedPOP 1247 decryptedPOP id-cmc 10 DecryptedPOP 1249 lraPOPWitness id-cmc 11 LraPOPWitness 1251 getCert id-cmc 15 GetCert 1253 getCRL id-cmc 16 GetCRL 1255 revokeRequest id-cmc 17 RevokeRequest 1257 regInfo id-cmc 18 OCTET STRING 1259 responseInfo id-cmc 19 OCTET STRING 1261 QueryPending id-cmc 21 OCTET STRING 1263 idPOPLinkRandom id-cmc 22 OCTET STRING 1265 idPOPLinkWitness id-cmc 23 OCTET STRING 1267 idConfirmCertAcceptance id-cmc 24 CMCCertId 1269 cmcStatusInfoExt id-cmc XX CMCStatusInfoExt 1271 publishTrustRoot id-cmc XX CertificateSequence 1273 publishAuthenticatedData id-cmc XX AuthPublish 1275 batchRequests id-cmc XX BodyPartList 1277 batchResponses id-cmc XX BodyPartList 1279 5.1 CMC Status Info Control Attributes 1281 The CMC status info control is used in full PKI Response messages to 1283 return information about the processing of a client request. Two 1285 controls are described in this section. The first is the preferred 1287 control, the second is included for backwards compatibility with RFC 1289 2797. 1291 Servers MAY emit multiple CMC status info controls referring to a 1293 single body part. Clients MUST be able to deal with multiple CMC 1295 status info controls in a response message. Servers MUST use the 1297 CMCStatusInfoExt control, but MAY additionally use the CMCStatusInfo 1299 attribute. Clients MUST be able to process the CMCStatusInfoExt 1301 control. 1303 5.1.1 Extended CMC Status Info Control Attribute 1305 This control uses the following ASN.1 definition: 1307 CMCStatusInfoExt ::= SEQUENCE { 1309 CMCStatus CMCStatus, 1311 BodyList SEQUENCE SIZE (1..MAX) OF 1313 BodyPartReference, 1315 StatusString UTF8String OPTIONAL, 1317 OtherInfo CHOICE { 1319 FailInfo CMCFailInfo, 1321 PendInfo PendInfo, 1323 ExtendedFailInfo SEQUENCE { 1325 FailInfoOID OBJECT IDENTIFIER, 1327 FailInfoValue AttributeValue 1329 } 1331 } 1333 } 1334 BodyPartReference ::= CHOICE { 1336 BodyPartID BodyPartID, 1338 BodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID 1340 } 1342 PendInfo ::= SEQUENCE { 1344 pendToken OCTET STRING, 1346 pendTime GeneralizedTime 1348 } 1350 -- cMCStatus is described in section 5.1.3 1352 -- bodyList contains the list of references to body parts in the 1354 request message to which this status information applies. If an 1356 error is being returned for a simple enrollment message, body list 1358 will contain a single integer of value '1'. 1360 -- statusString contains a string with additional description 1362 information. This string is human readable. 1364 -- failInfo is described in section 5.1.4. It provides a detailed 1366 error on what the failure was. This choice is present only if 1368 cMCStatus is failed. 1370 -- extendedFailInfo is provided for other users of the enrollment 1372 protocol to provided their own error codes. This choice is present 1374 only if cMCStatus is failed. Caution should be used in defining new 1376 values as they may not be correctly recognized by all clients and 1378 servers. The failInfo value of internalCA error may be assumed if 1380 the extended error is not recognized. 1382 -- pendToken is the token to be used in the queryPending control 1384 attribute. 1386 -- pendTime contains the suggested time the server wants to be 1388 queried about the status of the request. 1390 If the cMCStatus field is success, the CMC Status Info Control MAY 1392 be omitted unless it is only item in the response message. If no 1394 status exists for a certificate request or other item requiring 1396 processing, then the value of success is to be assumed. 1398 5.1.2 CMC Status Info Control Attribute 1400 The CMC status info control is used in full PKI Response messages to 1402 return information on a client request. Servers MAY emit multiple 1404 CMC status info controls referring to a single body part. Clients 1406 MUST be able to deal with multiple CMC status info controls in a 1408 response message. This statement uses the following ASN.1 1410 definition: 1412 CMCStatusInfo ::= SEQUENCE { 1414 cMCStatus CMCStatus, 1416 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, 1418 statusString UTF8String OPTIONAL, 1419 failInfo CMCFailInfo, 1421 pendInfo PendInfo } OPTIONAL 1423 } 1425 -- cMCStatus is described in section 5.1.3 1427 -- bodyList contains the list of body parts in the request 1429 message to which this status information applies. If an error is 1431 being returned for a simple enrollment message, body list will 1433 contain a single integer of value '1'. 1435 -- statusString contains a string with additional description 1437 information. This string is human readable. 1439 -- failInfo is described in section 5.1.4. It provides a detailed 1441 error on what the failure was. This choice is present only if 1443 cMCStatus is failed. 1445 If the cMCStatus field is success, the CMC Status Info Control MAY 1447 be omitted unless it is only item in the response message. If no 1449 status exists for a certificate request or other item requiring 1451 processing, then the value of success is to be assumed. 1453 5.1.3 CMCStatus values 1455 CMCStatus is a field in the CMCStatusInfo structure. This field 1457 contains a code representing the success or failure of a specific 1459 operation. CMCStatus has the ASN.1 structure of: 1461 CMCStatus ::= INTEGER { 1463 success (0), 1465 -- request was granted 1467 -- reserved (1), 1469 -- not used, defined where the original structure was 1471 defined 1473 failed (2), 1475 -- you don't get what you want, more information elsewhere 1477 in the message 1479 pending (3), 1481 -- the request body part has not yet been processed, 1483 -- requester is responsible to poll back on this 1485 -- pending may only be return for certificate request 1487 operations. 1489 noSupport (4), 1491 -- the requested operation is not supported 1493 confirmRequired (5) 1495 -- conformation using the idConfirmCertAcceptance control is 1497 required 1499 -- before use of certificate 1501 } 1503 5.1.4 CMCFailInfo 1505 CMCFailInfo conveys information relevant to the interpretation of a 1507 failure condition. The CMCFailInfo has the following ASN.1 1508 CMCFailInfo ::= INTEGER { 1510 badAlg (0) 1512 -- Unrecognized or unsupported algorithm 1514 badMessageCheck (1) 1516 -- integrity check failed 1518 badRequest (2) 1520 -- transaction not permitted or supported 1522 badTime (3) 1524 -- Message time field was not sufficiently close to the 1526 system time 1528 badCertId (4) 1530 -- No certificate could be identified matching the provided 1532 criteria 1534 unsuportedExt (5) 1536 -- A requested X.509 extension is not supported by the 1538 recipient CA. 1540 mustArchiveKeys (6) 1542 -- Private key material must be supplied 1544 badIdentity (7) 1546 -- Identification Attribute failed to verify 1548 popRequired (8) 1550 -- Server requires a POP proof before issuing certificate 1552 popFailed (9) 1554 -- POP processing failed 1556 noKeyReuse (10) 1558 -- Server policy does not allow key re-use 1560 internalCAError (11) 1562 tryLater (12) 1564 } 1566 Additional failure reasons MAY be defined for closed environments 1568 with a need. 1570 5.2 Identification and IdentityProof Control Attributes 1572 Some CAs and LRAs require that a proof of identity be included in a 1574 certification request. Many different ways of doing this exist with 1576 different degrees of security and reliability. Most people are 1578 familiar with the request of a bank to provide your mother's maiden 1580 name as a form of identity proof. 1582 CMC provides one method of proving the client's identity based on a 1584 shared secret between the certificate requestor and the verifying 1586 authority. If clients support full request messages, clients MUST 1588 implement this method of identity proof. Servers MUST provide this 1590 method and MAY also have a bilateral method of similar strength 1592 available. 1594 The CMC method starts with an out-of-band transfer of a token (the 1596 shared secret). The shared-secret should be generated in a random 1598 manner. The distribution of this token is beyond the scope of this 1600 document. The client then uses this token for an identity proof as 1602 follows: 1604 1. The reqSequence field of the PKIData object (encoded exactly as 1606 it appears in the request message including the sequence type and 1608 length) is the value to be validated. 1610 2. A SHA1 hash of the token is computed. 1612 3. An HMAC-SHA1 value is then computed over the value produced in 1614 Step 1, as described in [HMAC], using the hash of the token from 1616 Step 2 as the shared secret value. 1618 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the 1620 value of the identityProof attribute. 1622 When the server verifies the identityProof attribute, it computes 1624 the HMAC-SHA1 value in the same way and compares it to the 1626 identityProof attribute contained in the enrollment request. 1628 If a server fails the verification of an identityProof attribute and 1630 the server returns a response message, the failInfo attribute MUST 1632 be present in the response and MUST have a value of badIdentity. 1634 Reuse of the shared-secret on enrollment retries makes it easier for 1636 the client and to prevent getting out of sync. However, reuse of 1638 the shared-secret can potentially open the door for some types of 1640 attacks. 1642 Optionally, servers MAY require the inclusion of the unprotected 1644 identification attribute with an identification attribute. The 1646 identification attribute is intended to contain either a text string 1648 or a numeric quantity, such as a random number, which assists the 1650 server in locating the shared secret needed to validate the contents 1652 of the identityProof attribute. Numeric values MUST be converted to 1654 text string representations prior to encoding as UTF8-STRINGs in 1656 this attribute. If the identification control attribute is included 1658 in the message, the derivation of the shared secret in step 2 is 1660 altered so that the hash of the concatenation of the token and the 1662 identity value are hashed rather than just the token. 1664 5.2.1 Hardware Shared Secret Token Generation 1666 The shared secret between the end-entity and the identity verify is 1668 sometimes transferred using a hardware device that generates a 1670 series of tokens based on some shared secret value. The user can 1672 therefore prove their identity by transferring this token in plain 1674 text along with a name string. The above protocol can be used with 1676 a hardware shared-secret token generation device by the following 1678 modifications: 1680 1. The identification attribute MUST be included and MUST contain 1682 the hardware-generated token. 1684 2. The shared secret value used above is the same hardware-generated 1686 token. 1688 3. All certification requests MUST have a subject name and the 1690 subject name MUST contain the fields required to identify the holder 1692 of the hardware token device. 1694 5.3 Linking Identity and POP Information 1696 In a PKI Full Request message identity information about the 1697 SignedData object containing all of the certificate requests. Proof- 1699 of-possession information for key pairs requesting certification, 1701 however, is carried separately for each PKCS#10 or CRMF message. 1703 (For keys capable of generating a digital signature, the POP is 1705 provided by the signature on the PKCS#10 or CRMF request. For 1707 encryption-only keys the controls described in Section 5.7 below are 1709 used.) In order to prevent substitution-style attacks we must 1711 guarantee that the same entity generated both the POP and proof-of- 1713 identity information. 1715 This section describes two mechanisms for linking identity and POP 1717 information: witness values cryptographically derived from the 1719 shared-secret (Section 5.3.1) and shared-secret/subject DN matching 1721 (Section 5.3.2). Clients and servers MUST support the witness value 1723 technique. Clients and servers MAY support shared-secret/subject DN 1725 matching or other bilateral techniques of similar strength. The 1727 idea behind both mechanisms is to force the client to sign some data 1729 into each certificate request that can be directly associated with 1731 the shared-secret; this will defeat attempts to include certificate 1733 requests from different entities in a single Full PKI Request 1735 message. 1737 5.3.1 Witness values derived from the shared-secret 1739 The first technique for doing identity-POP linking works by forcing 1741 the client to include a piece of information cryptographically- 1743 derived from the shared-secret token as a signed extension within 1745 each certificate request (PKCS#10 or CRMF) message. This technique 1747 is useful if null subject DNs are used (because, for example, the 1749 server can generate the subject DN for the certificate based only on 1751 the shared secret). Processing begins when the client receives the 1753 shared-secret token out-of-band from the server. The client then 1755 computes the following values: 1757 1. The client generates a random byte-string, R, which SHOULD be at 1759 least 512 bits in length. 1761 2. A SHA1 hash of the token is computed. 1763 3. An HMAC-SHA1 value is then computed over the random value 1765 produced in Step 1, as described in [HMAC], using the hash of the 1767 token from Step 2 as the shared secret. 1769 4. The random value produced in Step 1 is encoded as the value of an 1771 idPOPLinkRandom control attribute. This control attribute MUST be 1773 included in the Full PKI Request message. 1775 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value 1777 of an idPOPLinkWitness extension to the certificate request. 1779 a. For CRMF, idPOPLinkWitness is included in the controls section 1781 of the CertRequest structure. 1783 b. For PKCS#10, idPOPLinkWitness is included in the attributes 1785 section of the CertificationRequest structure. 1787 Upon receipt, servers MUST verify that each certificate request 1789 contains a copy of the idPOPLinkWitness and that its value was 1791 derived in the specified manner from the shared secret and the