idnits 2.17.1 draft-ietf-pkix-cmp-transport-protocols-12.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 (June 15, 2011) is 4670 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 211 -- Looks like a reference, but probably isn't: '2' on line 212 -- Looks like a reference, but probably isn't: '4' on line 213 -- Looks like a reference, but probably isn't: '6' on line 214 -- Looks like a reference, but probably isn't: '7' on line 215 -- Looks like a reference, but probably isn't: '9' on line 216 -- Looks like a reference, but probably isn't: '11' on line 217 -- Looks like a reference, but probably isn't: '13' on line 218 -- Looks like a reference, but probably isn't: '15' on line 267 -- Looks like a reference, but probably isn't: '16' on line 268 -- Looks like a reference, but probably isn't: '17' on line 269 -- Looks like a reference, but probably isn't: '18' on line 270 -- Looks like a reference, but probably isn't: '20' on line 223 -- Looks like a reference, but probably isn't: '21' on line 225 -- Looks like a reference, but probably isn't: '23' on line 226 -- Looks like a reference, but probably isn't: '24' on line 227 -- Looks like a reference, but probably isn't: '25' on line 228 == Unused Reference: 'RFC5321' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC5646' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC2482' is defined on line 495, but no explicit reference was found in the text ** 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 (~~), 5 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Kause 3 Internet-Draft Tectia 4 Updates: 4210 (if approved) M. Peylo 5 Intended status: Standards Track NSN 6 Expires: December 17, 2011 June 15, 2011 8 Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP 9 draft-ietf-pkix-cmp-transport-protocols-12.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 December 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. HTTP-Based Protocol . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. HTTP Versions . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Persistent Connections . . . . . . . . . . . . . . . . . . 5 69 3.3. General Form . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.4. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.5. Communication Workflow . . . . . . . . . . . . . . . . . . 6 72 3.6. HTTP Request-URI . . . . . . . . . . . . . . . . . . . . . 6 73 3.7. Announcements . . . . . . . . . . . . . . . . . . . . . . 7 74 3.7.1. Pushing of Announcements . . . . . . . . . . . . . . . 7 75 3.7.2. Polling of Announcements . . . . . . . . . . . . . . . 8 76 3.7.2.1. CA Key Update Announcement . . . . . . . . . . . . 8 77 3.7.2.2. Revocation Announcement . . . . . . . . . . . . . 9 78 3.7.2.3. CRL Announcement . . . . . . . . . . . . . . . . . 9 79 3.8. HTTP Considerations . . . . . . . . . . . . . . . . . . . 10 80 3.9. Compatibility Issues with Legacy Implementations . . . . . 10 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 5. Information Security Considerations . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 88 Appendix B. Registration of the application/pkixcmp Media Type . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 The Certificate Management Protocol (CMP) [RFC4210] requires well 94 defined transport mechanisms to enable End Entities, RAs and CAs to 95 pass PKIMessage sequences between them. This document defines the 96 transport mechanisms which were removed from the main CMP 97 specification with the second release and referred to be in a 98 separate document. 100 The first version of the CMP specification [RFC2510] included a brief 101 description of a simple TCP-based transport protocol. Its features 102 are simple transport level error-handling and a mechanism to poll for 103 outstanding PKI messages. Additionally, it was mentioned that PKI 104 messages could also be conveyed using file-, E-mail- and HTTP-based 105 transport. 107 The current version of the CMP specification incorporated an own 108 polling mechanism and thus the need for a transport protocol 109 providing this functionality vanished. The remaining features CMP 110 requires from its transport protocols are connection- and error- 111 handling. 113 During the long time it existed as draft, this RFC was undergoing 114 drastic changes. The TCP-based transport specification was enhanced 115 and a TCP-Messages-over-HTTP transport specification appeared. As 116 both proved to be needless and cumbersome, implementers preferred to 117 use plain HTTP transport. This specification now reflects that by 118 exclusively describing HTTP transport. 120 HTTP transport is generally easy to implement, traverses network 121 borders utilizing ubiquitous proxies and is already commonly found in 122 existing implementations. 124 2. Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. HTTP-Based Protocol 132 For direct interaction between two entities, where a reliable 133 transport protocol like TCP is available, HTTP SHOULD be utilized for 134 conveying CMP messages. 136 With its status codes, HTTP provides needed error reporting 137 capabilities. General problems on the server side as well as those 138 directly caused by the respective request can be reported to the 139 client. 141 As CMP implements a transaction ID, identifying transactions 142 consisting of more than just a single request/response pair, the 143 statelessness of HTTP is not blocking its usage as transport protocol 144 for CMP messages. 146 3.1. HTTP Versions 148 Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] 149 MAY be used. Naturally, the newer version should be preferred. To 150 support legacy implementations, both server and client MUST be able 151 to interact with counterparts utilizing the other HTTP protocol 152 version. 154 3.2. Persistent Connections 156 HTTP permits to reuse a connection for subsequent requests. 157 Implementations may use this functionality for messages within the 158 same transaction but MUST NOT rely on that, as e.g. intermediate HTTP 159 proxies might terminate the connection after each request/response 160 pair. 162 In contrast to HTTP/1.1, persistent connections are explicitly 163 negotiated in HTTP/1.0. To avoid the problems described in chapter 164 19.6.2 in [RFC2616], HTTP/1.0 implementations must not send Keep- 165 Alive when talking to proxies. 167 3.3. General Form 169 An ASN.1 DER-encoded PKIMessage is sent as the entity-body of an HTTP 170 POST request. If this HTTP request is successful, the server returns 171 the CMP reply in the body of the HTTP response. The response status 172 code in this case MUST be 200; other 2xx codes MUST NOT be used for 173 this purpose. The HTTP responses with empty message body to pushed 174 CMP Announcement messages also utilize the status codes 201 and 202 175 to identify if the information was properly processed. 177 Note that a server may return any 1xx, 3xx, 4xx, or 5xx status code 178 if the HTTP request needs further handling or is otherwise not 179 acceptable. 181 3.4. Media Type 183 The Internet Media Type "application/pkixcmp" MUST be set in the HTTP 184 header when conveying a PKIMessage. 186 3.5. Communication Workflow 188 In CMP most communication is initiated by the end entities where 189 every CMP request triggers a CMP response message from the CA or RA. 191 The CMP Announcement messages described in Section 3.7 are an 192 exception. Their creation may be triggered by events or generated on 193 a regular basis by a CA. The recipient of the Announcement only 194 replies with an HTTP status code acknowledging the receipt or 195 indicating an error but not with a CMP response. 197 If the receipt of an HTTP request is not confirmed by receiving an 198 HTTP reply it MUST be assumed that the request was not successfully 199 delivered to its estination. 201 3.6. HTTP Request-URI 203 The Request-URI is formed as specified in [RFC3986]. 205 Client requests containing a PKI message MUST be directed to an 206 Request-URI depicting a directory. A server implementation MUST 207 handle Request-URIs with or without a trailing slash as identical. 208 The following list contains all such CMP message types. The prefixed 209 numbers reflect ASN.1 numbering of the respective element. 211 [0] Initialization Request 212 [2] Certification Request 213 [4] PKCS-10 Request 214 [6] pop Response 215 [7] Key Update Request 216 [9] Key Recovery Request 217 [11] Revocation Request 218 [13] Cross-Certification Request 219 [15] CA Key Update Announcement 220 [16] Certificate Announcement 221 [17] Revocation Announcement 222 [18] CRL Announcement 223 [20] Nested Message 225 [21] General Message 226 [23] Error Message 227 [24] Certificate Confirmation 228 [25] Polling Request 230 An example of a Request-Line and a Host header field in an HTTP/1.1 231 header, sending a CMP request to a server, located in the "/cmp" 232 directory of the host example.com, would be 234 POST /cmp HTTP/1.1 235 Host: example.com 237 or in the absoluteURI form 239 POST http://example.com/cmp/ HTTP/1.1 240 Host: example.com 242 A CMP server may be logically located either inside the root- or 243 within subdirectories of an HTTP server. As default, the path should 244 end in a "cmp" directory. 246 3.7. Announcements 248 A CMP server may create event-triggered announcements or generate 249 them on a regular basis. It MAY also utilize HTTP transport to 250 convey them to a suitable recipient. They can either be pushed to 251 the recipient or polled from the HTTP CMP server. 253 3.7.1. Pushing of Announcements 255 The ASN.1 encoded structures are sent as the entity-body of an HTTP 256 POST request. 258 Suitable recipients for CMP announcements might e.g. be repositories 259 storing the announced information such as directory services. Those 260 listen for incoming messages, utilizing the same HTTP Request-URI 261 scheme as defined in Section 3.6. 263 The following PKIMessages are announcements that may be pushed by a 264 CA. The prefixed numbers reflect ASN.1 numbering of the respective 265 element. 267 [15] CA Key Update Announcement 268 [16] Certificate Announcement 269 [17] Revocation Announcement 270 [18] CRL Announcement 272 CMP announcement messages do not require any CMP response. However, 273 the recipient MUST acknowledge receipt with a HTTP response having an 274 appropriate status code and an empty body. The sending side should 275 assume the delivery unsuccessful without such reply and retry if 276 applicable after waiting for an appropriate time span. 278 If the announced issue was successfully stored in a database or was 279 already present, the answer MUST be an HTTP response with a "201 280 Created" status code and empty message body. 282 In case the announced issue was only stored for further processing, 283 the status code of the returned HTTP response must be "202 Accepted". 284 After an appropriate delay, the server may then try to send the 285 Announcement again and may repeat this until it receives a 286 confirmation that it had been successfully stored. The appropriate 287 duration of the delay and the option to increase it between 288 consecutive attempts should be carefully considered. 290 A receiver MUST answer with a suitable 4xx or 5xx HTTP error code 291 when a problem occurs. 293 3.7.2. Polling of Announcements 295 As an OPTIONAL feature a CA may provide CA Key Update Announcement, 296 Revocation Announcement and CRL Announcement messages for polling 297 using HTTP GET requests. This is not to be confused with the 298 "Polling Request and Response" mechanism defined by CMP. 300 The server replies with the requested Announcement as the body of a 301 HTTP response having a 200 status code. If no suitable announcement 302 message is available, an HTTP "404 Not Found" error code MUST be 303 returned. 305 Query components are formed according to [RFC3986]. Their start is 306 indicated by the first question mark in the Request-URI and they are 307 containing "key=value" pairs. Hexadecimal representations of ASN.1 308 strings used as value MAY contain lower or upper case letters and are 309 neither grouped nor prefixed. 311 The given examples are for a self-signed certificate with the common 312 name (OID 2.5.4.3) "Example CA", the keyIdentifier in hexadecimal 313 representation BE911E711EDB685BF94D9B176A1BC715CE51D794 and the 314 serial number 008F8B7E383D88327C. 316 3.7.2.1. CA Key Update Announcement 318 When updating its key pair, a CA can produce a CA Key Update 319 Announcement Message that can be made available to the relevant end 320 entities. This is described as "Root CA Key Update" in E.4 of 322 [RFC4210]. 324 A CMP server may provide this message via an HTTP GET request for the 325 CAKeyUpdAnn.PKI file in the respective server's path. The 326 identification of the old key in question is created according to the 327 Authority Key Identifier as defined in chapter 4.2.1.1 of [RFC5280]. 328 The query component then consists of one single "key=value" pair, 329 having the string "AuthorityKeyIdentifier" as key, and the 330 hexadecimal representation of the ASN.1 AuthorityKeyIdentifier 331 sequence as value. 333 An example of the query component, when requesting a CA Key Update 334 Announcement Message for an old key identified with the 335 AuthorityKeyIdentifier 303C8014BE911E711EDB685BF94D9B176A1BC715CE51D7 336 94A119A4173015311330110603550403130A4578616D706C652043418209008F8B7E3 337 83D88327C 339 ?AuthorityKeyIdentifier=303C8014BE911E711EDB685BF94D9B176A1BC715CE 340 51D794A119A4173015311330110603550403130A4578616D706C65204341820900 341 8F8B7E383D88327C 343 3.7.2.2. Revocation Announcement 345 A CMP server MAY permit subjects to poll for a Revocation 346 Announcement using HTTP means. This enables a subject to determine 347 if its certificate is about to be (or has been) revoked. 349 The Request-URI of the HTTP GET targets the RevAnn.PKI file in the 350 respective server's path. The query component contains two 351 "key=value" pairs identifying the certificate in question: 352 o an "issuer" key with the hexadecimal representation of the 353 certificate's issuer's GeneralNames ASN.1 sequence as value 354 o a "serialNumber" key with the hexadecimal representation of the 355 certificate's serial number 357 An example of the query component, when requesting a Revocation 358 Announcement of a certificate issued by "Example CA" having the 359 decimal serialNumber 6699 would be: 361 ?issuer=3015311330110603550403130A4578616D706C65204341& 362 serialNumber=1A2B 364 3.7.2.3. CRL Announcement 366 A CMP server MAY offer the possibility to poll for the latest CRL 367 Announcement of a specific CA. 369 The Request-URI targets the CRLAnn.PKI file. The query component 370 consists of one one "key=value" pair containing an "issuer" key with 371 the hexadecimal representation of the CA's GeneralNames' ASN.1 372 sequence as value. 374 An example of a Request-URI for the latest CRL Announcement of 375 "Example CA" from a CMP server located in the "/cmp" directory of the 376 host example.com would be 378 http://example.com/cmp/ 379 CRLAnn.PKI?issuer=3015311330110603550403130A4578616D706C65204341 381 3.8. HTTP Considerations 383 In general, CMP messages are not cachable; requests and responses 384 MUST include a "Cache-Control: no-cache" (and, if either side uses 385 HTTP/1.0, a "Pragma: no-cache") to prevent the client from getting 386 cached responses. 388 Connection management is based on the HTTP provided mechanisms 389 (Connection and Proxy-Connection header fields). 391 While an implementation MAY make use of all defined features of the 392 HTTP protocol, it SHOULD keep the protocol utilization as simple as 393 possible. 395 There is no need for the clients to send an Expect request-header 396 field with the "100-continue" expectation and wait for a 100 397 (Continue) status as described in chapter 8.2.3 of [RFC2616]. The 398 CMP payload sent by a client is relatively small, so having extra 399 messages exchanged is more inefficient as the server will anyway only 400 seldomly reject the message without looking at the body. 402 Content codings MAY be applied. 404 3.9. Compatibility Issues with Legacy Implementations 406 As this document was subject of multiple changes during the long 407 period of time it was created in, implementations using a different 408 approach for HTTP transport may exist. While only those 409 implementations according to this specification are compliant, 410 implementers should to be aware that there might be existing ones 411 which behave differently. 413 Legacy implementations might also use an unregistered "application/ 414 pkixcmp-poll" MIME type as it was specified in earlier drafts of this 415 document. Here, the entity-body of an HTTP POST request contains the 416 DER-encoded PKIMessage prefixed by an additional "TCP-Messaging" 417 protocol. TCP-Messaging was described in draft versions of this 418 document but was removed. 420 4. Security Considerations 422 The following aspects need to be considered by server side 423 implementers: 425 1. There is the risk for denial of service attacks through resource 426 consumption by opening many connections, therefore idle 427 connections should be terminated after an appropriate timeout, 428 maybe also depending on the available free resources. After 429 sending a CMP Error Message, the server should close the 430 connection even if the CMP transaction is not yet fully 431 completed. 433 2. There is no security at the HTTP protocol level (unless tunneled 434 via TLS) and thus information from the HTTP protocol SHOULD NOT 435 be used to change state of the transaction. Change of state 436 SHOULD be triggered by signed PKIMessages only. 438 5. Information Security Considerations 440 CMP provides inbuilt integrity protection and authentication. Due to 441 the nature of a PKI, from a security perspective the information 442 communicated unencrypted does not contain sensitive information. 444 However, it might be possible for an interceptor to utilize the 445 available information to gather confidential technical or business 446 critical information. Therefore, users of the HTTP CMP transport 447 might want to use HTTP over TLS according to [RFC2818] or should 448 consider to use virtual private networks created e.g. by utilizing 449 Internet Protocol Security according to [RFC4301]. 451 6. IANA Considerations 453 The IANA has already registered TCP and UDP port 829 for "PKIX-3 454 CA/RA" and the MIME media type "application/pkixcmp" for identifying 455 CMP sequences. 457 No further action by the IANA is necessary for this document or any 458 anticipated updates. 460 7. References 462 7.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 468 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 469 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 471 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 472 Resource Identifier (URI): Generic Syntax", STD 66, 473 RFC 3986, January 2005. 475 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 476 "Internet X.509 Public Key Infrastructure Certificate 477 Management Protocol (CMP)", RFC 4210, September 2005. 479 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 480 Housley, R., and W. Polk, "Internet X.509 Public Key 481 Infrastructure Certificate and Certificate Revocation List 482 (CRL) Profile", RFC 5280, May 2008. 484 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 485 October 2008. 487 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 488 Languages", BCP 47, RFC 5646, September 2009. 490 7.2. Informative References 492 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 493 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 495 [RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode 496 Plain Text", RFC 2482, January 1999. 498 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 499 Infrastructure Certificate Management Protocols", 500 RFC 2510, March 1999. 502 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 504 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 505 Internet Protocol", RFC 4301, December 2005. 507 Appendix A. Acknowledgments 509 Until the fifth draft version of this document, released in November 510 24th 2000, the sole authors were Amit Kapoor and Ronald Tschlaer from 511 Certicom. Up to this point the now removed TCP-Based transport was 512 described in detail. They are not available for this working on this 513 document anymore at the time it is entering the "Authors Final Review 514 state AUTH48". As they therefore cannot approve this document as it 515 would be necessary, their names were moved to this section. Their 516 contact data, as originally stated by them, is as follows: 518 Amit Kapoor 519 Certicom 520 25801 Industrial Blvd 521 Hayward, CA 522 US 523 Email: amit@trustpoint.com 525 Ronald Tschalaer 526 Certicom 527 25801 Industrial Blvd 528 Hayward, CA 529 US 530 Email: ronald@trustpoint.com 532 The authors gratefully acknowledge the contributions of various 533 members of the IETF PKIX Working Group and the ICSA CA-talk mailing 534 list (a list solely devoted to discussing CMP interoperability 535 efforts). 537 By providing ideas, giving hints and doing invaluable review work, 538 the following individuals, listed alphabetically, have significantly 539 contributed to this document: 541 Tomas Gustavsson, Primekey 542 Peter Gutmann, University of Auckland 543 Wolf-Dietrich Moeller, Nokia Siemens Networks 545 Appendix B. Registration of the application/pkixcmp Media Type 546 To: ietf-types@iana.org 547 Subject: Registration of MIME media type application/pkixcmp 549 MIME media type name: application 551 MIME subtype name: pkixcmp 553 Required parameters: - 555 Optional parameters: - 557 Encoding considerations: 559 Content may contain arbitrary octet values (the ASN.1 DER encoding 560 of a PKIMessage sequence, as defined in the IETF PKIX Working Group 561 specifications). base64 encoding is required for MIME e-mail; no 562 encoding is necessary for HTTP. 564 Security considerations: 566 This MIME type may be used to transport Public-Key Infrastructure 567 (PKI) messages between PKI entities. These messages are defined by 568 the IETF PKIX Working Group and are used to establish and maintain 569 an Internet X.509 PKI. There is no requirement for specific 570 security mechanisms to be applied at this level if the PKI messages 571 themselves are protected as defined in the PKIX specifications. 573 Interoperability considerations: - 575 Published specification: this document 577 Applications which use this media type: Applications using 578 certificate management, operational, or ancillary protocols (as 579 defined by the IETF PKIX Working Group) to send PKI messages via 580 E-Mail or HTTP. 582 Additional information: 584 Magic number (s): - 585 File extension (s): ".PKI" 586 Macintosh File Type Code (s): - 588 Person and email address to contact for further information: 589 Martin Peylo, martin.peylo@nsn.com 591 Intended usage: COMMON 593 Author/Change controller: Martin Peylo 595 Authors' Addresses 597 Tomi Kause 598 Tectia Corporation 599 Fredrikinkatu 42 600 Helsinki 00100 601 Finland 603 Email: toka@tectia.com 605 Martin Peylo 606 Nokia Siemens Networks 607 Linnoitustie 6 608 Espoo 02600 609 Finland 611 Email: martin.peylo@nsn.com