idnits 2.17.1 draft-ietf-pkix-cmp-transport-protocols-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4210, but the abstract doesn't seem to directly say this. It does mention RFC4210 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 19, 2011) is 4754 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 618 -- Looks like a reference, but probably isn't: '2' on line 619 -- Looks like a reference, but probably isn't: '4' on line 620 -- Looks like a reference, but probably isn't: '6' on line 621 -- Looks like a reference, but probably isn't: '7' on line 622 -- Looks like a reference, but probably isn't: '9' on line 624 -- Looks like a reference, but probably isn't: '11' on line 625 -- Looks like a reference, but probably isn't: '13' on line 626 -- Looks like a reference, but probably isn't: '15' on line 627 -- Looks like a reference, but probably isn't: '16' on line 628 -- Looks like a reference, but probably isn't: '17' on line 629 -- Looks like a reference, but probably isn't: '18' on line 630 -- Looks like a reference, but probably isn't: '20' on line 631 -- Looks like a reference, but probably isn't: '21' on line 632 -- Looks like a reference, but probably isn't: '23' on line 654 -- Looks like a reference, but probably isn't: '24' on line 634 -- Looks like a reference, but probably isn't: '25' on line 635 -- Looks like a reference, but probably isn't: '1' on line 645 -- Looks like a reference, but probably isn't: '3' on line 646 -- Looks like a reference, but probably isn't: '5' on line 647 -- Looks like a reference, but probably isn't: '8' on line 648 -- Looks like a reference, but probably isn't: '10' on line 649 -- Looks like a reference, but probably isn't: '12' on line 650 -- Looks like a reference, but probably isn't: '14' on line 651 -- Looks like a reference, but probably isn't: '19' on line 652 -- Looks like a reference, but probably isn't: '22' on line 653 -- Looks like a reference, but probably isn't: '26' on line 655 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2482 (Obsoleted by RFC 6082) -- Obsolete informational reference (is this intentional?): RFC 2510 (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Kause 3 Internet-Draft SSH 4 Updates: 4210 (if approved) M. Peylo 5 Intended status: Standards Track NSN 6 Expires: October 21, 2011 April 19, 2011 8 Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP 9 draft-ietf-pkix-cmp-transport-protocols-11.txt 11 Abstract 13 This document describes how to layer the Certificate Management 14 Protocol over various transport protocols. It is the "CMPtrans" 15 document referenced in RFC 4210 and therefore updates the reference 16 given therein. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 21, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. HTTP Versions . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Persistent Connections . . . . . . . . . . . . . . . . . . 6 69 3.3. General Form . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.5. Communication Workflow . . . . . . . . . . . . . . . . . . 7 72 3.6. HTTP Request-URI . . . . . . . . . . . . . . . . . . . . . 7 73 3.7. Announcements . . . . . . . . . . . . . . . . . . . . . . 8 74 3.7.1. Pushing of Announcements . . . . . . . . . . . . . . . 8 75 3.7.2. Polling of Announcements . . . . . . . . . . . . . . . 9 76 3.7.2.1. CA Key Update Announcement . . . . . . . . . . . . 9 77 3.7.2.2. Revocation Announcement . . . . . . . . . . . . . 10 78 3.7.2.3. CRL Announcement . . . . . . . . . . . . . . . . . 10 79 3.8. HTTP Considerations . . . . . . . . . . . . . . . . . . . 11 80 3.9. Compatibility Issues with Legacy Implementations . . . . . 11 81 4. TCP-Based Management Protocol . . . . . . . . . . . . . . . . 12 82 4.1. General Form . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.2. Version . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.2.1. Version Negotiation . . . . . . . . . . . . . . . . . 13 85 4.2.2. Detection and Interoperation with RFC2510 86 Conformant Implementations . . . . . . . . . . . . . . 14 87 4.3. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.3.1. Connection Close Flag . . . . . . . . . . . . . . . . 14 89 4.4. Message-Types . . . . . . . . . . . . . . . . . . . . . . 15 90 4.4.1. pkiReq . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.4.2. pkiRep . . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.4.3. pollReq . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.4.4. pollRep . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.4.5. finRep . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.4.6. errorMsgRep . . . . . . . . . . . . . . . . . . . . . 17 96 4.4.6.1. VersionNotSupported . . . . . . . . . . . . . . . 18 97 4.4.6.2. GeneralClientError . . . . . . . . . . . . . . . . 19 98 4.4.6.3. InvalidMessageType . . . . . . . . . . . . . . . . 19 99 4.4.6.4. InvalidPollID . . . . . . . . . . . . . . . . . . 20 100 4.4.6.5. GeneralServerError . . . . . . . . . . . . . . . . 20 101 5. File-Based Protocol . . . . . . . . . . . . . . . . . . . . . 21 102 6. Mail-Based Protocol . . . . . . . . . . . . . . . . . . . . . 22 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 104 8. Information Security Considerations . . . . . . . . . . . . . 24 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 108 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 109 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 110 Appendix B. Registration of the application/pkixcmp Media Type . 28 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 113 1. Introduction 115 The Certificate Management Protocol (CMP) [RFC4210] requires well 116 defined transport mechanisms to enable End Entities, RAs and CAs to 117 pass PKIMessage sequences between them. This document defines the 118 transport mechanisms which were removed from the main CMP 119 specification with the second release and referred to be in a 120 separate document. 122 The first version of the CMP specification [RFC2510] included a brief 123 description of a simple TCP-based transport protocol. Its features 124 are simple transport level error-handling and a mechanism to poll for 125 outstanding PKI messages. Additionally, it was mentioned that PKI 126 messages could also be conveyed using file-, E-mail- and HTTP-based 127 transport. 129 The current version of the CMP specification incorporated an own 130 polling mechanism and thus the need for a transport protocol 131 providing this functionality vanished. The remaining features CMP 132 requires from its transport protocols are connection- and error- 133 handling. 135 During the long time it existed as draft, this RFC was undergoing 136 drastic changes. The TCP-based transport specification was enhanced 137 and a TCP-Messages-over-HTTP transport specification appeared. Both 138 proved to be needless and cumbersome, implementers preferred to use 139 plain HTTP transport. This specification now aims to reflect that. 141 HTTP transport is generally easy to implement, traverses network 142 borders utilizing ubiquitous proxies and is already commonly found in 143 existing implementations. TCP-based transport is only documented for 144 information and optional downward compatibility. E-Mail or file 145 transfer are also mentioned and may be used to convey PKIMessage 146 sequences - provided that scenarios are identified where they are 147 better suited than HTTP. 149 2. Requirements 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. HTTP-Based Protocol 157 For direct interaction between two entities, where a reliable 158 transport protocol like TCP is available, HTTP SHOULD be utilized for 159 conveying CMP messages. 161 With its status codes, HTTP provides needed error reporting 162 capabilities. General problems on the server side as well as those 163 directly caused by the respective request can be reported to the 164 client. 166 As CMP implements a transaction ID, identifying transactions 167 consisting of more than just a single request/response pair, the 168 statelessness of HTTP is not blocking its usage as transport protocol 169 for CMP messages. 171 3.1. HTTP Versions 173 Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] 174 MAY be used. Naturally, the newer version should be preferred. To 175 support legacy implementations, both server and client MUST be able 176 to interact with counterparts utilizing the other HTTP protocol 177 version. 179 3.2. Persistent Connections 181 HTTP permits to reuse a connection for subsequent requests. 182 Implementations may use this functionality for messages within the 183 same transaction but MUST NOT rely on that, as e.g. intermediate HTTP 184 proxies might terminate the connection after each request/response 185 pair. 187 In contrast to HTTP/1.1, persistent connections are explicitly 188 negotiated in HTTP/1.0. To avoid the problems described in chapter 189 19.6.2 in [RFC2616], HTTP/1.0 implementations must not send Keep- 190 Alive when talking to proxies. 192 3.3. General Form 194 An ASN.1 DER-encoded PKIMessage is sent as the entity-body of an HTTP 195 POST request. If this HTTP request is successful, the server returns 196 the CMP reply in the body of the HTTP response. The response status 197 code in this case MUST be 200; other 2xx codes MUST NOT be used for 198 this purpose. The HTTP responses with empty message body to CMP 199 Announcement messages also utilize the status codes 201 and 202 to 200 identify if the information was properly processed. 202 Note that a server may return any 1xx, 3xx, 4xx, or 5xx status code 203 if the HTTP request needs further handling or is otherwise not 204 acceptable. 206 3.4. Media Type 208 The Internet Media Type "application/pkixcmp" MUST be set in the HTTP 209 header when conveying a PKIMessage. 211 3.5. Communication Workflow 213 In CMP most communication is initiated by the end entities where 214 every CMP request triggers a CMP response message from the CA or RA. 216 The CMP Announcement messages described in Section 3.7 are an 217 exception. Their creation may be triggered by events or generated on 218 a regular basis by a CA. The recipient of the Announcement only 219 replies with an HTTP status code acknowledging the receipt or 220 indicating an error but not with a CMP response. 222 The receipt of every HTTP message is confirmed by the counterpart 223 using HTTP means or it MUST be assumed by the sender that it was not 224 successfully delivered to its destination. 226 3.6. HTTP Request-URI 228 The Request-URI is formed as specified in [RFC3986]. 230 Client requests containing a PKI message MUST be directed to an 231 Request-URI depicting a directory. A server implementation MUST 232 handle Request-URIs with or without a trailing slash as identical. 233 The following list contains all such CMP message types. The prefixed 234 numbers reflect ASN.1 numbering of the respective element. 236 [0] Initialization Request 237 [2] Certification Request 238 [4] PKCS-10 Request 239 [6] pop Response 240 [7] Key Update Request 241 [9] Key Recovery Request 242 [11] Revocation Request 243 [13] Cross-Certification Request 244 [15] CA Key Update Announcement 245 [16] Certificate Announcement 246 [17] Revocation Announcement 247 [18] CRL Announcement 248 [20] Nested Message 250 [21] General Message 251 [23] Error Message 252 [24] Certificate Confirmation 253 [25] Polling Request 255 An example of a Request-Line and a Host header field in an HTTP/1.1 256 header, sending a CMP request to a server, located in the "/cmp" 257 directory of the host example.com, would be 259 POST /cmp HTTP/1.1 260 Host: example.com 262 or in the absoluteURI form 264 POST http://example.com/cmp/ HTTP/1.1 265 Host: example.com 267 A CMP server may be logically located either inside the root- or 268 within subdirectories of an HTTP server. As default, the path should 269 end in a "cmp" directory. 271 3.7. Announcements 273 A CMP server may create event-triggered announcements or generate 274 them on a regular basis. It MAY also utilize HTTP transport to 275 convey them to a suitable recipient. They can either be pushed to 276 the recipient or polled from the HTTP CMP server. 278 3.7.1. Pushing of Announcements 280 The ASN.1 encoded structures are sent as the entity-body of an HTTP 281 POST request. 283 Suitable recipients for CMP announcements might e.g. be repositories 284 storing the announced information such as directory services. Those 285 listen for incoming messages, utilizing the same HTTP Request-URI 286 scheme as defined in Section 3.6. 288 The following PKIMessages are announcements that may be pushed by a 289 CA. The prefixed numbers reflect ASN.1 numbering of the respective 290 element. 292 [15] CA Key Update Announcement 293 [16] Certificate Announcement 294 [17] Revocation Announcement 295 [18] CRL Announcement 297 CMP announcement messages do not require any CMP response. However, 298 the recipient MUST acknowledge receipt with a HTTP message having an 299 appropriate status code and an empty body. The sending side should 300 assume the delivery unsuccessful without such reply and retry if 301 applicable after waiting for an appropriate time span. 303 If the announced issue was successfully stored in a database or was 304 already present, the answer MUST be an HTTP message with a "201 305 Created" status code and empty message body. 307 In case the announced issue was only stored for further processing, 308 the status code of the returned HTTP message must be "202 Accepted". 309 After an appropriate delay, the server may then try to send the 310 Announcement again and may repeat this until it receives a 311 confirmation that it had been successfully stored. The appropriate 312 duration of the delay and the option to increase it between 313 consecutive attempts should be carefully considered. 315 A receiver MUST answer with a suitable 4xx or 5xx HTTP error code 316 when a problem occurs. 318 3.7.2. Polling of Announcements 320 As an OPTIONAL feature a CA may provide CA Key Update Announcement, 321 Revocation Announcement and CRL Announcement messages for polling 322 using HTTP GET requests. 324 The server replies with the requested Announcement as the body of a 325 HTTP response having a 200 status code. If no suitable announcement 326 message is available, an HTTP "404 Not Found" error code MUST be 327 returned. 329 Query components are formed according to [RFC3986]. Their start is 330 indicated by the first question mark in the Request-URI and they are 331 containing "key=value" pairs. Hexadecimal representations of ASN.1 332 strings used as value MAY contain lower or upper case letters and are 333 neither grouped nor prefixed. 335 The given examples are for a self-signed certificate with the common 336 name (OID 2.5.4.3) "Example CA", the keyIdentifier in hexadecimal 337 representation BE911E711EDB685BF94D9B176A1BC715CE51D794 and the 338 serial number 008F8B7E383D88327C. 340 3.7.2.1. CA Key Update Announcement 342 When updating its key pair, a CA can produce a CA Key Update 343 Announcement Message that can be made available to the relevant end 344 entities. This is described as "Root CA Key Update" in E.4 of 345 [RFC4210]. 347 A CMP server may provide this message via an HTTP GET request for the 348 CAKeyUpdAnn.PKI file in the respective server's path. The 349 identification of the old key in question is created according to the 350 Authority Key Identifier as defined in chapter 4.2.1.1 of [RFC5280]. 351 The query component then cosists of one single "key=value" pair, 352 having the string "AuthorityKeyIdentifier" as key, and the 353 hexadecimal representation of the ASN.1 AuthorityKeyIdentifier 354 sequence as value. 356 An example of the query component, when requesting a CA Key Update 357 Announcement Message for an old key identified with the 358 AuthorityKeyIdentifier 303C8014BE911E711EDB685BF94D9B176A1BC715CE51D7 359 94A119A4173015311330110603550403130A4578616D706C652043418209008F8B7E3 360 83D88327C 362 ?AuthorityKeyIdentifier=303C8014BE911E711EDB685BF94D9B176A1BC715CE 363 51D794A119A4173015311330110603550403130A4578616D706C65204341820900 364 8F8B7E383D88327C 366 3.7.2.2. Revocation Announcement 368 A CMP server MAY permit subjects to poll for a Revocation 369 Announcement using HTTP means. This enables a subject to determine 370 if its certificate is about to be (or has been) revoked. 372 The Request-URI of the HTTP GET targets the RevAnn.PKI file in the 373 respective server's path. The query component contains two 374 "key=value" pairs identifying the certificate in question: 375 o an "issuer" key with the hexadecimal representation of the 376 certificate's issuer's GeneralNames ASN.1 sequence as value 377 o a "serialNumber" key with the hexadecimal representation of the 378 certificate's serial number 380 An example of the query component, when requesting a Revocation 381 Announcement of a certificate issued by "Example CA" having the 382 decimal serialNumber 6699 would be: 384 ?issuer=3015311330110603550403130A4578616D706C65204341& 385 serialNumber=1A2B 387 3.7.2.3. CRL Announcement 389 A CMP server MAY offer the possibility to poll for the latest CRL 390 Announcement of a specific CA. 392 The Request-URI targets the CRLAnn.PKI file. The query component 393 consists of one one "key=value" pair containing an "issuer" key with 394 the hexadecimal representation of the CA's GeneralNames' ASN.1 395 sequence as value. 397 An example of a Request-URI for the latest CRL Announcement of 398 "Example CA" from a CMP server located in the "/cmp" directory of the 399 host example.com would be 401 http://example.com/cmp/ 402 CRLAnn.PKI?issuer=3015311330110603550403130A4578616D706C65204341 404 3.8. HTTP Considerations 406 In general, CMP messages are not cachable; requests and responses 407 MUST include a "Cache-Control: no-cache" (and, if either side uses 408 HTTP/1.0, a "Pragma: no-cache") to prevent the client from getting 409 cached responses. 411 Connection management is based on the HTTP provided mechanisms 412 (Connection and Proxy-Connection header fields). 414 While an implementation MAY make use of all defined features of the 415 HTTP protocol, it SHOULD keep the protocol utilization as simple as 416 possible. 418 There is no need for the clients to send an Expect request-header 419 field with the "100-continue" expectation and wait for a 100 420 (Continue) status as described in chapter 8.2.3 of [RFC2616]. The 421 CMP payload sent by a client is relatively small, so having extra 422 messages exchanged is more inefficient as the server will anyway only 423 seldomly reject the message without looking at the body. 425 Content codings MAY be applied. 427 3.9. Compatibility Issues with Legacy Implementations 429 As this document was subject of multiple changes during the long 430 period of time it was created in, implementations using a different 431 approach for HTTP transport may exist. While only those 432 implementations according to this specification are compliant, 433 implementers should to be aware that there might be existing ones 434 which behave differently. 436 Legacy implementations might also use an unregistered "application/ 437 pkixcmp-poll" MIME type as it was specified in earlier drafts of this 438 document. Here, the entity-body of an HTTP POST request contains a 439 TCP-Message instead of a plain DER-encoded PKIMessage. Effectively, 440 this is conveying PKIMessage over TCP-Message over HTTP. 442 4. TCP-Based Management Protocol 444 The so-called "TCP-based transport" is OPTIONAL and its use is 445 deprecated. Its description appears here only for information and 446 downward compatibility. HTTP-based transport, as described in 447 Section 3, should be preferred when transporting CMP messages as 448 defined in [RFC4210]. The reasoning for that is given in Section 1. 450 While this section is called TCP-based and the messages are called 451 TCP-Messages, the same protocol can be used over any reliable, 452 connection oriented transport protocol (e.g. SNA, DECnet, etc.). 453 This protocol is suitable for cases where an end entity (or an RA) 454 initiates a transaction and can poll to pick up the results. 456 The client sends a TCP-Message to the server, and the server responds 457 with another TCP-Message. A response MUST be sent for every request, 458 even if the encapsulated CMP message in the request does not have a 459 corresponding response. 461 The protocol requires a listener process on an RA or CA which can 462 accept TCP-Messages on a well-defined port (default TCP port number 463 is 829). Typically a client initiates the connection to the server 464 and instantly submits a TCP-Message. The server replies with a TCP- 465 Message containing either a CMP message or a reference number to be 466 used later when polling for the actual CMP response message. 468 If a polling-reference was supplied, the client SHOULD send a polling 469 request using this polling-reference after waiting for at least the 470 time specified along with the reference number. The server may again 471 reply with a new polling-reference or with the actual CMP message 472 response. 474 When the final CMP response message has been picked up by the client, 475 no new polling reference is supplied. 477 4.1. General Form 479 The format of a TCP-Message is shown below: 481 0 1 2 3 482 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Version = 10 | Flags | Message-Type | \ 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 488 \ \ 489 / Value (variable length) / 490 \ \ 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Length: 32 bits (unsigned integer) 494 This field contains the number of remaining octets of the TCP- 495 Message (i.e. number of octets of the Value field plus 3). All 496 bit values in this protocol are specified to be in network byte 497 order. 499 Version: 8-bits (unsigned integer) 500 The version of the TCP-Message is 10 in for this document. It 501 MUST be incremented in each future specification modification 502 e.g. changing the Flags field in a way that is not fully 503 backwards compatible. 505 Flags: 8 bits 506 TCP-Message specific flags as described in Section 4.3. 508 Message-Type: 8 bits 509 A value indicating the type of the TCP-Message. 511 Value: variable length 512 Message-type dependent data is stored here. The usage of this 513 field is described along with the respective message-type 515 4.2. Version 517 The TCP-Message version is 10 for this document. The number has 518 deliberately been chosen to prevent [RFC2510] compliant applications 519 from treating it as a valid message type. Applications receiving a 520 version less than 10 SHOULD interpret the message as being an 521 [RFC2510] style message. 523 4.2.1. Version Negotiation 525 If a client knows the protocol version(s) supported by the server 526 (e.g. from a previous TCP-Message exchange or via some out-of-band 527 means) then it SHOULD send a TCP-Message with the highest version 528 supported both by it and the server. If a client does not know what 529 version(s) the server supports then it SHOULD send a TCP-Message 530 using the highest version it supports. 532 If a server receives a TCP-Message version that it supports, then it 533 MUST reply with a TCP-Message of the same version. If the version 534 received is higher than what the server supports, it MUST send back a 535 VersionNotSupported errorMsgRep containing the highest version it 536 supports, see Section 4.4.6. 538 4.2.2. Detection and Interoperation with RFC2510 Conformant 539 Implementations 541 Servers wishing to interoperate with clients conforming to [RFC2510] 542 can do so by treating any received message with a version less than 543 10 as an [RFC2510] message and responding in that format. Servers 544 not wishing to support [RFC2510] messages MUST respond with a 545 [RFC2510] errorMsgRep. 547 If a client receives a [RFC2510] errorMsgRep (message-type 06) 548 message, it MAY automatically resend the same request on the same 549 connection, falling back to the [RFC2510] format; if the received 550 message is not an errorMsgRep, it MUST terminate the connection. It 551 MAY then retry the communication falling back completely to the 552 [RFC2510] format. 554 Naturally, a client MUST abort the connection attempt if the server 555 does not support any of the client's supported versions. It SHOULD 556 retry the version negotiation after a delay to check if the server 557 was updated. 559 4.3. Flags 561 The LSB of the Flags field is used to indicate a connection close; 562 all other bits in the Flags octet MUST be ignored by receivers, and 563 MUST be set to zero by senders. 565 4.3.1. Connection Close Flag 567 By default connections are kept open after the receipt of a response. 568 Either party (client or server) MAY set the connection close bit at 569 any time. If the connection close bit is set on a request, then the 570 server MUST set the bit in the response and close the connection 571 after sending the response. If the bit is set on a response from the 572 server, the client MUST NOT send any further requests on that 573 connection. Applications MAY decide to close an idle connection (one 574 on which no response is outstanding) after some time-out. Because of 575 the problem where a client sends a request and the server closes the 576 connection while the request is still in flight, clients SHOULD 577 automatically retry a request for which no part of the response could 578 be read due to a connection close or reset. 580 If the connection is kept open, it MUST only be used for subsequent 581 request/response transactions started by the client - the server MUST 582 NOT use it to send requests to the client. Different transactions 583 may be freely interwoven on the same connection. E.g. a CR/CP need 584 not immediately be followed by the Confirm, but may be followed by 585 any other request from a different transaction. 587 4.4. Message-Types 589 Message-Types 0-127 are reserved and are to be issued under IANA 590 auspices. Message-types 128-255 are reserved for application use. 592 The Message-Types currently defined are: 594 ID Value Message Name 595 -------- ------------ 596 '00'H pkiReq 597 '01'H pollRep 598 '02'H pollReq 599 '03'H finRep 600 '05'H pkiRep 601 '06'H errorMsgRep 603 If a server receives an unknown message-type, it MUST reply with an 604 InvalidMessageType errorMsgRep. If a client receives an unknown 605 message-type, it MUST abort the current CMP transaction and terminate 606 the connection. 608 The different TCP-Message-types are discussed in the following 609 sections: 611 4.4.1. pkiReq 613 A pkiReq message conveys a PKIMessage from a client to a server. The 614 Value field of this TCP-Message contains a DER-encoded PKIMessage. 616 The type of PKIMessages that can be carried by pkiReq TCP-Messages 617 are (in the order they are defined in [RFC4210]): 618 [0] Initialization Request 619 [2] Certification Request 620 [4] PKCS-10 Request 621 [6] pop Response 622 [7] Key Update Request 624 [9] Key Recovery Request 625 [11] Revocation Request 626 [13] Cross-Certification Request 627 [15] CA Key Update Announcement 628 [16] Certificate Announcement 629 [17] Revocation Announcement 630 [18] CRL Announcement 631 [20] Nested Message 632 [21] General Message 633 [23] Error Message 634 [24] Certificate Confirmation 635 [25] Polling Request 637 4.4.2. pkiRep 639 TCP-Messages of this type are used to send a response to the 640 requestor. The Value field of the pkiRep contains a DER encoded 641 PKIMessage. 643 The type of PKIMessages that can be carried by such pkiRep messages 644 are (in the order they are defined in [RFC4210]): 645 [1] Initialization Response 646 [3] Certification Response 647 [5] pop Challenge 648 [8] Key Update Response 649 [10] Key Recovery Response 650 [12] Revocation Response 651 [14] Cross-Certificate Response 652 [19] Confirmation 653 [22] General Response 654 [23] Error Message 655 [26] Polling Response 657 4.4.3. pollReq 659 A pollReq is used by a client to check the status of a pending TCP- 660 Message. The Value portion of a pollReq contains: 662 0 1 2 3 663 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Polling-Reference | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Polling-Reference: 32 bits (unsigned integer) 669 This polling-reference MUST be the one returned via the 670 respective pollRep TCP-Message. 672 4.4.4. pollRep 674 A pollRep is sent by the server to the client as response in case 675 there is no PKIMessage ready yet. The Value portion of the pollRep 676 looks as follows: 678 0 1 2 3 679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Polling-Reference | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Time-to-Check-Back | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Polling-Reference: 32 bits (unsigned integer) 687 A unique 32-bit number identifying the transaction. 689 Time-to-Check-Back: 32 bits (unsigned integer) 690 The time in seconds indicating the minimum interval after which 691 the client SHOULD check the status again. The duration for which 692 the server keeps the polling-reference unique is left to the 693 implementation. 695 4.4.5. finRep 697 A finRep is sent by the server whenever no other response applies, 698 such as after receiving a CMP pkiConf. The Value portion of the 699 finRep SHALL contain: 701 0 1 2 3 4 5 6 7 702 +-+-+-+-+-+-+-+-+ 703 | '00'H | 704 +-+-+-+-+-+-+-+-+ 706 '00'H: 8 bits 707 All bits set to zero. 709 4.4.6. errorMsgRep 711 This TCP-Message is sent when a TCP-Message level protocol error is 712 detected. It is imperative that PKIError messages MUST NOT be sent 713 using this message type. Examples of TCP-Message level errors are: 715 o Invalid protocol version 716 o Invalid TCP message-type 717 o Invalid polling reference number 719 The Value field of the errorMsgRep TCP-Message MUST contain: 721 0 1 2 3 722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Error-Type | Data-Length | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 \ \ 727 / Data (variable length) / 728 \ \ 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Error-Type: 16 bits A value (format described below) indicating the 732 type of the error. 734 Data-Length: 16 bits (unsigned integer) Contains the length of the 735 Data field in number of octets. Error messages not conveying 736 additional information MUST set Data-Length to 0. 738 Data: octets 739 An UTF8 text string for user readable error messages, containing 740 additional information about the error. Note that it does not 741 contain a terminating NULL character at the end. It SHOULD 742 include an [RFC5646] language tag, as described in [RFC2482] 744 The Error-Type is in the format MMNN where M and N are hex digits 745 (0-F) and MM represents the major category and NN the minor. The 746 major categories defined by this specification are: 748 ID Value Major Categories 749 -------- ---------------- 750 '01'H TCP-Message version negotiation 751 '02'H client errors 752 '03'H server errors 754 The major categories '80'H-'FF'H are reserved for application use. 756 The different error-types are discussed in the following sections: 758 4.4.6.1. VersionNotSupported 760 The VersionNotSupported errorMsgRep is defined as follows: 762 +------------------+------------------------+ 763 | Field | Value | 764 +------------------+------------------------+ 765 | Error-Type | '0101'H | 766 | | | 767 | Data-Length | 1 | 768 | | | 769 | Data | | 770 | | | 771 | UTF8-text String | implementation defined | 772 +------------------+------------------------+ 774 where is the highest TCP-Message protocol version the 775 server supports. 777 4.4.6.2. GeneralClientError 779 The GeneralClientError errorMsgRep is defined as follows: 781 +------------------+------------------------+ 782 | Field | Value | 783 +------------------+------------------------+ 784 | Error-Type | '0200'H | 785 | | | 786 | Data-Length | 0 | 787 | | | 788 | Data | | 789 | | | 790 | UTF8-text String | implementation defined | 791 +------------------+------------------------+ 793 4.4.6.3. InvalidMessageType 795 The InvalidMessageType errorMsgRep is defined as follows: 797 +------------------+------------------------+ 798 | Field | Value | 799 +------------------+------------------------+ 800 | Error-Type | '0201'H | 801 | | | 802 | Data-Length | 1 | 803 | | | 804 | Data | | 805 | | | 806 | UTF8-text String | implementation defined | 807 +------------------+------------------------+ 809 where is the invalid Message-Type ID received by the 810 server. 812 4.4.6.4. InvalidPollID 814 The InvalidPollID errorMsgRep is defined as follows: 816 +------------------+------------------------+ 817 | Field | Value | 818 +------------------+------------------------+ 819 | Error-Type | '0202'H | 820 | | | 821 | Data-Length | 4 | 822 | | | 823 | Data | | 824 | | | 825 | UTF8-text String | implementation defined | 826 +------------------+------------------------+ 828 where is the polling-reference received by the 829 server, identifying the transaction. 831 4.4.6.5. GeneralServerError 833 The GeneralServerError errorMsgRep is defined as follows: 835 +------------------+------------------------+ 836 | Field | Value | 837 +------------------+------------------------+ 838 | Error-Type | '0300'H | 839 | | | 840 | Data-Length | 0 | 841 | | | 842 | Data | | 843 | | | 844 | UTF8-text String | implementation defined | 845 +------------------+------------------------+ 847 5. File-Based Protocol 849 A file containing a PKIMessage MUST contain only the DER encoding of 850 one PKIMessage, there MUST NOT be extraneous header or trailer 851 information in the file. 853 Such files can be used to transport PKIMessage sequences using e.g. 854 FTP. 856 6. Mail-Based Protocol 858 This subsection specifies a means for conveying ASN.1-encoded 859 messages for the protocol exchanges via Internet mail [RFC5321]. A 860 simple MIME object is specified as follows. 862 Content-Type: application/pkixcmp 863 Content-Transfer-Encoding: base64 865 <> 867 This MIME object can be sent and received using common MIME 868 processing engines and provides a simple Internet mail transport for 869 PKIX-CMP messages. Implementations MAY wish to also recognize and 870 use the "application/x-pkixcmp" MIME type (specified in earlier 871 versions of this document) in order to support backward compatibility 872 wherever applicable. 874 7. Security Considerations 876 Four aspects need to be considered by server side implementers: 878 1. There is the risk for denial of service attacks through resource 879 consumption by opening many connections, therefore idle 880 connections should be terminated after an appropriate timeout, 881 maybe also depending on the available free resources. After 882 sending a CMP Error Message, the server should close the 883 connection even if the CMP transaction is not yet fully 884 completed. 886 2. There is no security at the TCP and HTTP protocol level (unless 887 tunneled via SSL/TLS) and thus information from TCP-Messages or 888 the HTTP protocol SHOULD NOT be used to change state of the 889 transaction. Change of state SHOULD be triggered by the signed 890 PKIMessages which are carried within the TCP-Message. 892 3. If the server is going to be sending messages with sensitive 893 information (not meant for public consumption) in the clear, it 894 is RECOMMENDED that the server sends back the message directly 895 and not use the TCP-Message pollRep. 897 4. The TCP-Message polling request/response mechanism can be used 898 for all kinds of denial of service attacks. It is RECOMMENDED 899 that a server does not change the polling-reference between 900 polling requests. 902 8. Information Security Considerations 904 CMP provides inbuilt integrity protection and authentication. Due to 905 the nature of a PKI, from a security perspective the information 906 communicated unencrypted does not contain sensitive information. 908 However, it might be possible for an interceptor to utilize the 909 available information to gather confidential technical or business 910 critical information. Therefore, users of the HTTP CMP transport 911 might want to use HTTP over TLS according to [RFC2818] or should 912 consider to use virtual private networks created e.g. utilizing 913 Internet Protocol Security according to [RFC4301]. 915 9. IANA Considerations 917 The IANA has already registered TCP and UDP port 829 for "PKIX-3 918 CA/RA" and the MIME media type "application/pkixcmp" for identifying 919 CMP sequences. 921 No further action by the IANA is necessary for this document or any 922 anticipated updates. 924 10. References 926 10.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, March 1997. 931 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 932 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 933 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 935 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 936 Resource Identifier (URI): Generic Syntax", STD 66, 937 RFC 3986, January 2005. 939 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 940 "Internet X.509 Public Key Infrastructure Certificate 941 Management Protocol (CMP)", RFC 4210, September 2005. 943 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 944 Housley, R., and W. Polk, "Internet X.509 Public Key 945 Infrastructure Certificate and Certificate Revocation List 946 (CRL) Profile", RFC 5280, May 2008. 948 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 949 October 2008. 951 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 952 Languages", BCP 47, RFC 5646, September 2009. 954 10.2. Informative References 956 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 957 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 959 [RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode 960 Plain Text", RFC 2482, January 1999. 962 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 963 Infrastructure Certificate Management Protocols", 964 RFC 2510, March 1999. 966 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 968 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 969 Internet Protocol", RFC 4301, December 2005. 971 Appendix A. Acknowledgments 973 Until the fifth draft version of this document, released in November 974 24th 2000, the sole authors were Amit Kapoor and Ronald Tschlaer from 975 Certicom. Up to this point, besides editorial changes, the now 976 deprecated TCP-Based transport was described as it is still included 977 herein. They are not available for this working on this document 978 anymore at the time it is entering the "Authors Final Review state 979 AUTH48". As they therefore cannot approve this document as it would 980 be necessary, their names were moved to this section. Their contact 981 data, as originally stated by them, is as follows: 983 Amit Kapoor 984 Certicom 985 25801 Industrial Blvd 986 Hayward, CA 987 US 988 Email: amit@trustpoint.com 990 Ronald Tschalaer 991 Certicom 992 25801 Industrial Blvd 993 Hayward, CA 994 US 995 Email: ronald@trustpoint.com 997 The authors gratefully acknowledge the contributions of various 998 members of the IETF PKIX Working Group and the ICSA CA-talk mailing 999 list (a list solely devoted to discussing CMP interoperability 1000 efforts). 1002 By providing ideas, giving hints and doing invaluable review work, 1003 the following individuals, listed alphabetically, have significantly 1004 contributed to this document: 1006 Tomas Gustavsson, Primekey 1007 Peter Gutmann, University of Auckland 1008 Wolf-Dietrich Moeller, Nokia Siemens Networks 1010 Appendix B. Registration of the application/pkixcmp Media Type 1011 To: ietf-types@iana.org 1012 Subject: Registration of MIME media type application/pkixcmp 1014 MIME media type name: application 1016 MIME subtype name: pkixcmp 1018 Required parameters: - 1020 Optional parameters: - 1022 Encoding considerations: 1024 Content may contain arbitrary octet values (the ASN.1 DER encoding 1025 of a PKIMessage sequence, as defined in the IETF PKIX Working Group 1026 specifications). base64 encoding is required for MIME e-mail; no 1027 encoding is necessary for HTTP. 1029 Security considerations: 1031 This MIME type may be used to transport Public-Key Infrastructure 1032 (PKI) messages between PKI entities. These messages are defined by 1033 the IETF PKIX Working Group and are used to establish and maintain 1034 an Internet X.509 PKI. There is no requirement for specific 1035 security mechanisms to be applied at this level if the PKI messages 1036 themselves are protected as defined in the PKIX specifications. 1038 Interoperability considerations: - 1040 Published specification: this document 1042 Applications which use this media type: Applications using 1043 certificate management, operational, or ancillary protocols (as 1044 defined by the IETF PKIX Working Group) to send PKI messages via 1045 E-Mail or HTTP. 1047 Additional information: 1049 Magic number (s): - 1050 File extension (s): ".PKI" 1051 Macintosh File Type Code (s): - 1053 Person and email address to contact for further information: 1054 Martin Peylo, martin.peylo@nsn.com 1056 Intended usage: COMMON 1058 Author/Change controller: Martin Peylo 1060 Authors' Addresses 1062 Tomi Kause 1063 SSH Communications Security Corp. 1064 Fredrikinkatu 42 1065 Helsinki 00100 1066 Finland 1068 Email: toka@ssh.com 1070 Martin Peylo 1071 Nokia Siemens Networks 1072 Linnoitustie 6 1073 Espoo 02600 1074 Finland 1076 Email: martin.peylo@nsn.com