idnits 2.17.1 draft-ietf-pkix-cmp-transport-protocols-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** 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 draft header indicates that this document updates RFC2510, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4210, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2510, updated by this document, for RFC5378 checks: 1996-06-14) -- 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 (July 30, 2009) is 5383 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 284 -- Looks like a reference, but probably isn't: '2' on line 285 -- Looks like a reference, but probably isn't: '4' on line 286 -- Looks like a reference, but probably isn't: '6' on line 287 -- Looks like a reference, but probably isn't: '7' on line 288 -- Looks like a reference, but probably isn't: '9' on line 289 -- Looks like a reference, but probably isn't: '11' on line 290 -- Looks like a reference, but probably isn't: '13' on line 291 -- Looks like a reference, but probably isn't: '15' on line 292 -- Looks like a reference, but probably isn't: '16' on line 293 -- Looks like a reference, but probably isn't: '17' on line 294 -- Looks like a reference, but probably isn't: '18' on line 295 -- Looks like a reference, but probably isn't: '20' on line 296 -- Looks like a reference, but probably isn't: '21' on line 297 -- Looks like a reference, but probably isn't: '23' on line 320 -- Looks like a reference, but probably isn't: '24' on line 300 -- Looks like a reference, but probably isn't: '25' on line 301 -- Looks like a reference, but probably isn't: '1' on line 311 -- Looks like a reference, but probably isn't: '3' on line 312 -- Looks like a reference, but probably isn't: '5' on line 313 -- Looks like a reference, but probably isn't: '8' on line 314 -- Looks like a reference, but probably isn't: '10' on line 315 -- Looks like a reference, but probably isn't: '12' on line 316 -- Looks like a reference, but probably isn't: '14' on line 317 -- Looks like a reference, but probably isn't: '19' on line 318 -- Looks like a reference, but probably isn't: '22' on line 319 -- Looks like a reference, but probably isn't: '26' on line 321 ** Downref: Normative reference to an Informational RFC: RFC 1945 ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 2482 (Obsoleted by RFC 6082) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kapoor 3 Internet-Draft R. Tschalaer 4 Updates: 2510,4210 Certicom 5 (if approved) T. Kause 6 Intended status: Standards Track SSH 7 Expires: January 31, 2010 M. Peylo 8 NSN 9 July 30, 2009 11 Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP 12 draft-ietf-pkix-cmp-transport-protocols-06.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 31, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes how to layer Certificate Management Protocols 60 over various transport protocols. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. TCP-Based Management Protocol . . . . . . . . . . . . . . . . 6 67 3.1. General Form . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Version . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2.1. Version Negotiation . . . . . . . . . . . . . . . . . 7 70 3.2.2. Detection and Interoperation with RFC2510 71 Conformant Implementations . . . . . . . . . . . . . . 8 72 3.3. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.3.1. Connection Close Flag . . . . . . . . . . . . . . . . 8 74 3.4. Message-Types . . . . . . . . . . . . . . . . . . . . . . 9 75 3.4.1. pkiReq . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.4.2. pkiRep . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.4.3. pollReq . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.4.4. pollRep . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4.5. finRep . . . . . . . . . . . . . . . . . . . . . . . . 11 80 3.4.6. errorMsgRep . . . . . . . . . . . . . . . . . . . . . 11 81 3.4.6.1. VersionNotSupported . . . . . . . . . . . . . . . 12 82 3.4.6.2. GeneralClientError . . . . . . . . . . . . . . . . 13 83 3.4.6.3. InvalidMessageType . . . . . . . . . . . . . . . . 13 84 3.4.6.4. InvalidPollID . . . . . . . . . . . . . . . . . . 14 85 3.4.6.5. GeneralServerError . . . . . . . . . . . . . . . . 14 86 4. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . . . 15 87 4.1. HTTP Versions . . . . . . . . . . . . . . . . . . . . . . 15 88 4.2. General Form . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.3. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.4. HTTP Considerations . . . . . . . . . . . . . . . . . . . 15 91 4.5. Compatibility Issues with Legacy Implementations . . . . . 15 92 5. File-Based Protocol . . . . . . . . . . . . . . . . . . . . . 17 93 6. Mail-Based Protocol . . . . . . . . . . . . . . . . . . . . . 18 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 98 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 99 Appendix B. Registration of the application/pkixcmp Media Type . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 Well defined transport mechanisms are required for the Certificate 105 Management Protocol [RFC4210] in order to allow end entities, RAs and 106 CAs to pass PKIMessage sequences between them. 108 2. Requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 111 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 112 as shown) are to be interpreted as described in [RFC2119]. 114 3. TCP-Based Management Protocol 116 While this section is called TCP-based and the messages are called 117 TCP-Messages, the same protocol can be used over any reliable, 118 connection oriented transport protocol (e.g. SNA, DECnet, etc.). 119 This protocol is suitable for cases where an end entity (or an RA) 120 initiates a transaction and can poll to pick up the results. 122 The client sends a TCP-Message to the server, and the server responds 123 with another TCP-Message. A response MUST be sent for every request, 124 even if the encapsulated CMP message in the request does not have a 125 corresponding response. 127 The protocol requires a listener process on an RA or CA which can 128 accept TCP-Messages on a well-defined port (default TCP port number 129 is 829). Typically a client initiates the connection to the server 130 and instantly submits a TCP-Message. The server replies with a TCP- 131 Message containing either a CMP message or a reference number to be 132 used later when polling for the actual CMP response message. 134 If a polling-reference was supplied, the client SHOULD send a polling 135 request using this polling-reference after waiting for at least the 136 time specified along with the reference number. The server may again 137 reply with a new polling-reference or with the actual CMP message 138 response. 140 When the final CMP response message has been picked up by the client, 141 no new polling reference is supplied. 143 3.1. General Form 145 The format of a TCP-Message is shown below: 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Version = 10 | Flags | Message-Type | \ 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 154 \ \ 155 / Value (variable length) / 156 \ \ 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Length: 32 bits (unsigned integer) 160 This field contains the number of remaining octets of the TCP- 161 Message (i.e. number of octets of the Value field plus 3). All 162 bit values in this protocol are specified to be in network byte 163 order. 165 Version: 8-bits (unsigned integer) 166 The version of the TCP-Message is 10 in for this document. It 167 MUST be incremented in each future specification modification 168 e.g. changing the Flags field in a way that is not fully 169 backwards compatible. 171 Flags: 8 bits 172 TCP-Message specific flags as described in Section 3.3. 174 Message-Type: 8 bits 175 A value indicating the type of the TCP-Message. 177 Value: variable length 178 Message-type dependent data is stored here. The usage of this 179 field is described along with the respective message-type 181 3.2. Version 183 The TCP-Message version is 10 for this document. The number has 184 deliberately been chosen to prevent [RFC2510] compliant applications 185 from treating it as a valid message type. Applications receiving a 186 version less than 10 SHOULD interpret the message as being an 187 [RFC2510] style message. 189 3.2.1. Version Negotiation 191 If a client knows the protocol version(s) supported by the server 192 (e.g. from a previous TCP-Message exchange or via some out-of-band 193 means) then it SHOULD send a TCP-Message with the highest version 194 supported both by it and the server. If a client does not know what 195 version(s) the server supports then it SHOULD send a TCP-Message 196 using the highest version it supports. 198 If a server receives a TCP-Message version that it supports, then it 199 MUST reply with a TCP-Message of the same version. If the version 200 received is higher than what the server supports, it MUST send back a 201 VersionNotSupported errorMsgRep containing the highest version it 202 supports, see Section 3.4.6. 204 3.2.2. Detection and Interoperation with RFC2510 Conformant 205 Implementations 207 Servers wishing to interoperate with clients conforming to [RFC2510] 208 can do so by treating any received message with a version less than 209 10 as an [RFC2510] message and responding in that format. Servers 210 not wishing to support [RFC2510] messages MUST respond with a 211 [RFC2510] errorMsgRep. 213 If a client receives a [RFC2510] errorMsgRep (message-type 06) 214 message, it MAY automatically resend the same request on the same 215 connection, falling back to the [RFC2510] format; if the received 216 message is not an errorMsgRep, it MUST terminate the connection. It 217 MAY then retry the communication falling back completely to the 218 [RFC2510] format. 220 Naturally, a client MUST abort the connection attempt if the server 221 does not support any of the client's supported versions. It SHOULD 222 retry the version negotiation after a delay to check if the server 223 was updated. 225 3.3. Flags 227 The LSB of the Flags field is used to indicate a connection close; 228 all other bits in the Flags octet MUST be ignored by receivers, and 229 MUST be set to zero by senders. 231 3.3.1. Connection Close Flag 233 By default connections are kept open after the receipt of a response. 234 Either party (client or server) MAY set the connection close bit at 235 any time. If the connection close bit is set on a request, then the 236 server MUST set the bit in the response and close the connection 237 after sending the response. If the bit is set on a response from the 238 server, the client MUST NOT send any further requests on that 239 connection. Applications MAY decide to close an idle connection (one 240 on which no response is outstanding) after some time-out. Because of 241 the problem where a client sends a request and the server closes the 242 connection while the request is still in flight, clients SHOULD 243 automatically retry a request for which no part of the response could 244 be read due to a connection close or reset. 246 If the connection is kept open, it MUST only be used for subsequent 247 request/response transactions started by the client - the server MUST 248 NOT use it to send requests to the client. Different transactions 249 may be freely interwoven on the same connection. E.g. a CR/CP need 250 not immediately be followed by the Confirm, but may be followed by 251 any other request from a different transaction. 253 3.4. Message-Types 255 Message-Types 0-127 are reserved and are to be issued under IANA 256 auspices. Message-types 128-255 are reserved for application use. 258 The Message-Types currently defined are: 260 ID Value Message Name 261 -------- ------------ 262 '00'H pkiReq 263 '01'H pollRep 264 '02'H pollReq 265 '03'H finRep 266 '05'H pkiRep 267 '06'H errorMsgRep 269 If a server receives an unknown message-type, it MUST reply with an 270 InvalidMessageType errorMsgRep. If a client receives an unknown 271 message-type, it MUST abort the current CMP transaction and terminate 272 the connection. 274 The different TCP-Message-types are discussed in the following 275 sections: 277 3.4.1. pkiReq 279 A pkiReq message conveys a PKIMessage from a client to a server. The 280 Value field of this TCP-Message contains a DER-encoded PKIMessage. 282 The type of PKIMessages that can be carried by pkiReq TCP-Messages 283 are (in the order they are defined in [RFC4210]): 284 [0] Initialization Request 285 [2] Certification Request 286 [4] PKCS-10 Request 287 [6] pop Response 288 [7] Key Update Request 289 [9] Key Recovery Request 290 [11] Revocation Request 291 [13] Cross-Certification Request 292 [15] CA Key Update Announcement 293 [16] Certificate Announcement 294 [17] Revocation Announcement 295 [18] CRL Announcement 296 [20] Nested Message 297 [21] General Message 298 [23] Error Message 300 [24] Certificate Confirmation 301 [25] Polling Request 303 3.4.2. pkiRep 305 TCP-Messages of this type are used to send a response to the 306 requestor. The Value field of the pkiRep contains a DER encoded 307 PKIMessage. 309 The type of PKIMessages that can be carried by such pkiRep messages 310 are (in the order they are defined in [RFC4210]): 311 [1] Initialization Response 312 [3] Certification Response 313 [5] pop Challenge 314 [8] Key Update Response 315 [10] Key Recovery Response 316 [12] Revocation Response 317 [14] Cross-Certificate Response 318 [19] Confirmation 319 [22] General Response 320 [23] Error Message 321 [26] Polling Response 323 3.4.3. pollReq 325 A pollReq is used by a client to check the status of a pending TCP- 326 Message. The Value portion of a pollReq contains: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Polling-Reference | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Polling-Reference: 32 bits (unsigned integer) 335 This polling-reference MUST be the one returned via the 336 respective pollRep TCP-Message. 338 3.4.4. pollRep 340 A pollRep is sent by the server to the client as response in case 341 there is no PKIMessage ready yet. The Value portion of the pollRep 342 looks as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Polling-Reference | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Time-to-Check-Back | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Polling-Reference: 32 bits (unsigned integer) 353 A unique 32-bit number identifying the transaction. 355 Time-to-Check-Back: 32 bits (unsigned integer) 356 The time in seconds indicating the minimum interval after which 357 the client SHOULD check the status again. The duration for which 358 the server keeps the polling-reference unique is left to the 359 implementation. 361 3.4.5. finRep 363 A finRep is sent by the server whenever no other response applies, 364 such as after receiving a CMP pkiConf. The Value portion of the 365 finRep SHALL contain: 367 0 1 2 3 4 5 6 7 368 +-+-+-+-+-+-+-+-+ 369 | '00'H | 370 +-+-+-+-+-+-+-+-+ 372 '00'H: 8 bits 373 All bits set to zero. 375 3.4.6. errorMsgRep 377 This TCP-Message is sent when a TCP-Message level protocol error is 378 detected. It is imperative that PKIError messages MUST NOT be sent 379 using this message type. Examples of TCP-Message level errors are: 380 o Invalid protocol version 381 o Invalid TCP message-type 382 o Invalid polling reference number 384 The Value field of the errorMsgRep TCP-Message MUST contain: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Error-Type | Data-Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 \ \ 392 / Data (variable length) / 393 \ \ 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Error-Type: 16 bits A value (format described below) indicating the 397 type of the error. 399 Data-Length: 16 bits (unsigned integer) Contains the length of the 400 Data field in number of octets. Error messages not conveying 401 additional information MUST set Data-Length to 0. 403 Data: octets 404 An UTF8 text string for user readable error messages, containing 405 additional information about the error. Note that it does not 406 contain a terminating NULL character at the end. It SHOULD 407 include an [RFC4646] language tag, as described in [RFC2482] 409 The Error-Type is in the format MMNN where M and N are hex digits 410 (0-F) and MM represents the major category and NN the minor. The 411 major categories defined by this specification are: 413 ID Value Major Categories 414 -------- ---------------- 415 '01'H TCP-Message version negotiation 416 '02'H client errors 417 '03'H server errors 419 The major categories '80'H-'FF'H are reserved for application use. 421 The different error-types are discussed in the following sections: 423 3.4.6.1. VersionNotSupported 425 The VersionNotSupported errorMsgRep is defined as follows: 427 +------------------+------------------------+ 428 | Field | Value | 429 +------------------+------------------------+ 430 | Error-Type | '0101'H | 431 | | | 432 | Data-Length | 1 | 433 | | | 434 | Data | | 435 | | | 436 | UTF8-text String | implementation defined | 437 +------------------+------------------------+ 439 where is the highest TCP-Message protocol version the 440 server supports. 442 3.4.6.2. GeneralClientError 444 The GeneralClientError errorMsgRep is defined as follows: 446 +------------------+------------------------+ 447 | Field | Value | 448 +------------------+------------------------+ 449 | Error-Type | '0200'H | 450 | | | 451 | Data-Length | 0 | 452 | | | 453 | Data | | 454 | | | 455 | UTF8-text String | implementation defined | 456 +------------------+------------------------+ 458 3.4.6.3. InvalidMessageType 460 The InvalidMessageType errorMsgRep is defined as follows: 462 +------------------+------------------------+ 463 | Field | Value | 464 +------------------+------------------------+ 465 | Error-Type | '0201'H | 466 | | | 467 | Data-Length | 1 | 468 | | | 469 | Data | | 470 | | | 471 | UTF8-text String | implementation defined | 472 +------------------+------------------------+ 474 where is the invalid Message-Type ID received by the 475 server. 477 3.4.6.4. InvalidPollID 479 The InvalidPollID errorMsgRep is defined as follows: 481 +------------------+------------------------+ 482 | Field | Value | 483 +------------------+------------------------+ 484 | Error-Type | '0202'H | 485 | | | 486 | Data-Length | 4 | 487 | | | 488 | Data | | 489 | | | 490 | UTF8-text String | implementation defined | 491 +------------------+------------------------+ 493 where is the polling-reference received by the 494 server, identifying the transaction. 496 3.4.6.5. GeneralServerError 498 The GeneralServerError errorMsgRep is defined as follows: 500 +------------------+------------------------+ 501 | Field | Value | 502 +------------------+------------------------+ 503 | Error-Type | '0300'H | 504 | | | 505 | Data-Length | 0 | 506 | | | 507 | Data | | 508 | | | 509 | UTF8-text String | implementation defined | 510 +------------------+------------------------+ 512 4. HTTP-Based Protocol 514 The stateless HTTP MAY be utilized for conveying CMP messages instead 515 of or additionally to the TCP-Messages. 517 4.1. HTTP Versions 519 Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] 520 MAY be used. Naturally, the newer version SHOULD be preferred. 521 Both, server and client implementations MUST be able to interact with 522 counterparts primarily utilizing the different HTTP protocol version. 524 4.2. General Form 526 An ASN.1 DER-encoded PKIMessage is sent as the entity-body of an HTTP 527 POST request. If the HTTP request is successful, the server returns 528 the CMP reply in the body of the HTTP response. The response status 529 code in this case MUST be 200; other 2xx codes MUST NOT be used for 530 this purpose. 532 Note that a server may return any 1xx, 3xx, 4xx, or 5xx code if the 533 HTTP request needs further handling or is otherwise not acceptable. 535 4.3. MIME Type 537 The MIME type "application/pkixcmp" MUST be set as in the HTTP header 538 when conveying a PKIMessage. 540 4.4. HTTP Considerations 542 In general, CMP messages are not cachable; requests and responses 543 MUST include a "Cache-Control: no-cache" (and, if either side uses 544 HTTP/1.0, a "Pragma: no-cache") to prevent the client from getting 545 cached responses. 547 Connection management is based on the HTTP provided mechanisms 548 (Connection and Proxy-Connection header fields). 550 While an implementation MAY make use of all defined features of the 551 HTTP protocol, it SHOULD keep the protocol utilization as simple as 552 possible. 554 Content codings MAY be applied. 556 4.5. Compatibility Issues with Legacy Implementations 558 As this document was subject of multiple changes during the long 559 period of time it was created in, several implementations may exist 560 using a different approach for HTTP transport. 562 Thus, legacy implementations might also use an unregistered 563 "application/pkixcmp-poll" MIME type as it was specified in earlier 564 drafts of this document. Here, the entity-body of an HTTP POST 565 request contains a TCP-Message instead of a plain DER-encoded 566 PKIMessage. Effectively, this is conveying PKIMessage over TCP- 567 Message over HTTP. 569 5. File-Based Protocol 571 A file containing a PKIMessage MUST contain only the DER encoding of 572 one PKIMessage, there MUST NOT be extraneous header or trailer 573 information in the file. 575 Such files can be used to transport PKIMessage sequences using e.g. 576 FTP. 578 6. Mail-Based Protocol 580 This subsection specifies a means for conveying ASN.1-encoded 581 messages for the protocol exchanges via Internet mail [RFC2821]. A 582 simple MIME object is specified as follows. 584 Content-Type: application/pkixcmp 585 Content-Transfer-Encoding: base64 587 <> 589 This MIME object can be sent and received using common MIME 590 processing engines and provides a simple Internet mail transport for 591 PKIX-CMP messages. Implementations MAY wish to also recognize and 592 use the "application/x-pkixcmp" MIME type (specified in earlier 593 versions of this document) in order to support backward compatibility 594 wherever applicable. 596 7. Security Considerations 598 Three aspects need to be considered by server side implementors: 600 1. There is no security at the TCP and HTTP protocol level (unless 601 tunneled via SSL/TLS) and thus TCP-Messages SHOULD NOT be used to 602 change state of the transaction. Change of state SHOULD be 603 triggered by the signed PKIMessages which are carried within the 604 TCP-Message. 606 2. If the server is going to be sending messages with sensitive 607 information (not meant for public consumption) in the clear, it 608 is RECOMMENDED that the server sends back the message directly 609 and not use the pollRep. 611 3. The polling request/response mechanism can be used for all kinds 612 of denial of service attacks. It is RECOMMENDED that a server 613 does not change the polling-reference between polling requests. 615 8. References 617 8.1. Normative References 619 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 620 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 626 Infrastructure Certificate Management Protocols", 627 RFC 2510, March 1999. 629 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 630 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 631 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 633 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 634 "Internet X.509 Public Key Infrastructure Certificate 635 Management Protocol (CMP)", RFC 4210, September 2005. 637 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 638 Languages", BCP 47, RFC 4646, September 2006. 640 8.2. Informative References 642 [RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode 643 Plain Text", RFC 2482, January 1999. 645 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 646 April 2001. 648 Appendix A. Acknowledgments 650 The authors gratefully acknowledge the contributions of various 651 members of the IETF PKIX Working Group and the ICSA CA-talk mailing 652 list (a list solely devoted to discussing CMP interoperability 653 efforts). 655 Appendix B. Registration of the application/pkixcmp Media Type 656 To: ietf-types@iana.org 657 Subject: Registration of MIME media type application/pkixcmp 659 MIME media type name: application 661 MIME subtype name: pkixcmp 663 Required parameters: - 665 Optional parameters: - 667 Encoding considerations: 669 Content may contain arbitrary octet values (the ASN.1 DER encoding 670 of a PKIMessage sequence, as defined in the IETF PKIX Working Group 671 specifications). base64 encoding is required for MIME e-mail; no 672 encoding is necessary for HTTP. 674 Security considerations: 676 This MIME type may be used to transport Public-Key Infrastructure 677 (PKI) messages between PKI entities. These messages are defined by 678 the IETF PKIX Working Group and are used to establish and maintain 679 an Internet X.509 PKI. There is no requirement for specific 680 security mechanisms to be applied at this level if the PKI messages 681 themselves are protected as defined in the PKIX specifications. 683 Interoperability considerations: - 685 Published specification: this document 687 Applications which use this media type: Applications using 688 certificate management, operational, or ancillary protocols (as 689 defined by the IETF PKIX Working Group) to send PKI message via 690 E-Mail or HTTP. 692 Additional information: 694 Magic number (s): - 695 File extension (s): ".PKI" 696 Macintosh File Type Code (s): - 698 Person and email address to contact for further information: 699 Martin Peylo, martin.peylo@nsn.com 701 Intended usage: COMMON 703 Author/Change controller: Martin Peylo 705 Authors' Addresses 707 Amit Kapoor 708 Certicom 709 25801 Industrial Blvd 710 Hayward, CA 711 US 713 Email: amit@trustpoint.com 715 Ronald Tschalaer 716 Certicom 717 25801 Industrial Blvd 718 Hayward, CA 719 US 721 Email: ronald@trustpoint.com 723 Tomi Kause 724 SSH Communications Security Corp. 725 Fredrikinkatu 42 726 Helsinki 00100 727 Finland 729 Email: toka@ssh.com 731 Martin Peylo 732 Nokia Siemens Networks 733 Linnoitustie 6 734 Espoo 02600 735 Finland 737 Email: martin.peylo@nsn.com