idnits 2.17.1 draft-arnold-scmp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-arnold-scmp-08.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-arnold-scmp-08.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-arnold-scmp-08.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-arnold-scmp-08.txt)', but the file name used is 'draft-arnold-scmp-08' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 782 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 26, 2001) is 8429 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PKCS-7' is defined on line 768, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 1119 (ref. 'NTP') (Obsoleted by RFC 1305) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 13 errors (**), 1 flaw (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Tom Arnold (CyberSource) 2 Category: Informational Jason Eaton (Jungawunga.com) 3 March 26, 2001 4 Expires in six months 6 Simple Commerce Messaging Protocol (SCMP) 7 Version 1 Message Specification 8 (draft-arnold-scmp-08.txt) 10 Status of this Memo 12 This memo provides information for the Internet community. It does 13 not specify an Internet standard of any kind. Distribution of this 14 memo is unlimited. 16 This document is an Internet-Draft and is in full conformance 17 with all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Introduction 37 The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 38 electronic commerce message protocol for secure, real-time 39 communication of a set of data from a sending agent's application 40 to a receiving agent's server. Additionally the response by the 41 receiving agent's server to the sending agent is the reply from the 42 request represented by the set of data in the message's payload. The 43 intent of this protocol is to define a method where trading partners 44 can perform on-line business requests in an environment where the sending 45 partner is fully authenticated, and the message cannot be repudiated. 47 The taxonomy of the SCMP message payload is not in the scope of this 48 document. The SCMP protocol does not specify payload definitions or 49 how trading partners are expected to process the payload, beyond basic 50 server-level functions related to processing SCMP headers. This intent 51 is to permit trading partners the flexibility to implement either a 52 standard commerce message format as in ANSI-X12 Electronic Data 53 Interchange (EDI) or some other non-standard payload format. This 54 document does give an example implementation of a payload format 55 based on [XML]. 57 The only requirement on the message payload is that it be prepared 58 as specified in [SMIME] section 3.1. 60 In this manner, SCMP fundamentally differs from many emerging 61 commerce message protocols. Beyond specifying the method for 62 encryption, authentication and handling, these other protocols 63 specify the contents of the message and details how a server is to 64 process and respond to a given message payload. 66 In this version of the protocol, a requirement has been added that 67 describes the process trading partners will implement to agree on 68 payload content formats. To this end, section 2.2.2 has been modified 69 to accommodate the identification of payload content format, and an 70 appropriate example has been appended. 72 NOTE from the Authors: 74 Our intent has always been to propose a secure, request and reply 75 messaging protocol that is unencumbered by the negotiation and 76 debates around commerce message content (payload). One need only 77 consider the number of proposed credit card payment "standards" 78 to become fully embroiled in this issue. 80 By including a requirement related to the negotiation and agreement 81 on a payload format along with implementation specifications, we 82 intend to complete this specification so as to facilitate 83 implementations and interoperability. 85 We fully recognize that businesses will evaluate the proposed content 86 standards from industry consotiums, IETF, RosettaNet, CompTIA and 87 others then decide on a payload format that meets their requirements. 88 >From this point, we feel SCMP is well suited as a method to implement 89 the transaction messaging between their busines and other businesses. 91 1.1. Terminology 93 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD 94 NOT are used in conformance to the definitions in RFC2119 [MUSTSHOULD]. 96 1.2. Definitions Several terms will be used when specifying SCMP. 98 Trading Partners Two entities wishing to perform some on-line 99 request processing where authentication, 100 privacy, integrity and non-repudiation of the 101 requests are important. Trading partners have 102 established a trusted relationship between each 103 other. 105 Client An application program that executes on a remote 106 system, used by a trading partner to request 107 services from a server via an untrusted or 108 publicly switched packet network, like the 109 Internet. 111 Server An application program used to process SCMP 112 messages received from a client, and generate 113 appropriate replies which are sent back to the 114 client. 116 Sending Agent An entity that operates or uses a Client for 117 requesting on-line services from a server. 119 Receiving Agent An entity that operates a Server, receives and 120 processes requests from a plurality of Clients. 122 Request An SCMP formatted message containing a set of 123 directives set in a textual form requesting a set 124 of directives be executed on behalf of the sending 125 agent. 127 Reply An SCMP formatted message containing a set of 128 result data generated as a result of processing an 129 SCMP request. 131 Payload The meaningful content provided by a client to a 132 server, encapsulated in an SCMP message. Similarly 133 the meaningful content provided by a server to a 134 client, encapsulated in an SCMP message. 136 Services Groups of operations and/or algorithms implemented 137 by the server application which are executed as 138 designated by the payload. Each available group of 139 operations and/or algorithms is a service. 141 1.3. Document Overview 143 This document describes SCMP from the standpoint of how trading partners 144 would implement a client/server request processing system via an 145 untrusted network connection. 147 In a on-line, electronic commerce environment, trading partners require 148 a scalable, message handling system that will meet these minimum 149 requirements: 151 1.3.1 Real-time Request and Response 153 A single message containing all credentials and payload data is 154 prepared by a sending agent and sent to a receiving agent. The 155 receiving agent, upon verification of sender's credentials, SHOULD 156 process the payload, format a reply, and respond to the sender as 157 the response to the request. 159 1.3.2 Message Privacy 161 Through use of cryptographic methods, the privacy of the sender's 162 message payload MUST be assured in the event a message payload is 163 intercepted. 165 1.3.3 Message Integrity 167 If a message arrives in an incomplete or tampered condition from a 168 sending agent, the receiving agent's server MUST detect the condition, 169 deny message payload processing, and respond with an appropriate 170 error message. 172 1.3.4 Authentication of Sending and Receiving Agents 174 Messages between trading partners, as represented by sending and 175 receiving agents, MUST contain attributes that assure a given request 176 could only be from a specific trading partner. Additionally SCMP 177 requests and SCMP replies MUST be authenticated. 179 Prior to performing any application functions on a SCMP request 180 payload, the receiving agent's server MUST verify that the request has 181 been made by an authorized sender. 183 1.3.5 Non-repudiation 185 When a receiving agent's server receives a request to process a payload, 186 the receiving agent's application SHOULD guarantee that the sender 187 cannot, at some later time, refute having sent the request. 189 Non-repudiation is defined as, the inability of either trading partner 190 (sender or receiver) to refute the sending of an SCMP request or SCMP 191 reply. 193 An Electronic Commerce provider will typically provide financial based 194 functionality such as authorization, settlement, and crediting, of 195 credit card accounts and/or merchant accounts. This functionality 196 requires that the Electronic Commerce Provider execute financial 197 transactions on behalf of the merchant, or trading partner. Therefore it 198 is desirable that the transaction directives which are given in an SCMP 199 message are non-refutable. 201 1.3.6 Payload Independence 203 The messaging system SHOULD perform consistently for all payload formats. 205 1.3.7 Standards Based 207 The messaging protocol SHOULD be based on proven, existing cryptography 208 and Internet standards. 210 1.3.8 Use of Standard Credentials 212 Standard credential formats SHOULD be used to maximize interoperability 213 of common Public Key Infrastructures. 215 1.3.9 Transport Independent 217 The message SHOULD be transportable over the most common Internet 218 transport protocols. 220 1.3.10 Service Level Guarantee 222 The receiving agent SHOULD guarantee a response within the time 223 designated by the sender, or reject the message with an appropriate 224 error message. 226 1.3.11 State Independence 228 State dependency by either a sender's or receiver's application SHOULD 229 be minimalized as to support multiple transport mechanisms. 231 1.3.12 Payload Content Agreement 233 The sending agent MUST agree to create message payloads in a format 234 that is acceptable to the receiving agent's application server. This 235 agreement can take a few different forms: 237 - Receiving agent publishes a private payload specification. This 238 specification MUST define the application(s) that will be offered, 239 all input and output data formats, processing rules and other 240 information about the application behavior. The value for 241 "SCMP-message-type" (see Section 2.2.2 in this document) will have 242 the word "private-" prepended to any distinct value. Example: 244 "SCMP-message-type: private-CYBSCommerceService/1.0" 246 - Receiving agent agrees to accept transactions that comply with a 247 published industry standard or consortium format. The value for 248 "SCMP-message-type" (see Section 2.2.2 in this document) will have 249 the word "std-" prepended to any distinct value. Example: 251 "SCMP-message-type: std-CXML/1.0.2" 253 - Receiving agent agrees to implement data format from sending agent's 254 published specification. A local value for "SCMP-message-type" MUST 255 be agreed to and implemented. Further, the word "private-" MUST be 256 prepended to the value. Example: 258 "SCMP-message-type: private-userCompanyShippingManifest/2.1" 260 - Receiving agent agrees to implement a data format that is a combination 261 of any the aforementioned forms. In this situation, the value for 262 "SCMP-message-type" header will be set by the sending agent's client 263 application to appropriately match the data format for the message 264 payload. There MUST NOT be a requirement that an individual trading 265 partner relationship use one and only one payload format. Different 266 formats MAY be used to accommodate different application functions. 268 2. SCMP Message Construction 270 The payload of an SCMP message is divided into two parts. The outer 271 SMIME entity that contains the cryptographically enhanced payload and 272 the inner MIME encapsulation of the payload. In this way the inner MIME 273 message can be enveloped protecting the header information which may 274 contain sensative data. 276 All of the header fields defined in this document are subject to the 277 general syntactic rules for header fields specified in [RFC822]. 279 Both the sending agent and receiving agent MUST specify all SCMP 280 headers specified in this document. 282 2.1 Outer SMIME Message Construction 284 The outer SMIME message MUST be constructed in accordance with [SMIME] 285 section 3.1. An SCMP compliant server SHOULD implement the three 286 message types as described in [SMIME], signed, enveloped, and 287 signed/enveloped. An SCMP compliant server MUST implement 288 signed/envelope message type as described in [SMIME]. 290 For non-repudiation concerns, the trading partners MUST exchange 291 signed or signed/enveloped SCMP message types. 293 SCMP error messages MUST be of signed type and NOT encrypted. 295 In addition to the headers listed below use of any additional standard 296 SMIME and MIME headers are assumed. These headers will most likely be 297 ones that need to be processed prior to payload decryption. 299 2.1.1 SCMP Protocol Version 301 The SCMP-protocol-version header is used to designate the SCMP protocol 302 version. Server implementations MAY reject the request based upon 303 protocol version, before any message processing occurs. 305 An example SCMP-protocol-version header will be in this format: 307 SCMP-protocol-version: 2.0 309 The value of the protocol-version header MUST be in the following 310 format, any number of digits, followed by a the special character ".", 311 followed by any number of digits. Where special character, and digits is 312 defined in [RFC822]. 314 If a particular protocol version is not supported by the implimentation, 315 the receiving agent MUST reject the request with an appropriate SCMP 316 error message. 318 2.2 Inner MIME Message Construction 320 The payload of an SCMP message MUST be prepared as a standard MIME 321 entity as defined in the [MIME] specification. 323 The remainder of this section describes the payload-based extensions 324 that MUST be implemented by both the client and server to ensure 325 correct and proper request processing. 327 Setting the SCMP service headers is the responsibility of the sending 328 agent's client application. Processing the SCMP payload headers is the 329 responsibility of the receiving agent's server application processing 330 the request. 332 The following headers are described for the inner MIME entity which 333 contains the payload. Thus if the SMIME message type is signed/enveloped 334 (which is recommended), then the SCMP headers will be encrypted with 335 the sender's message payload. 337 Both the sending agent and receiving agent MUST specify all SCMP 338 headers specified in this document. 340 2.2.1. Request Time to Live 342 This describes the amount of actual processing time in seconds the 343 client expects the server to complete payload processing prior to 344 responding with an appropriate reply. 346 An SCMP server receiving a SCMP message MUST evaluate the request time 347 to live value and determine if it can execute the required service(s) 348 in the amount of time designated. Assuming the server believes it can 349 complete the work within the allowed time, it will accept the request. 350 If not, the server MUST return an error to the client stating it 351 could not accept the request. 353 Once a server has accepted a request, it MUST process it until the time 354 to live value has been reached or until completion. If the time to live 355 value is reached during execution, the server MUST return an error to 356 the client stating that a time-out has occurred. 358 Application functions to ensure data consistency, integrity, or 359 rollback after the time to live value has been exceeded will be the 360 responsibility of the server application. A policy on what application 361 actions a server will take upon exceeding a time to live value SHOULD 362 be published by the receiving agent operating the server. 364 An example of a policy in this are would be one where a receiving 365 agent's server will continue processing the request after a request 366 time to live value has been exceeded. Given this policy, a client, 367 having received a time-out error message, would send a "request 368 status message" to the server, referencing the original 369 scmp-request-id (from the message that timed out) in the message 370 payload. The server's reply to this status message would be the reply 371 that would have been sent had the processing time not exceeded the 372 time to live metric. 374 The time to live header will be in this format: 376 SCMP-request-time-to-live: 90 378 Where the value of the time-to-live header is a digit or digit(s) as 379 specified in [RFC822]. The value of the time-to-live is represented 380 as any number of digit(s) which will designate a number of seconds. 382 2.2.2. Message Type 384 This value specifies the type of payload that is contained in the SCMP 385 message. The intent of this header is to provide a meta-level 386 description of the message payload and allow a receiving server to 387 decide which services or associated algorithms to use in processing 388 the payload. 390 Message type is specified as follows: 392 SCMP-message-type: [service-name]/[version-number] 394 Where service-name is text as specified in [RFC822] and version-number 395 is a digit or digit(s), followed by the special character ".", followed 396 by a digit or digit(s). Where digit and special character are defined in 397 [RFC822]. 399 For instance, if a service was published called "CommerceService", the 400 SCMP-message-type would be represented as: 402 SCMP-message-type: private-CYBSCommerceService/1 404 Trading partners MUST agree on payload data formats and the distinct 405 value for the SCMP-message-type field before requests are processed. 407 If a particular message type is not supported by the implimentation, 408 the receiving agent MUST reject the request with an appropriate SCMP 409 error message. 411 2.2.3. Request ID 413 Request ID's MUST be generated by the client application, thus 414 assuring that the scmp-request-id is available in the event that the 415 request cannot be sent to the server due to errors. 417 The format of value of the request id header is 22 digits, where 418 digits is defined by [RFC822]. 420 An example of a request scmp-request-id is: 422 scmp-request-id: 0917293049096167904518 424 The scmp-request-id MUST be unique in the domain of a client 425 application and SHOULD NOT be easy to predict so as to prevent a 426 potential replay attack. 428 A client application, when preparing the scmp-request-id, SHOULD 429 perform a random number generation with sufficient degrees of 430 randomness, to ensure unpredictability, and generate a client side 431 time value, to ensure uniqueness of the result. These two data items 432 together SHOULD form the resulting scmp-request-id. 434 Servers MAY use a scmp-request-id as a reference and handle to the 435 original request during server message processing. 437 Servers MUST return the submitted request id back to the client via 438 the SCMP reply message in the SCMP-request-id header. 440 3. Transport Implementations 442 SCMP can be implemented using any variety of transport methods as 443 defined by the service provider. Here are a few examples. 445 HTTP: This delivers a SCMP message to a server URL and SHOULD 446 use a POST function. Used in this manner the SCMP reply 447 would be the entity-body of the HTTP response. SCMP error 448 messages would be the entity-body of the HTTP response. 450 SMTP: This will support a queued batch processing service. Used 451 in this manner the SCMP messages would be the body of the SMTP 452 message. SCMP error messages would be sent in the body of the 453 SMTP message. 455 4. Receiving Server Functions 457 This section describes minimal server functions required to implement 458 SCMP. 460 4.1. General 462 A SCMP server receives a message from a client, processes the message 463 and generates a reply. If the message type is signed or signed/enveloped 464 the server initially validates the outer signature. If the outer 465 signature is not valid the server MUST NOT process the request further. 467 4.1.1. Message Timestamp 469 The time a request was received SHOULD be derived from the environment 470 which recieves the message. Clients and servers SHOULD be synchronized 471 using [NTP] or Secure NTP. 473 The message timestamp SHOULD be used, in combination with the 474 scmp-request-id, by the server to aid in detection of a potential 475 replay attack. 477 It is recommended that servers SHOULD run a client-visible NTP server 478 to allow SCMP client applications to synchronize clocks as required. 480 4.1.2 Support for Request Non-Repudiation 482 Support for non-repudiation MUST be included in any complete SCMP 483 implementation, as described in the following subsections. 485 Implemenations MAY support non-repudation of error message replies. 486 This document addresses the non-repudation concerns of the server or 487 receiving agent. The non-repudiation concerns of of the client or 488 sending agent MAY be fulfilled by the same means as the server or 489 receiving agent supports non-repudiation. 491 4.1.2.1 Client Message Signing 493 The client application MUST send signed or signed/enveloped message type 494 as specified in [SMIME]. 496 4.1.2.2 Server Message Signing 498 The server application MUST send signed or signed/enveloped message type 499 as specified in [SMIME]. 501 4.1.2.3 Server Processing 503 The receiving agent's server application evaluates the digital 504 signature, thereby guaranteeing that the message payload has not been 505 altered in transit, and that the message was, in fact, signed by a 506 specific trading partner (client) who possess the proper credentials. 508 4.1.2.4 Server Accounting 510 The receiving agent's server application MUST store the original signed/ 511 encrypted message in an unprocessed state along with the timestamp for 512 identifying when the message was received. 514 4.1.2.5 Client Accounting 516 The sending agent's client application MAY store the original signed/ 517 encrypted message in an unprocessed state along with the timestamp for 518 identifying when the message was received. 520 4.1.2.6 Revocation 522 All messages signed by a sending agent's client application in 523 accordance with [SMIME] and sent to a receiving agent's server SHALL be 524 considered non-repudiable. 526 To satisfy the non-repudiation requirements, the receiver of the message 527 MUST support revocation mechanisms for the certificates of the potential 528 senders of the SCMP messages that are accepted by the server application. 530 4.2. Application issues 532 The server MUST evaluate the signature of the message, if the message 533 is of signed or signed/enveloped type, prior to processing the message 534 payload. In performing this authentication process, the server MUST 535 validate the senders certificate and verify that the senders certificate 536 is not listed in any available revocation systems. 538 Assuming the SCMP message's signature is valid, the server will process 539 requests with the appropriate service designated by the SCMP-message-type value. 541 4.2.1. Request Serialization 543 A server SHOULD NOT guarantee serialized request processing. If request 544 serialization is a application requirement, it is expected that all of 545 the serialized transactions will be received in a single message payload 546 or that other content specific serialization systems will be used. 548 4.2.2. Server Errors 550 During application processing, a server could encounter several classes 551 of error conditions. The server MUST be capable of reporting an error as 552 described in section 5 of this document. Error Detection may vary based 553 on specific implementation. 555 Additionally, a server MUST be capable of detecting a duplicate scmp- 556 request-id and reply to the sending client application with an 557 appropriate SCMP error message. Duplicate request detection MUST be 558 based on the scmp-request-id and the distinguished name of the signer to 559 prevent potential denial of service attacks. 561 5. Protocol Level Error Messages 563 In general SCMP does not concern itself with application level errors. 564 Such errors SHOULD be returned in an SCMP reply with appropriate 565 application specific formatting. 567 5.1. Format 569 SCMP error messages MUST be signed SMIME messages. SCMP errors 570 MUST NOT be encrypted to permit clients to process encryption related 571 errors. 573 The format of SCMP errors is: 575 SCMP 577 Where the format of "error number" is a digit or digits as defined in 578 [RFC822] and "error message text" is text as defined in [RFC822]. 580 5.2. Client Application Error Handling 582 Client action in the case of error return is error specific and not 583 defined. If the server fails to return any reply within the time to 584 live requested (due to unspecified server or network failure) the 585 client MAY re-send the request. Clients MUST NOT retry a request in 586 an interval which is less than the time to live value of the original 587 request. 589 6. Security Considerations 591 Security considerations are addressed throughout this document. 593 6.1 Encryption Strength 595 It is recommended that strong enough cryptographic methods be used to 596 ensure authenticity, integrity, non-repudiation, and privacy of the 597 payload. 599 6.2 Non-repudiation 601 Non-repudation implimentation is specified in section 4.1.2. 603 As addressed above, this document does not describe how a sending agent 604 may support non-repudiation. The intent of this document does describe 605 how a receiving agent can support non-repudiation. 607 If the receving agent accepts and processes a transaction after the 608 private key of the sending agent has been comprimised, that request is 609 refutable, or not non-refutable. 611 6.3 Public Certificate Considerations 613 6.3.1 Certificate Exchange 615 Every trading partner implementing SCMP SHOULD exchange certificates 616 that have been issued and signed by one or more mutually trusted 617 certificate authorities. Prior to establishing trading partner 618 relationships, the sender and receiver SHOULD acquire mutually 619 acceptable public root certificates from the agreed upon certificate 620 authority or authorities. 622 Sending and receiving agents MAY utilize certificate only messages to 623 exchange certificates as specified in [SMIME]. 625 6.3.2 Certificate Authentication and Revocation 627 Trading partners, upon receiving or exchanging public key certificates 628 for the first time, SHOULD validate the certificate and certificate 629 chain before processing an SCMP request. 631 A server certificate revalidation policy, related to the frequency 632 certificates are revalidated against a certificate authority's 633 certificate revocation list, is not specified by SCMP. This matter is 634 left as a policy decision for the operator of the SCMP server. 636 The timestamp of a certificate revocation event SHOULD be the time the 637 private key was known to be comprimised, or the time that the revocation 638 event was made. 640 6.4 Private Key Considerations 642 6.4.1 Private Key Generation 644 Private key generation SHOULD be of a secure manner as not to jepordize 645 the integrety of the private key. 647 6.4.2 Private Key Storage 649 The sending agent, maintaining a SCMP client application, MUST 650 maintain the private key in a secure location. 652 6.4.3 Private Key Revocation 654 Should a sending agent loose control of their private key, they MUST 655 notify the agreed upon, trusted, certificate authority. This 656 notification mechanism is not defined in this document, and SHOULD 657 be done via an out of band mechanism. 659 6.5 Request Id 661 The request id MUST be unique as to prevent possible replay attack 662 senarios. 664 7. SCMP Message Example 666 [ OUTER MIME START ] 667 Content-Type: application/pkcs7-mime 668 Content-Transfer-Encoding: base64 669 Content-Length: 1024 670 SCMP-protocol-version: 2.0 672 [ INNER MIME START - enveloped entity ] 673 SCMP-request-time-to-live: 90 674 SCMP-message-type: private-CYBSCommerceService/2.0 675 SCMP-request-id: 0123456789012345678901 676 Content-Type: application/pkcs7-mime 677 Content-Transfer-Encoding: base64 678 Content-Length: 512 680 [SIGNEDPAYLOAD - a SignedData with payload as encapsulatedContent] 681 [ INNER MIME END ] 682 [ OUTER MIME END ] 684 8. XML Payload Example 686 This section is intended to be an example implementation of a payload 687 and is NOT required for this protocol. The parties communicating could 688 agree on two "scmp-message-type" values. The first would be the exchange 689 of the DTD template, ( ie. scmp-message-type=widget xml definition ). 690 The second could be the actual data generated from that template, ( ie. 691 scmp-message-type=widget xml data ). The DTD would be transfered 692 defining the data format. The server could store the format for later 693 transferring of these types of messages. An example DTD follows. 695 696 697 698 699 700 701 703 This DTD would produce data as follows. 705 706 707 Widget Maker 708 709 0349003 710 711 713 This XML data would be the payload of the SCMP. When the agent recieves 714 this type of SCMP message they could validate the message format with 715 the previously received template. 717 9. Author's Address 719 Tom Arnold 720 CyberSource Corporation 721 1295 Charleston Road 722 Mountain View, CA 94043 723 E-mail: toma@cybersource.com 724 Phone: 650-965-6000 726 Jason Eaton 727 CyberSource Corporation 728 1295 Charleston Road Mountain View, CA 94043 729 E-mail: jeaton@cybersource.com 730 Phone: 650-965-6000 731 10. Acknowledgements 733 The authors wish to recognize and thank several individuals 734 (listed in alphabetic order) who have and continue to 735 support the development of requirements and improvement of 736 this protocol. 738 Mike Agostino (Vulcan), Ron Bose (LitleNet), David Burdett (Mondex), 739 Leonard Cantor (IBM), Dan Corcoran (Equifax), Steve Crocker 740 (Crocker Assoc.), Tony Curwen (Ingram Micro), Donald Eastlake (IBM), 741 Richard Frank (Intertrust), James Gavin (Commercenet), Paul 742 Guthrie (Brodia), Lauren Hall (SIIA), Bengamin Hipp 743 (FUSA/Paymentech), Andy Jeffrey (Sonnet Financial), Helle Jespersen 744 (IBM), Sean Kiewiet (Hypercom.com), Connie Lindgreen (IBM), 745 Michael Myers (VeriSign), Allan Ottosen (PBS), John Pettitt 746 (Beyond.com), Jesse Rendleman (CyberSource), Don Sloan 747 (Tech Data), Carl Stucke (Equifax), Frank Tyksen (Portland 748 Software), Huy Vu (VISA USA), Sean Youssefi (CobWeb) 750 11. References 752 [SMIME] B. Ramsdell, "S/MIME Version 3 Message 753 Specification", RFC 2633, IETF, June 1998. 755 [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 756 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 757 3: Message Header Extensions for Non-ASCII Text", RFC 758 2047; "MIME Part 4: Registration Procedures", RFC 759 2048; "MIME Part 5: Conformance Criteria and 760 Examples", RFC 2049, IETF. 762 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 763 Levels", RFC 2119, IETF. 765 [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, 766 September 1989. 768 [PKCS-7] B. Kaliski, "PKCS #7: Cryptograpic Message Syntax" 769 RFC 2315, IETF, March 1998. 771 [RFC822] D. Crocker, "Standard for the format of arpa internet 772 text messages", RFC 822, IETF, August 1982. 774 [X.520] "ITU-T Recommendation X.520: Information Technlogy - 775 Open Systems Interconnection - The Directory: 776 Selected Attributes Types, 1993. 778 [XML] Extensible Mark Up Language. See http://www.w3.org/TR