idnits 2.17.1 draft-arnold-scmp-04.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. ** Bad filename characters: the document name given in the document, 'draft-arnold-scmp-04.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-arnold-scmp-04.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-arnold-scmp-04.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-04.txt)', but the file name used is 'draft-arnold-scmp-04' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 725 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 3 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). == Unrecognized Status in 'Category: Application', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == 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 (October 5, 1999) is 8967 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) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. 'SMIME') ** Obsolete normative reference: RFC 1119 (ref. 'NTP') (Obsoleted by RFC 1305) ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. 'PKCS-7') ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 14 errors (**), 1 flaw (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Tom Arnold (CyberSource) 2 Category: Application Jason Eaton (CyberSource) 3 October 5, 1999 4 Expires in six months 6 Simple Commerce Messaging Protocol (SCMP) 7 Version 1 Message Specification 8 (draft-arnold-scmp-04.txt) 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 1. Introduction 34 The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 35 electronic commerce message protocol for secure, real-time 36 communication of a set of data from a sending agent's application 37 to a receiving agent's server. Additionally the response by the 38 receiving agent's server to the sending agent is the reply from the 39 request represented by the set of data in the message's payload. The 40 intent of this protocol is to define a method where trading partners can 41 perform on-line business requests in an environment where the sending 42 partner is fully authenticated, and the message cannot be repudiated. 44 The taxonomy of the SCMP message payload is not in the scope of this 45 document. The SCMP protocol does not specify payload definitions or 46 how trading partners are expected to process the payload, beyond basic 47 server-level functions related to processing SCMP headers. This intent 48 is to permit trading partners the flexibility to implement either a 49 standard commerce message format as in ANSI-X12 Electronic Data 50 Interchange (EDI) or some other non-standard payload format. This 51 document does give an example implementation of a payload format 52 based on [XML]. 54 The only requirement on the message payload is that it be prepared 55 as specified in [MIME]. 57 In this manner, SCMP fundamentally differs from many emerging 58 commerce message protocols. Beyond specifying the method for 59 encryption, authentication and handling, these other protocols 60 specify the contents of the message and details how a server is to 61 process and respond to a given message payload. 63 1.1. Document Overview 65 This document describes SCMP from the standpoint of how trading partners 66 would implement a client/server request processing system via an 67 untrusted network connection. 69 In a on-line, electronic commerce environment, trading partners require 70 a scalable, message handling system that will meet these minimum 71 requirements: 73 1.1.1 Real-time Request and Response 75 A single message containing all credentials and payload data is 76 prepared by a sending agent and sent to a receiving agent. The 77 receiving agent, upon verification of sender's credentials, should 78 process the payload, format a reply, and respond to the sender as 79 the response to the request. 81 1.1.2 Message Privacy 83 Through use of cryptographic methods, the privacy of the sender's 84 message payload should be assured should a message payload be 85 intercepted. 87 1.1.3 Message Integrity 89 If a message arrives in an incomplete or tampered condition from a 90 sending agent, the receiving agent's server should detect the condition, 91 deny message payload processing, and respond with an appropriate 92 error message. 94 1.1.4 Authentication of Sending and Receiving Agents 96 Messages between trading partners, as represented by sending and 97 receiving agents, must contain attributes that assure a given request 98 could only be from a specific trading partner. Additionally SCMP 99 requests and SCMP replies MUST be authenticated. 101 Prior to performing any application functions on a SCMP request 102 payload, the receiving agent's server MUST verify that the request has 103 been made by an authorized sender. 105 1.1.5 Non-repudiation 107 When a receiving agent's server receives a request to process a payload, 108 the receiving agent's application should guarantee that the sender 109 cannot, at some later time, refute having sent the request. 111 Non-repudiation is defined as, the inability of either trading partner 112 (sender or receiver) to refute the sending of an SCMP request or SCMP 113 reply. 115 An Electronic Commerce provider will typically provide financial based 116 functionality such as authorization, settlement, and crediting, of 117 credit card accounts and/or merchant accounts. This functionality 118 requires that the Electronic Commerce Provider execute financial 119 transactions on behalf of the merchant, or trading partner. Therefore it 120 is desirable that the transaction directives which are given in an SCMP 121 message are non-refutable. 123 1.1.6 Payload Independence 125 The messaging system should perform consistently for all payload formats. 127 1.1.7 Standards Based 129 The messaging protocol should be based on proven, existing cryptography 130 and Internet standards. 132 1.1.8 Use of Standard Credentials 134 Standard credential formats should be used to maximize interoperability 135 of common Public Key Infrastructures. 137 1.1.9 Transport Independent 139 The message should be transportable over the most common Internet 140 transport protocols. 142 1.1.10 Service Level Guarantee 144 The receiving agent should guarantee a response within the time 145 designated by the sender, or reject the message with an appropriate 146 error message. 148 1.1.11 State Independence 150 State dependency by either a sender's or receiver's application should 151 be minimalized as to support multiple transport mechanisms. 153 1.2. Terminology 155 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 156 are used in conformance to the definitions in [MUSTSHOULD]. 158 1.3. Definitions 160 Several terms will be used when specifying SCMP. 162 Trading Partners Two entities wishing to perform some on-line 163 request processing where authentication, 164 privacy, integrity and non-repudiation of the 165 requests are important. Trading partners have 166 established a trusted relationship between each 167 other. 169 Client An application program that executes on a remote 170 system, used by a trading partner to request 171 services from a server via an untrusted or 172 publicly switched packet network, like the 173 Internet. 175 Server An application program used to process SCMP 176 messages received from a client, and generate 177 appropriate replies which are sent back to the 178 client. 180 Sending Agent An entity that operates or uses a Client for 181 requesting on-line services from a server. 183 Receiving Agent An entity that operates a Server, receives and 184 processes requests from a plurality of Clients. 186 Request An SCMP formatted message containing a set of 187 directives set in a textual form requesting a set 188 of directives be executed on behalf of the sending 189 agent. 191 Reply An SCMP formatted message containing a set of 192 result data generated as a result of processing an 193 SCMP request. 195 Payload The meaningful content provided by a client to a 196 server, encapsulated in an SCMP message. Similarly 197 the meaningful content provided by a server to a 198 client, encapsulated in an SCMP message. 200 Services Groups of operations and/or algorithms implemented 201 by the server application which are executed as 202 designated by the payload. Each available group of 203 operations and/or algorithms is a service. 205 2. Payload Encapsulation 207 The payload of an SCMP message MUST be prepared as a standard MIME 208 entity as defined in the [MIME] specification. The [SMIME] document 209 describes how the resulting MIME entity SHOULD be cryptographically 210 enhanced according to [PKCS-7]. 212 An SCMP compliant server SHOULD implement the three message types as 213 described in [SMIME], signed, enveloped, and signed/enveloped. An SCMP 214 compliant server MUST implement signed/envelope message type as 215 described in [SMIME]. 217 For non-repudiation concerns, the trading partners MUST exchange 218 signed or signed/enveloped SCMP message types. 220 SCMP error messages MUST be of signed type and NOT encrypted. 222 All of the header fields defined in this document are subject to the 223 general syntactic rules for header fields specified in [RFC822]. 225 In addition to the standard MIME headers, a compliant implementation 226 MUST define "SCMP-protocol-version" and "SCMP-sender-name". These 227 headers added to the outer MIME entity, as described in [MIME]. 229 Use of any additional standard SMIME (outside MIME entity) headers are 230 assumed. These headers will most likely be ones that need to be 231 processed prior to payload decryption. 233 Both the sending agent and receiving agent MUST specify all SCMP 234 headers specified in this document. 236 2.1 SCMP Protocol Version 238 The SCMP-protocol-version header is used to designate the SCMP protocol 239 version. Server implementations MAY reject the request based upon 240 protocol version, before any message processing occurs. 242 An example SCMP-protocol-version header will be in this format: 244 SCMP-protocol-version: 2.0 246 The value of the protocol-version header MUST be in the following 247 format, any number of digits, followed by a the special character ".", 248 followed by any number of digits. Where special character, and digits is 249 defined in [RFC822]. 251 If a particular protocol version is not supported by the implimentation, 252 the receiving agent MUST reject the request with an appropriate SCMP 253 error message. 255 3. SCMP Payload-based Headers 257 This section describes the payload-based extensions that MUST be 258 implemented by both the client and server to ensure correct and proper 259 request processing. 261 Setting the SCMP service headers is the responsibility of the sending 262 agent's client application. Processing the SCMP payload headers is the 263 responsibility of the receiving agent's server application processing 264 the request. 266 The following headers are described for the payload of the SMIME 267 entity, and MUST be prepared as defined in [MIME]. Thus if the SMIME 268 message type is signed/enveloped ( which is recommended ), then the 269 SCMP headers will be encrypted with the sender's message payload. 271 Both the sending agent and receiving agent MUST specify all SCMP 272 headers specified in this document. 274 3.1. Request Time to Live 276 This describes the amount of actual processing time in seconds the 277 client expects the server to complete payload processing prior to 278 responding with an appropriate reply. 280 An SCMP server receiving a SCMP message MUST evaluate the request time 281 to live value and determine if it can execute the required service(s) 282 in the amount of time designated. Assuming the server believes it can 283 complete the work within the allowed time, it will accept the request. 284 If not, the server MUST return an error to the client stating it 285 could not accept the request. 287 Once a server has accepted a request, it MUST process it until the time 288 to live value has been reached or until completion. If the time to live 289 value is reached during execution, the server MUST return an error to 290 the client stating that a time-out has occurred. 292 Application functions to ensure data consistency, integrity, or 293 rollback after the time to live value has been exceeded will be the 294 responsibility of the server application. A policy on what application 295 actions a server will take upon exceeding a time to live value SHOULD 296 be published by the receiving agent operating the server. 298 An example of a policy in this are would be one where a receiving 299 agent's server will continue processing the request after a request 300 time to live value has been exceeded. Given this policy, a client, 301 having received a time-out error message, would send a "request 302 status message" to the server, referencing the original 303 scmp-request-id (from the message that timed out) in the message 304 payload. The server's reply to this status message would be the reply 305 that would have been sent had the processing time not exceeded the 306 time to live metric. 308 The time to live header will be in this format: 310 SCMP-request-time-to-live: 90 312 Where the value of the time-to-live header is a digit or digit(s) as 313 specified in [RFC822]. The value of the time-to-live is represented 314 as any number of digit(s) which will designate a number of seconds. 316 3.2. Message Type 318 This value specifies the type of payload that is contained in the SCMP 319 message. The intent of this header is to provide a meta-level 320 description of the message payload and allow a receiving server to 321 decide which services or associated algorithms to use in processing 322 the payload. 324 Message type is specified as follows: 326 SCMP-message-type: [service-name]/[version-number] 328 Where service-name is text as specified in [RFC822] and version-number 329 is a digit or digit(s), followed by the special character ".", followed 330 by a digit or digit(s). Where digit and special character are defined in 331 [RFC822]. 333 For instance, if a service was published called "CommerceService", the 334 SCMP-message-type would be represented as: 336 SCMP-message-type: CommerceService/1 338 It is assumed that trading partners will agree on service names 339 before requests are processed. 341 If a particular message type is not supported by the implimentation, 342 the receiving agent MUST reject the request with an appropriate SCMP 343 error message. 345 3.3. Request ID 347 Request ID's MUST be generated by the client application, thus 348 assuring that the scmp-request-id is available in the event that the 349 request cannot be sent to the server due to errors. 351 The format of value of the request id header is 22 digits, where 352 digits is defined by [RFC822]. 354 An example of a request scmp-request-id is: 356 scmp-request-id: 0917293049096167904518 358 The scmp-request-id MUST be unique in the domain of a client 359 application and SHOULD NOT be easy to predict so as to prevent a 360 potential replay attack. 362 A client application, when preparing the scmp-request-id, SHOULD 363 perform a random number generation with sufficient degrees of 364 randomness, to ensure unpredictability, and generate a client side 365 time value, to ensure uniqueness of the result. These two data items 366 together SHOULD form the resulting scmp-request-id. 368 Servers MAY use a scmp-request-id as a reference and handle to the 369 original request during server message processing. 371 Servers MUST return the submitted request id back to the client via 372 the SCMP reply message in the SCMP-request-id header. 374 4. SCMP Data Block (Message Payload) 376 The payload or data block can be any arbitrary data type in the format 377 as specified by the SCMP-message-type. This payload forms the content 378 of the SMIME message as described in [SMIME]. 380 6. Transport Implementations 382 SCMP can be implemented using any variety of transport methods as 383 defined by the service provider. Here are a few examples. 385 HTTP: This delivers a SCMP message to a server URL and should 386 use a POST function. Used in this manner the SCMP reply 387 would be the entity-body of the HTTP response. SCMP error 388 messages would be the entity-body of the HTTP response. 390 SMTP: This will support a queued batch processing service. Used 391 in this manner the SCMP messages would be the body of the SMTP 392 message. SCMP error messages would be sent in the body of the 393 SMTP message. 395 7. Receiving Server Functions 397 This section describes minimal server functions required to implement 398 SCMP. 400 7.1. General 402 A SCMP server receives a message from a client, processes the message 403 and generates a reply. If the message type is signed or signed/enveloped 404 the server initially validates the outer signature. If the outer 405 signature is not valid the server MUST NOT process the request further. 407 7.1.1. Message Timestamp 409 The time a request was received SHOULD be derived from the environment 410 which recieves the message. Clients and servers SHOULD be synchronized 411 using [NTP] or Secure NTP. 413 The message timestamp SHOULD be used, in combination with the 414 scmp-request-id, by the server to aid in detection of a potential 415 replay attack. 417 It is recommended that servers SHOULD run a client-visible NTP server 418 to allow SCMP client applications to synchronize clocks as required. 420 7.1.2 Support for Request Non-Repudiation 422 Support for non-repudiation MUST be included in any complete SCMP 423 implementation, as described in the following subsections. 425 Implemenations MAY support non-repudation of error message replies. 426 This document addresses the non-repudation concerns of the server or 427 receiving agent. The non-repudiation concerns of of the client or 428 sending agent MAY be fulfilled by the same means as the server or 429 receiving agent supports non-repudiation. 431 7.1.2.1 Client Message Signing 433 The client application must send signed or signed/enveloped message type 434 as specified in [SMIME]. 436 7.1.2.2 Server Message Signing 438 The server application must send signed or signed/enveloped message type 439 as specified in [SMIME]. 441 7.1.2.3 Server Processing 443 The receiving agent's server application evaluates the digital 444 signature, thereby guaranteeing that the message payload has not been 445 altered in transit, and that the message was, in fact, signed by a 446 specific trading partner (client) who possess the proper credentials. 448 7.1.2.4 Server Accounting 450 The receiving agent's server application MUST store the original signed/ 451 encrypted message in an unprocessed state along with the timestamp for 452 identifying when the message was received. 454 7.1.2.5 Client Accounting 456 The sending agent's client application MAY store the original signed/ 457 encrypted message in an unprocessed state along with the timestamp for 458 identifying when the message was received. 460 7.1.2.6 Revocation 462 All messages signed by a sending agent's client application in 463 accordance with [SMIME] and sent to a receiving agent's server SHALL be 464 considered non-repudiable. 466 To satisfy the non-repudiation requirements, the receiver of the message 467 MUST support revocation mechanisms for the certificates of the potential 468 senders of the SCMP messages that are accepted by the server application. 470 7.2. Application issues 472 The server MUST evaluate the signature of the message, if the message 473 is of signed or signed/enveloped type, prior to processing the message 474 payload. In performing this authentication process, the server MUST 475 validate the senders certificate and verify that the senders certificate 476 is not listed in any available revocation systems. 478 Assuming the SCMP message's signature is valid, the server will process 479 requests with the appropriate service designated by the SCMP-message-type value. 481 7.2.1. Request Serialization 483 A server SHOULD NOT guarantee serialized request processing. If requests 484 must be serialized, it is expected that all of the serialized 485 transactions will be received in a single message payload or that other 486 content specific serialization systems will be used. 488 7.2.2. Server Errors 490 A server may encounter several classes of error conditions. The 491 server MUST be capable of reporting an error as described in section 8 492 of this document. Error Detection may vary based on specific 493 implementation. 495 A server MUST be capable of detecting a duplicate scmp-request-id 496 and reply to the sending client application with an appropriate SCMP 497 error message. Duplicate request detection MUST be based on the 498 scmp-request-id and the distinguished name of the signer to prevent 499 denial of service attacks. 501 8. Protocol Level Error Messages 503 In general SCMP does not concern itself with application level errors. 504 Such errors MUST be returned in an SCMP reply with appropriate 505 application specific formatting. 507 8.1. Format 509 SCMP error messages MUST be signed SMIME messages. SCMP errors 510 MUST NOT be encrypted to permit clients to process encryption related 511 errors. 513 The format of SCMP errors is: 515 SCMP 517 Where the format of "error number" is a digit or digits as defined in 518 [RFC822] and "error message text" is text as defined in [RFC822]. 520 8.2. Client Application Error Handling 522 Client action in the case of error return is error specific and not 523 defined. If the server fails to return any reply within the time to 524 live requested (due to unspecified server or network failure) the 525 client MAY re-send the request. Clients MUST NOT retry a request in 526 an interval which is less than the time to live value of the original 527 request. 529 9. Security Considerations 531 Security considerations are addressed throughout this document. 533 9.1 Encryption Strength 535 It is recommended that strong enough cryptographic methods be used to 536 ensure authenticity, integrity, non-repudiation, and privacy of the 537 payload. 539 9.2 Non-repudiation 541 Non-repudation implimentation is specified in section 7.1.2. 543 As addressed above, this document does not describe how a sending agent 544 may support non-repudiation. The intent of this document does describe 545 how a receiving agent can support non-repudiation. 547 If the receving agent accepts and processes a transaction after the 548 private key of the sending agent has been comprimised, that request is 549 refutable, or not non-refutable. 551 9.3 Public Certificate Considerations 553 9.3.1 Certificate Exchange 555 Every trading partner implementing SCMP SHOULD exchange certificates 556 that have been issued and signed by one or more mutually trusted 557 certificate authorities. Prior to establishing trading partner 558 relationships, the sender and receiver SHOULD acquire mutually 559 acceptable public root certificates from the agreed upon certificate 560 authority or authorities. 562 Sending and receiving agents MAY utilize certificate only messages to 563 exchange certificates as specified in [SMIME]. 565 9.3.2 Certificate Authentication and Revocation 567 Trading partners, upon receiving or exchanging public key certificates 568 for the first time, SHOULD validate the certificate and certificate 569 chain before processing an SCMP request. 571 A server certificate revalidation policy, related to the frequency 572 certificates are revalidated against a certificate authority's 573 certificate revocation list, is not specified by SCMP. This matter is 574 left as a policy decision for the operator of the SCMP server. 576 The timestamp of a certificate revocation event SHOULD be the time the 577 private key was known to be comprimised, or the time that the revocation 578 event was made. 580 9.4 Private Key Considerations 582 9.4.1 Private Key Generation 584 Private key generation should be of a secure manner as not to jepordize 585 the integrety of the private key. 587 9.4.2 Private Key Storage 589 The sending agent, maintaining a SCMP client application, MUST 590 maintain the private key in a secure location. 592 9.4.3 Private Key Revocation 594 Should a sending agent loose control of their private key, they MUST 595 notify the agreed upon, trusted, certificate authority. This 596 notification mechanism is not defined in this document, and should 597 be done via an out of band mechanism. 599 9.5 Request Id 601 The request id MUST be unique as to prevent possible replay attack 602 senarios. 604 10. SCMP Message Example 606 [ OUTER MIME START ] 607 Content-Type: application/pkcs7-mime 608 Content-Transfer-Encoding: base64 609 Content-Length: 1024 610 SCMP-protocol-version: 2.0 611 SCMP-sender-name: Adobe 613 [ INNER MIME START - enveloped entity ] 614 SCMP-request-time-to-live: 90 615 SCMP-message-type: Commerce/2.0 616 SCMP-request-id: 0123456789012345678901 617 Content-Type: application/pkcs7-mime 618 Content-Transfer-Encoding: base64 619 Content-Length: 512 621 [PAYLOAD - signed entity ] 623 [ INNER MIME END ] 624 [ OUTER MIME END ] 626 11. XML Payload Example 628 This section is intended to be an example implementation of a payload 629 and is NOT required for this protocol. The parties communicating could 630 agree on two "scmp-message-type" values. The first would be the exchange 631 of the DTD template, ( ie. scmp-message-type=widget xml definition ). 632 The second could be the actual data generated from that template, ( ie. 633 scmp-message-type=widget xml data ). The DTD would be transfered 634 defining the data format. The server could store the format for later 635 transferring of these types of messages. An example DTD follows. 637 638 639 640 641 642 643 645 This DTD would produce data as follows. 647 648 649 Widget Maker 650 651 0349003 652 653 655 This XML data would be the payload of the SCMP. When the agent recieves 656 this type of SCMP message they could validate the message format with 657 the previously received template. 659 12. Author's Address 661 Tom Arnold 662 CyberSource Corporation 663 550 S. Winchester Blvd., #301 664 San Jose, CA 95128 665 E-mail: toma@cybersource.com 666 Phone: 408-556-9100 668 Jason Eaton 669 CyberSource Corporation 670 550 S. Winchester Blvd., #301 671 San Jose, CA 95128 672 E-mail: jeaton@cybersource.com 673 Phone: 408-556-9100 675 13. Acknowledgements 677 The authors wish to recognize and thank several individuals 678 (listed in alphabetic order) who have and continue to 679 support the development of requirements and improvement of 680 this protocol. 682 Mike Agostino (Vulcan), Ron Bose (LitleNet), David Burdett (Mondex), 683 Leonard Cantor (IBM), Dan Corcoran (Equifax), Steve Crocker 684 (Crocker Assoc.), Tony Curwen (Ingram Micro), Donald Eastlake (IBM), 685 Richard Frank (Intertrust), James Gavin (Commercenet), Paul 686 Guthrie (VISA International), Lauren Hall (SIIA), Bengamin Hipp 687 (FUSA/Paymentech), Andy Jeffrey (Sonnet Financial), Helle Jespersen 688 (IBM), Sean Kiewiet (Hypercom.com), Connie Lindgreen (IBM), 689 Michael Myers (VeriSign), Allan Ottosen (PBS), John Pettitt 690 (Beyond.com), Jesse Rendleman (CyberSource), Don Sloan 691 (Tech Data), Carl Stucke (Equifax), Frank Tyksen (Portland 692 Software), Huy Vu (VISA USA), Sean Youssefi (CobWeb) 694 14. References 696 [SMIME] S. Dusse, et. al, "S/MIME Version 2 Message 697 Specification", RFC 2311, IETF, March 1998. 699 [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 700 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 701 3: Message Header Extensions for Non-ASCII Text", RFC 702 2047; "MIME Part 4: Registration Procedures", RFC 703 2048; "MIME Part 5: Conformance Criteria and 704 Examples", RFC 2049, IETF. 706 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 707 Levels", RFC 2119, IETF. 709 [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, 710 September 1989. 712 [PKCS-7] B. Kaliski, "PKCS #7: Cryptograpic Message Syntax" 713 RFC 2315, IETF, March 1998. 715 [RFC822] D. Crocker, "Standard for the format of arpa internet 716 text messages", RFC 822, IETF, August 1982. 718 [X.520] "ITU-T Recommendation X.520: Information Technlogy - 719 Open Systems Interconnection - The Directory: 720 Selected Attributes Types, 1993. 722 [XML] Extensible Mark Up Language. See http://www.w3.org/TR