idnits 2.17.1 draft-arnold-scmp-06.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-06.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-arnold-scmp-06.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-arnold-scmp-06.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-06.txt)', but the file name used is 'draft-arnold-scmp-06' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 721 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 4 instances of too long lines in the document, the longest one being 71 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 (May 12, 2000) is 8743 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) == Unused Reference: 'PKCS-7' is defined on line 707, 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) ** 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 (~~), 6 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 May 12, 2000 4 Expires in six months 6 Simple Commerce Messaging Protocol (SCMP) 7 Version 1 Message Specification 8 (draft-arnold-scmp-06.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 [SMIME] section 3.1. 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. Terminology 65 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 66 are used in conformance to the definitions in RFC2119 [MUSTSHOULD]. 68 1.2. Definitions 70 Several terms will be used when specifying SCMP. 72 Trading Partners Two entities wishing to perform some on-line 73 request processing where authentication, 74 privacy, integrity and non-repudiation of the 75 requests are important. Trading partners have 76 established a trusted relationship between each 77 other. 79 Client An application program that executes on a remote 80 system, used by a trading partner to request 81 services from a server via an untrusted or 82 publicly switched packet network, like the 83 Internet. 85 Server An application program used to process SCMP 86 messages received from a client, and generate 87 appropriate replies which are sent back to the 88 client. 90 Sending Agent An entity that operates or uses a Client for 91 requesting on-line services from a server. 93 Receiving Agent An entity that operates a Server, receives and 94 processes requests from a plurality of Clients. 96 Request An SCMP formatted message containing a set of 97 directives set in a textual form requesting a set 98 of directives be executed on behalf of the sending 99 agent. 101 Reply An SCMP formatted message containing a set of 102 result data generated as a result of processing an 103 SCMP request. 105 Payload The meaningful content provided by a client to a 106 server, encapsulated in an SCMP message. Similarly 107 the meaningful content provided by a server to a 108 client, encapsulated in an SCMP message. 110 Services Groups of operations and/or algorithms implemented 111 by the server application which are executed as 112 designated by the payload. Each available group of 113 operations and/or algorithms is a service. 115 1.3. Document Overview 117 This document describes SCMP from the standpoint of how trading 118 partners would implement a client/server request processing system via 119 an untrusted network connection. 121 In a on-line, electronic commerce environment, trading partners require 122 a scalable, message handling system that will meet these minimum 123 requirements: 125 1.3.1 Real-time Request and Response 127 A single message containing all credentials and payload data is 128 prepared by a sending agent and sent to a receiving agent. The 129 receiving agent, upon verification of sender's credentials, SHOULD 130 process the payload, format a reply, and respond to the sender as 131 the response to the request. 133 1.3.2 Message Privacy 135 Through use of cryptographic methods, the privacy of the sender's 136 message payload MUST be assured in the event a message payload is 137 intercepted. 139 1.3.3 Message Integrity 141 If a message arrives in an incomplete or tampered condition from a 142 sending agent, the receiving agent's server MUST detect the condition, 143 deny message payload processing, and respond with an appropriate 144 error message. 146 1.3.4 Authentication of Sending and Receiving Agents 148 Messages between trading partners, as represented by sending and 149 receiving agents, MUST contain attributes that assure a given request 150 could only be from a specific trading partner. Additionally SCMP 151 requests and SCMP replies MUST be authenticated. 153 Prior to performing any application functions on a SCMP request 154 payload, the receiving agent's server MUST verify that the request has 155 been made by an authorized sender. 157 1.3.5 Non-repudiation 159 When a receiving agent's server receives a request to process a payload, 160 the receiving agent's application SHOULD guarantee that the sender 161 cannot, at some later time, refute having sent the request. 163 Non-repudiation is defined as, the inability of either trading partner 164 (sender or receiver) to refute the sending of an SCMP request or SCMP 165 reply. 167 An Electronic Commerce provider will typically provide financial based 168 functionality such as authorization, settlement, and crediting, of 169 credit card accounts and/or merchant accounts. This functionality 170 requires that the Electronic Commerce Provider execute financial 171 transactions on behalf of the merchant, or trading partner. Therefore it 172 is desirable that the transaction directives which are given in an SCMP 173 message are non-refutable. 175 1.3.6 Payload Independence 177 The messaging system SHOULD perform consistently for all payload formats. 179 1.3.7 Standards Based 181 The messaging protocol SHOULD be based on proven, existing cryptography 182 and Internet standards. 184 1.3.8 Use of Standard Credentials 186 Standard credential formats SHOULD be used to maximize interoperability 187 of common Public Key Infrastructures. 189 1.3.9 Transport Independent 191 The message SHOULD be transportable over the most common Internet 192 transport protocols. 194 1.3.10 Service Level Guarantee 196 The receiving agent SHOULD guarantee a response within the time 197 designated by the sender, or reject the message with an appropriate 198 error message. 200 1.3.11 State Independence 202 State dependency by either a sender's or receiver's application SHOULD 203 be minimalized as to support multiple transport mechanisms. 205 2. SCMP Message Construction 207 The payload of an SCMP message is divided into two parts. The outer 208 SMIME entity that contains the cryptographically enhanced payload and 209 the inner MIME encapsulation of the payload. In this way the inner MIME 210 message can be enveloped protecting the header information which may 211 contain sensative data. 213 All of the header fields defined in this document are subject to the 214 general syntactic rules for header fields specified in [RFC822]. 216 Both the sending agent and receiving agent MUST specify all SCMP 217 headers specified in this document. 219 2.1 Outer SMIME Message Construction 221 The outer SMIME message MUST be constructed in accordance with [SMIME] 222 section 3.1. An SCMP compliant server SHOULD implement the three 223 message types as described in [SMIME], signed, enveloped, and 224 signed/enveloped. An SCMP compliant server MUST implement 225 signed/envelope message type as described in [SMIME]. 227 For non-repudiation concerns, the trading partners MUST exchange 228 signed or signed/enveloped SCMP message types. 230 SCMP error messages MUST be of signed type and NOT encrypted. 232 In addition to the headers listed below use of any additional standard 233 SMIME and MIME headers are assumed. These headers will most likely be 234 ones that need to be processed prior to payload decryption. 236 2.1.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 2.2 Inner MIME Message Construction 257 The payload of an SCMP message MUST be prepared as a standard MIME 258 entity as defined in the [MIME] specification. 260 The remainder of this section describes the payload-based extensions 261 that MUST be implemented by both the client and server to ensure 262 correct and proper request processing. 264 Setting the SCMP service headers is the responsibility of the sending 265 agent's client application. Processing the SCMP payload headers is the 266 responsibility of the receiving agent's server application processing 267 the request. 269 The following headers are described for the inner MIME entity which 270 contains the payload. Thus if the SMIME message type is signed/enveloped ( which is recommended ), then the SCMP headers will be encrypted with 271 the sender's message payload. 273 Both the sending agent and receiving agent MUST specify all SCMP 274 headers specified in this document. 276 2.2.1. Request Time to Live 278 This describes the amount of actual processing time in seconds the 279 client expects the server to complete payload processing prior to 280 responding with an appropriate reply. 282 An SCMP server receiving a SCMP message MUST evaluate the request time 283 to live value and determine if it can execute the required service(s) 284 in the amount of time designated. Assuming the server believes it can 285 complete the work within the allowed time, it will accept the request. 286 If not, the server MUST return an error to the client stating it 287 could not accept the request. 289 Once a server has accepted a request, it MUST process it until the time 290 to live value has been reached or until completion. If the time to live 291 value is reached during execution, the server MUST return an error to 292 the client stating that a time-out has occurred. 294 Application functions to ensure data consistency, integrity, or 295 rollback after the time to live value has been exceeded will be the 296 responsibility of the server application. A policy on what application 297 actions a server will take upon exceeding a time to live value SHOULD 298 be published by the receiving agent operating the server. 300 An example of a policy in this are would be one where a receiving 301 agent's server will continue processing the request after a request 302 time to live value has been exceeded. Given this policy, a client, 303 having received a time-out error message, would send a "request 304 status message" to the server, referencing the original 305 scmp-request-id (from the message that timed out) in the message 306 payload. The server's reply to this status message would be the reply 307 that would have been sent had the processing time not exceeded the 308 time to live metric. 310 The time to live header will be in this format: 312 SCMP-request-time-to-live: 90 314 Where the value of the time-to-live header is a digit or digit(s) as 315 specified in [RFC822]. The value of the time-to-live is represented 316 as any number of digit(s) which will designate a number of seconds. 318 2.2.2. Message Type 320 This value specifies the type of payload that is contained in the SCMP 321 message. The intent of this header is to provide a meta-level 322 description of the message payload and allow a receiving server to 323 decide which services or associated algorithms to use in processing 324 the payload. 326 Message type is specified as follows: 328 SCMP-message-type: [service-name]/[version-number] 330 Where service-name is text as specified in [RFC822] and version-number 331 is a digit or digit(s), followed by the special character ".", followed 332 by a digit or digit(s). Where digit and special character are defined in 333 [RFC822]. 335 For instance, if a service was published called "CommerceService", the 336 SCMP-message-type would be represented as: 338 SCMP-message-type: CommerceService/1 340 It is assumed that trading partners will agree on service names 341 before requests are processed. 343 If a particular message type is not supported by the implimentation, 344 the receiving agent MUST reject the request with an appropriate SCMP 345 error message. 347 2.2.3. Request ID 349 Request ID's MUST be generated by the client application, thus 350 assuring that the scmp-request-id is available in the event that the 351 request cannot be sent to the server due to errors. 353 The format of value of the request id header is 22 digits, where 354 digits is defined by [RFC822]. 356 An example of a request scmp-request-id is: 358 scmp-request-id: 0917293049096167904518 360 The scmp-request-id MUST be unique in the domain of a client 361 application and SHOULD NOT be easy to predict so as to prevent a 362 potential replay attack. 364 A client application, when preparing the scmp-request-id, SHOULD 365 perform a random number generation with sufficient degrees of 366 randomness, to ensure unpredictability, and generate a client side 367 time value, to ensure uniqueness of the result. These two data items 368 together SHOULD form the resulting scmp-request-id. 370 Servers MAY use a scmp-request-id as a reference and handle to the 371 original request during server message processing. 373 Servers MUST return the submitted request id back to the client via 374 the SCMP reply message in the SCMP-request-id header. 376 3. Transport Implementations 378 SCMP can be implemented using any variety of transport methods as 379 defined by the service provider. Here are a few examples. 381 HTTP: This delivers a SCMP message to a server URL and SHOULD 382 use a POST function. Used in this manner the SCMP reply 383 would be the entity-body of the HTTP response. SCMP error 384 messages would be the entity-body of the HTTP response. 386 SMTP: This will support a queued batch processing service. Used 387 in this manner the SCMP messages would be the body of the SMTP 388 message. SCMP error messages would be sent in the body of the 389 SMTP message. 391 4. Receiving Server Functions 393 This section describes minimal server functions required to implement 394 SCMP. 396 4.1. General 398 A SCMP server receives a message from a client, processes the message 399 and generates a reply. If the message type is signed or signed/enveloped 400 the server initially validates the outer signature. If the outer 401 signature is not valid the server MUST NOT process the request further. 403 4.1.1. Message Timestamp 405 The time a request was received SHOULD be derived from the environment 406 which recieves the message. Clients and servers SHOULD be synchronized 407 using [NTP] or Secure NTP. 409 The message timestamp SHOULD be used, in combination with the 410 scmp-request-id, by the server to aid in detection of a potential 411 replay attack. 413 It is recommended that servers SHOULD run a client-visible NTP server 414 to allow SCMP client applications to synchronize clocks as required. 416 4.1.2 Support for Request Non-Repudiation 418 Support for non-repudiation MUST be included in any complete SCMP 419 implementation, as described in the following subsections. 421 Implemenations MAY support non-repudation of error message replies. 422 This document addresses the non-repudation concerns of the server or 423 receiving agent. The non-repudiation concerns of of the client or 424 sending agent MAY be fulfilled by the same means as the server or 425 receiving agent supports non-repudiation. 427 4.1.2.1 Client Message Signing 429 The client application MUST send signed or signed/enveloped message type 430 as specified in [SMIME]. 432 4.1.2.2 Server Message Signing 434 The server application MUST send signed or signed/enveloped message type 435 as specified in [SMIME]. 437 4.1.2.3 Server Processing 439 The receiving agent's server application evaluates the digital 440 signature, thereby guaranteeing that the message payload has not been 441 altered in transit, and that the message was, in fact, signed by a 442 specific trading partner (client) who possess the proper credentials. 444 4.1.2.4 Server Accounting 446 The receiving agent's server application MUST store the original signed/ 447 encrypted message in an unprocessed state along with the timestamp for 448 identifying when the message was received. 450 4.1.2.5 Client Accounting 452 The sending agent's client application MAY store the original signed/ 453 encrypted message in an unprocessed state along with the timestamp for 454 identifying when the message was received. 456 4.1.2.6 Revocation 458 All messages signed by a sending agent's client application in 459 accordance with [SMIME] and sent to a receiving agent's server SHALL be 460 considered non-repudiable. 462 To satisfy the non-repudiation requirements, the receiver of the message 463 MUST support revocation mechanisms for the certificates of the potential 464 senders of the SCMP messages that are accepted by the server application. 466 4.2. Application issues 468 The server MUST evaluate the signature of the message, if the message 469 is of signed or signed/enveloped type, prior to processing the message 470 payload. In performing this authentication process, the server MUST 471 validate the senders certificate and verify that the senders certificate 472 is not listed in any available revocation systems. 474 Assuming the SCMP message's signature is valid, the server will process 475 requests with the appropriate service designated by the SCMP-message-type value. 477 4.2.1. Request Serialization 479 A server SHOULD NOT guarantee serialized request processing. If request 480 serialization is a application requirement, it is expected that all of 481 the serialized transactions will be received in a single message payload 482 or that other content specific serialization systems will be used. 484 4.2.2. Server Errors 486 During application processing, a server could encounter several classes 487 of error conditions. The server MUST be capable of reporting an error as 488 described in section 5 of this document. Error Detection may vary based 489 on specific implementation. 491 Additionally, a server MUST be capable of detecting a duplicate scmp- 492 request-id and reply to the sending client application with an 493 appropriate SCMP error message. Duplicate request detection MUST be 494 based on the scmp-request-id and the distinguished name of the signer to 495 prevent potential denial of service attacks. 497 5. Protocol Level Error Messages 499 In general SCMP does not concern itself with application level errors. 500 Such errors SHOULD be returned in an SCMP reply with appropriate 501 application specific formatting. 503 5.1. Format 505 SCMP error messages MUST be signed SMIME messages. SCMP errors 506 MUST NOT be encrypted to permit clients to process encryption related 507 errors. 509 The format of SCMP errors is: 511 SCMP 513 Where the format of "error number" is a digit or digits as defined in 514 [RFC822] and "error message text" is text as defined in [RFC822]. 516 5.2. Client Application Error Handling 518 Client action in the case of error return is error specific and not 519 defined. If the server fails to return any reply within the time to 520 live requested (due to unspecified server or network failure) the 521 client MAY re-send the request. Clients MUST NOT retry a request in 522 an interval which is less than the time to live value of the original 523 request. 525 6. Security Considerations 527 Security considerations are addressed throughout this document. 529 6.1 Encryption Strength 531 It is recommended that strong enough cryptographic methods be used to 532 ensure authenticity, integrity, non-repudiation, and privacy of the 533 payload. 535 6.2 Non-repudiation 537 Non-repudation implimentation is specified in section 7.1.2. 539 As addressed above, this document does not describe how a sending agent 540 may support non-repudiation. The intent of this document does describe 541 how a receiving agent can support non-repudiation. 543 If the receving agent accepts and processes a transaction after the 544 private key of the sending agent has been comprimised, that request is 545 refutable, or not non-refutable. 547 6.3 Public Certificate Considerations 549 6.3.1 Certificate Exchange 551 Every trading partner implementing SCMP SHOULD exchange certificates 552 that have been issued and signed by one or more mutually trusted 553 certificate authorities. Prior to establishing trading partner 554 relationships, the sender and receiver SHOULD acquire mutually 555 acceptable public root certificates from the agreed upon certificate 556 authority or authorities. 558 Sending and receiving agents MAY utilize certificate only messages to 559 exchange certificates as specified in [SMIME]. 561 6.3.2 Certificate Authentication and Revocation 563 Trading partners, upon receiving or exchanging public key certificates 564 for the first time, SHOULD validate the certificate and certificate 565 chain before processing an SCMP request. 567 A server certificate revalidation policy, related to the frequency 568 certificates are revalidated against a certificate authority's 569 certificate revocation list, is not specified by SCMP. This matter is 570 left as a policy decision for the operator of the SCMP server. 572 The timestamp of a certificate revocation event SHOULD be the time the 573 private key was known to be comprimised, or the time that the revocation 574 event was made. 576 6.4 Private Key Considerations 578 6.4.1 Private Key Generation 580 Private key generation SHOULD be of a secure manner as not to jepordize 581 the integrety of the private key. 583 6.4.2 Private Key Storage 585 The sending agent, maintaining a SCMP client application, MUST 586 maintain the private key in a secure location. 588 6.4.3 Private Key Revocation 590 Should a sending agent loose control of their private key, they MUST 591 notify the agreed upon, trusted, certificate authority. This 592 notification mechanism is not defined in this document, and SHOULD 593 be done via an out of band mechanism. 595 6.5 Request Id 597 The request id MUST be unique as to prevent possible replay attack 598 senarios. 600 7. SCMP Message Example 602 [ OUTER MIME START ] 603 Content-Type: application/pkcs7-mime 604 Content-Transfer-Encoding: base64 605 Content-Length: 1024 606 SCMP-protocol-version: 2.0 608 [ INNER MIME START - enveloped entity ] 609 SCMP-request-time-to-live: 90 610 SCMP-message-type: Commerce/2.0 611 SCMP-request-id: 0123456789012345678901 612 Content-Type: application/pkcs7-mime 613 Content-Transfer-Encoding: base64 614 Content-Length: 512 616 [PAYLOAD - signed entity ] 618 [ INNER MIME END ] 619 [ OUTER MIME END ] 621 8. XML Payload Example 623 This section is intended to be an example implementation of a payload 624 and is NOT required for this protocol. The parties communicating could 625 agree on two "scmp-message-type" values. The first would be the exchange 626 of the DTD template, ( ie. scmp-message-type=widget xml definition ). 627 The second could be the actual data generated from that template, ( ie. 628 scmp-message-type=widget xml data ). The DTD would be transfered 629 defining the data format. The server could store the format for later 630 transferring of these types of messages. An example DTD follows. 632 633 634 635 636 637 638 640 This DTD would produce data as follows. 642 643 644 Widget Maker 645 646 0349003 647 648 650 This XML data would be the payload of the SCMP. When the agent recieves 651 this type of SCMP message they could validate the message format with 652 the previously received template. 654 9. Author's Address 656 Tom Arnold 657 CyberSource Corporation 658 1295 Charleston Road 659 Mountain View, CA 94043 660 E-mail: toma@cybersource.com 661 Phone: 650-965-6000 663 Jason Eaton 664 CyberSource Corporation 665 1295 Charleston Road 666 Mountain View, CA 94043 667 E-mail: jeaton@cybersource.com 668 Phone: 650-965-6000 670 10. Acknowledgements 672 The authors wish to recognize and thank several individuals 673 (listed in alphabetic order) who have and continue to 674 support the development of requirements and improvement of 675 this protocol. 677 Mike Agostino (Vulcan), Ron Bose (LitleNet), David Burdett (Mondex), 678 Leonard Cantor (IBM), Dan Corcoran (Equifax), Steve Crocker 679 (Crocker Assoc.), Tony Curwen (Ingram Micro), Donald Eastlake (IBM), 680 Richard Frank (Intertrust), James Gavin (Commercenet), Paul 681 Guthrie (VISA International), Lauren Hall (SIIA), Bengamin Hipp 682 (FUSA/Paymentech), Andy Jeffrey (Sonnet Financial), Helle Jespersen 683 (IBM), Sean Kiewiet (Hypercom.com), Connie Lindgreen (IBM), 684 Michael Myers (VeriSign), Allan Ottosen (PBS), John Pettitt 685 (Beyond.com), Jesse Rendleman (CyberSource), Don Sloan 686 (Tech Data), Carl Stucke (Equifax), Frank Tyksen (Portland 687 Software), Huy Vu (VISA USA), Sean Youssefi (CobWeb) 689 11. References 691 [SMIME] B. Ramsdell, "S/MIME Version 3 Message 692 Specification", RFC 2633, IETF, June 1998. 694 [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 695 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 696 3: Message Header Extensions for Non-ASCII Text", RFC 697 2047; "MIME Part 4: Registration Procedures", RFC 698 2048; "MIME Part 5: Conformance Criteria and 699 Examples", RFC 2049, IETF. 701 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 702 Levels", RFC 2119, IETF. 704 [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, 705 September 1989. 707 [PKCS-7] B. Kaliski, "PKCS #7: Cryptograpic Message Syntax" 708 RFC 2315, IETF, March 1998. 710 [RFC822] D. Crocker, "Standard for the format of arpa internet 711 text messages", RFC 822, IETF, August 1982. 713 [X.520] "ITU-T Recommendation X.520: Information Technlogy - 714 Open Systems Interconnection - The Directory: 715 Selected Attributes Types, 1993. 717 [XML] Extensible Mark Up Language. See http://www.w3.org/TR