idnits 2.17.1 draft-arnold-scmp-03.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-03.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-arnold-scmp-03.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-arnold-scmp-03.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-03.txt)', but the file name used is 'draft-arnold-scmp-03' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 717 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 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. -- Couldn't find a document date in the document -- date freshness check skipped. 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) Summary: 14 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: Application Jason Eaton (CyberSource) 3 June 10, 1999 Michael Jimenez (CyberSource) 4 Expires in six months Hubert Chen (CyberSource) 6 Simple Commerce Messaging Protocol (SCMP) 7 Version 1 Message Specification 8 (draft-arnold-scmp-03.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. 52 The only requirement on the message payload is that it be prepared 53 as specified in [MIME]. 55 In this manner, SCMP fundamentally differs from many emerging 56 commerce message protocols. Beyond specifying the method for 57 encryption, authentication and handling, these other protocols 58 specify the contents of the message and details how a server is to 59 process and respond to a given message payload. 61 1.1. Document Overview 63 This document describes SCMP from the standpoint of how trading partners 64 would implement a client/server request processing system via an 65 untrusted network connection. 67 In a on-line, electronic commerce environment, trading partners require 68 a scalable, message handling system that will meet these minimum 69 requirements: 71 1.1.1 Real-time Request and Response 73 A single message containing all credentials and payload data is 74 prepared by a sending agent and sent to a receiving agent. The 75 receiving agent, upon verification of sender's credentials, should 76 process the payload, format a reply, and respond to the sender as 77 the response to the request. 79 1.1.2 Message Privacy 81 Through use of cryptographic methods, the privacy of the sender's 82 message payload should be assured should a message payload be 83 intercepted. 85 1.1.3 Message Integrity 87 If a message arrives in an incomplete or tampered condition from a 88 sending agent, the receiving agent's server should detect the condition, 89 deny message payload processing, and respond with an appropriate 90 error message. 92 1.1.4 Authentication of Sending and Receiving Agents 94 Messages between trading partners, as represented by sending and 95 receiving agents, must contain attributes that assure a given request 96 could only be from a specific trading partner. Additionally SCMP 97 requests and SCMP replies MUST be authenticated. 99 Prior to performing any application functions on a SCMP request 100 payload, the receiving agent's server MUST verify that the request has 101 been made by an authorized sender. 103 1.1.5 Non-repudiation 105 When a receiving agent's server receives a request to process a payload, 106 the receiving agent's application should guarantee that the sender 107 cannot, at some later time, refute having sent the request. 109 Non-repudiation is defined as, the inability of either trading partner 110 (sender or receiver) to refute the sending of an SCMP request or SCMP 111 reply. 113 An Electronic Commerce provider will typically provide financial based 114 functionality such as authorization, settlement, and crediting, of 115 credit card accounts and/or merchant accounts. This functionality 116 requires that the Electronic Commerce Provider execute financial 117 transactions on behalf of the merchant, or trading partner. Therefore it 118 is desirable that the transaction directives which are given in an SCMP 119 message are non-refutable. 121 1.1.6 Payload Independence 123 The messaging system should perform consistently for all payload formats. 125 1.1.7 Standards Based 127 The messaging protocol should be based on proven, existing cryptography 128 and Internet standards. 130 1.1.8 Use of Standard Credentials 132 Standard credential formats should be used to maximize interoperability 133 of common Public Key Infrastructures. 135 1.1.9 Transport Independent 137 The message should be transportable over the most common Internet 138 transport protocols. 140 1.1.10 Service Level Guarantee 142 The receiving agent should guarantee a response within the time 143 designated by the sender, or reject the message with an appropriate 144 error message. 146 1.1.11 State Independence 148 State dependency by either a sender's or receiver's application should 149 be minimalized as to support multiple transport mechanisms. 151 1.2. Terminology 153 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 154 are used in conformance to the definitions in [MUSTSHOULD]. 156 1.3. Definitions 158 Several terms will be used when specifying SCMP. 160 Trading Partners Two entities wishing to perform some on-line 161 request processing where authentication, 162 privacy, integrity and non-repudiation of the 163 requests are important. Trading partners have 164 established a trusted relationship between each 165 other. 167 Client An application program that executes on a remote 168 system, used by a trading partner to request 169 services from a server via an untrusted or 170 publicly switched packet network, like the 171 Internet. 173 Server An application program used to process SCMP 174 messages received from a client, and generate 175 appropriate replies which are sent back to the 176 client. 178 Sending Agent An entity that operates or uses a Client for 179 requesting on-line services from a server. 181 Receiving Agent An entity that operates a Server, receives and 182 processes requests from a plurality of Clients. 184 Request An SCMP formatted message containing a set of 185 directives set in a textual form requesting a set 186 of directives be executed on behalf of the sending 187 agent. 189 Reply An SCMP formatted message containing a set of 190 result data generated as a result of processing an 191 SCMP request. 193 Payload The meaningful content provided by a client to a 194 server, encapsulated in an SCMP message. Similarly 195 the meaningful content provided by a server to a 196 client, encapsulated in an SCMP message. 198 Services Groups of operations and/or algorithms implemented 199 by the server application which are executed as 200 designated by the payload. Each available group of 201 operations and/or algorithms is a service. 203 2. Payload Encapsulation 205 The payload of an SCMP message MUST be prepared as a standard MIME 206 entity as defined in the [MIME] specification. The [SMIME] document 207 describes how the resulting MIME entity SHOULD be cryptographically 208 enhanced according to [PKCS-7]. 210 An SCMP compliant server SHOULD implement the three message types as 211 described in [SMIME], signed, enveloped, and signed/enveloped. An SCMP 212 compliant server MUST implement signed/envelope message type as 213 described in [SMIME]. 215 For non-repudiation concerns, the trading partners MUST exchange 216 signed or signed/enveloped SCMP message types. 218 SCMP error messages MUST be of signed type and NOT encrypted. 220 All of the header fields defined in this document are subject to the 221 general syntactic rules for header fields specified in [RFC822]. 223 In addition to the standard MIME headers, a compliant implementation 224 MUST define "SCMP-protocol-version" and "SCMP-sender-name". These 225 headers added to the outer MIME entity, as described in [MIME]. 227 Use of any additional standard SMIME (outside MIME entity) headers are 228 assumed. These headers will most likely be ones that need to be 229 processed prior to payload decryption. 231 Both the sending agent and receiving agent MUST specify all SCMP 232 headers specified in this document. 234 2.1 SCMP Protocol Version 236 The SCMP-protocol-version header is used to designate the SCMP protocol 237 version. Server implementations MAY reject the request based upon 238 protocol version, before any message processing occurs. 240 An example SCMP-protocol-version header will be in this format: 242 SCMP-protocol-version: 2.0 244 The value of the protocol-version header MUST be in the following 245 format, any number of digits, followed by a the special character ".", 246 followed by any number of digits. Where special character, and digits is 247 defined in [RFC822]. 249 If a particular protocol version is not supported by the implimentation, 250 the receiving agent MUST reject the request with an appropriate SCMP 251 error message. 253 2.2 SCMP Sender Name 255 The SCMP-sender-name header is used to designate the SCMP sender name. 256 Thereby the sender name can be accessed before any decryption of the 257 request is performed. Server implementations MAY reject the request 258 based upon sender name, before any message processing occurs. 260 An SCMP-sender-name header will be in this format: 262 SCMP-sender-name: SomeCompany 264 The sender name MUST be the subject's common name of the x.509 265 certificate that belongs to the signer of the SCMP message. As 266 specified by [X.520]. 268 3. SCMP Payload-based Headers 270 This section describes the payload-based extensions that MUST be 271 implemented by both the client and server to ensure correct and proper 272 request processing. 274 Setting the SCMP service headers is the responsibility of the sending 275 agent's client application. Processing the SCMP payload headers is the 276 responsibility of the receiving agent's server application processing 277 the request. 279 The following headers are described for the payload of the SMIME 280 entity, and MUST be prepared as defined in [MIME]. Thus if the SMIME 281 message type is signed/enveloped ( which is recommended ), then the 282 SCMP headers will be encrypted with the sender's message payload. 284 Both the sending agent and receiving agent MUST specify all SCMP 285 headers specified in this document. 287 3.1. Request Time to Live 289 This describes the amount of actual processing time in seconds the 290 client expects the server to complete payload processing prior to 291 responding with an appropriate reply. 293 An SCMP server receiving a SCMP message MUST evaluate the request time 294 to live value and determine if it can execute the required service(s) 295 in the amount of time designated. Assuming the server believes it can 296 complete the work within the allowed time, it will accept the request. 297 If not, the server MUST return an error to the client stating it 298 could not accept the request. 300 Once a server has accepted a request, it MUST process it until the time 301 to live value has been reached or until completion. If the time to live 302 value is reached during execution, the server MUST return an error to 303 the client stating that a time-out has occurred. 305 Application functions to ensure data consistency, integrity, or 306 rollback after the time to live value has been exceeded will be the 307 responsibility of the server application. A policy on what application 308 actions a server will take upon exceeding a time to live value SHOULD 309 be published by the receiving agent operating the server. 311 An example of a policy in this are would be one where a receiving 312 agent's server will continue processing the request after a request 313 time to live value has been exceeded. Given this policy, a client, 314 having received a time-out error message, would send a "request 315 status message" to the server, referencing the original 316 scmp-request-id (from the message that timed out) in the message 317 payload. The server's reply to this status message would be the reply 318 that would have been sent had the processing time not exceeded the 319 time to live metric. 321 The time to live header will be in this format: 323 SCMP-request-time-to-live: 90 325 Where the value of the time-to-live header is a digit or digit(s) as 326 specified in [RFC822]. The value of the time-to-live is represented 327 as any number of digit(s) which will designate a number of seconds. 329 3.2. Message Type 331 This value specifies the type of payload that is contained in the SCMP 332 message. The intent of this header is to provide a meta-level 333 description of the message payload and allow a receiving server to 334 decide which services or associated algorithms to use in processing 335 the payload. 337 Message type is specified as follows: 339 SCMP-message-type: [service-name]/[version-number] 341 Where service-name is text as specified in [RFC822] and version-number 342 is a digit or digit(s), followed by the special character ".", followed 343 by a digit or digit(s). Where digit and special character are defined in 344 [RFC822]. 346 For instance, if a service was published called "CommerceService", the 347 SCMP-message-type would be represented as: 349 SCMP-message-type: CommerceService/1 351 It is assumed that trading partners will agree on service names 352 before requests are processed. 354 If a particular message type is not supported by the implimentation, 355 the receiving agent MUST reject the request with an appropriate SCMP 356 error message. 358 3.3. Request ID 360 Request ID's MUST be generated by the client application, thus 361 assuring that the scmp-request-id is available in the event that the 362 request cannot be sent to the server due to errors. 364 The format of value of the request id header is 22 digits, where 365 digits is defined by [RFC822]. 367 An example of a request scmp-request-id is: 369 scmp-request-id: 0917293049096167904518 371 The scmp-request-id MUST be unique in the domain of a client 372 application and SHOULD NOT be easy to predict so as to prevent a 373 potential replay attack. 375 A client application, when preparing the scmp-request-id, SHOULD 376 perform a random number generation with sufficient degrees of 377 randomness, to ensure unpredictability, and generate a client side 378 time value, to ensure uniqueness of the result. These two data items 379 together SHOULD form the resulting scmp-request-id. 381 Servers MAY use a scmp-request-id as a reference and handle to the 382 original request during server message processing. 384 Servers MUST return the submitted request id back to the client via 385 the SCMP reply message in the SCMP-request-id header. 387 4. SCMP Data Block (Message Payload) 389 The payload or data block can be any arbitrary data type in the format 390 as specified by the SCMP-message-type. This payload forms the content 391 of the SMIME message as described in [SMIME]. 393 6. Transport Implementations 395 SCMP can be implemented using any variety of transport methods as 396 defined by the service provider. Here are a few examples. 398 HTTP: This delivers a SCMP message to a server URL and should 399 use a POST function. Used in this manner the SCMP reply 400 would be the entity-body of the HTTP response. SCMP error 401 messages would be the entity-body of the HTTP response. 403 SMTP: This will support a queued batch processing service. Used 404 in this manner the SCMP messages would be the body of the SMTP 405 message. SCMP error messages would be sent in the body of the 406 SMTP message. 408 7. Receiving Server Functions 410 This section describes minimal server functions required to implement 411 SCMP. 413 7.1. General 415 A SCMP server receives a message from a client, processes the message 416 and generates a reply. If the message type is signed or signed/enveloped 417 the server initially validates the outer signature. If the outer 418 signature is not valid the server MUST NOT process the request further. 420 7.1.1. Message Timestamp 422 The time a request was received SHOULD be derived from the environment 423 which recieves the message. Clients and servers SHOULD be synchronized 424 using [NTP] or Secure NTP. 426 The message timestamp SHOULD be used, in combination with the 427 scmp-request-id, by the server to aid in detection of a potential 428 replay attack. 430 It is recommended that servers SHOULD run a client-visible NTP server 431 to allow SCMP client applications to synchronize clocks as required. 433 7.1.2 Support for Request Non-Repudiation 435 Support for non-repudiation MUST be included in any complete SCMP 436 implementation, as described in the following subsections. 438 Implemenations MAY support non-repudation of error message replies. This 439 document addresses the non-repudation concerns of the server or 440 receiving agent. The non-repudiation concerns of of the client or 441 sending agent MAY be fulfilled by the same means as the server or 442 receiving agent supports non-repudiation. 444 7.1.2.1 Client Message Signing 446 The client application must send signed or signed/enveloped message type 447 as specified in [SMIME]. 449 7.1.2.2 Server Message Signing 451 The server application must send signed or signed/enveloped message type 452 as specified in [SMIME]. 454 7.1.2.3 Server Processing 456 The receiving agent's server application evaluates the digital 457 signature, thereby guaranteeing that the message payload has not been 458 altered in transit, and that the message was, in fact, signed by a 459 specific trading partner (client) who possess the proper credentials. 461 7.1.2.4 Server Accounting 463 The receiving agent's server application MUST store the original signed/ 464 encrypted message in an unprocessed state along with the timestamp for 465 identifying when the message was received. 467 7.1.2.5 Client Accounting 469 The sending agent's client application MAY store the original signed/ 470 encrypted message in an unprocessed state along with the timestamp for 471 identifying when the message was received. 473 7.1.2.6 Revocation 475 All messages signed by a sending agent's client application in 476 accordance with [SMIME] and sent to a receiving agent's server SHALL be 477 considered non-repudiable. 479 To satisfy the non-repudiation requirements, the receiver of the message 480 MUST support revocation mechanisms for the certificates of the potential 481 senders of the SCMP messages that are accepted by the server application. 483 7.2. Application issues 485 The server MUST evaluate the signature of the message, if the message 486 is of signed or signed/enveloped type, prior to processing the message 487 payload. In performing this authentication process, the server MUST 488 validate the senders certificate and verify that the senders certificate 489 is not listed in any available revocation systems. 491 Assuming the SCMP message's signature is valid, the server will process 492 requests with the appropriate service designated by the SCMP-message-type value. 494 7.2.1. Request Serialization 496 A server SHOULD NOT guarantee serialized request processing. If requests 497 must be serialized, it is expected that all of the serialized 498 transactions will be received in a single message payload or that other 499 content specific serialization systems will be used. 501 7.2.2. Server Errors 503 A server may encounter several classes of error conditions. The 504 server MUST be capable of reporting an error as described in section 8 505 of this document. Error Detection may vary based on specific 506 implementation. 508 A server MUST be capable of detecting a duplicate scmp-request-id 509 and reply to the sending client application with an appropriate SCMP 510 error message. Duplicate request detection MUST be based on the 511 scmp-request-id and the distinguished name of the signer to prevent 512 denial of service attacks. 514 8. Protocol Level Error Messages 516 In general SCMP does not concern itself with application level errors. 517 Such errors MUST be returned in an SCMP reply with appropriate 518 application specific formatting. 520 8.1. Format 522 SCMP error messages MUST be signed SMIME messages. SCMP errors 523 MUST NOT be encrypted to permit clients to process encryption related 524 errors. 526 The format of SCMP errors is: 528 SCMP 530 Where the format of "error number" is a digit or digits as defined in 531 [RFC822] and "error message text" is text as defined in [RFC822]. 533 8.2. Client Application Error Handling 535 Client action in the case of error return is error specific and not 536 defined. If the server fails to return any reply within the time to 537 live requested (due to unspecified server or network failure) the 538 client MAY re-send the request. Clients MUST NOT retry a request in 539 an interval which is less than the time to live value of the original 540 request. 542 9. Security Considerations 544 Security considerations are addressed throughout this document. 546 9.1 Encryption Strength 548 It is recommended that strong enough cryptographic methods be used to 549 ensure authenticity, integrity, non-repudiation, and privacy of the 550 payload. 552 9.2 Non-repudiation 554 Non-repudation implimentation is specified in section 7.1.2. 556 As addressed above, this document does not describe how a sending agent 557 may support non-repudiation. The intent of this document does describe 558 how a receiving agent can support non-repudiation. 560 If the receving agent accepts and processes a transaction after the 561 private key of the sending agent has been comprimised, that request is 562 refutable, or not non-refutable. 564 9.3 Public Certificate Considerations 566 9.3.1 Certificate Exchange 568 Every trading partner implementing SCMP SHOULD exchange certificates 569 that have been issued and signed by one or more mutually trusted 570 certificate authorities. Prior to establishing trading partner 571 relationships, the sender and receiver SHOULD acquire mutually 572 acceptable public root certificates from the agreed upon certificate 573 authority or authorities. 575 Sending and receiving agents MAY utilize certificate only messages to 576 exchange certificates as specified in [SMIME]. 578 9.3.2 Certificate Authentication and Revocation 580 Trading partners, upon receiving or exchanging public key certificates 581 for the first time, SHOULD validate the certificate and certificate 582 chain before processing an SCMP request. 584 A server certificate revalidation policy, related to the frequency 585 certificates are revalidated against a certificate authority's 586 certificate revocation list, is not specified by SCMP. This matter is 587 left as a policy decision for the operator of the SCMP server. 589 The timestamp of a certificate revocation event SHOULD be the time the 590 private key was known to be comprimised, or the time that the revocation 591 event was made. 593 9.4 Private Key Considerations 595 9.4.1 Private Key Generation 597 Private key generation should be of a secure manner as not to jepordize 598 the integrety of the private key. 600 9.4.2 Private Key Storage 602 The sending agent, maintaining a SCMP client application, MUST 603 maintain the private key in a secure location. 605 9.4.3 Private Key Revocation 607 Should a sending agent loose control of their private key, they MUST 608 notify the agreed upon, trusted, certificate authority. This 609 notification mechanism is not defined in this document, and should 610 be done via an out of band mechanism. 612 9.5 Request Id 614 The request id MUST be unique as to prevent possible replay attack 615 senarios. 617 10. SCMP Message Example 619 [ OUTER MIME START ] 620 Content-Type: application/pkcs7-mime 621 Content-Transfer-Encoding: base64 622 Content-Length: 1024 623 SCMP-protocol-version: 2.0 624 SCMP-sender-name: Adobe 626 [ INNER MIME START - enveloped entity ] 627 SCMP-request-time-to-live: 90 628 SCMP-message-type: Commerce/2.0 629 SCMP-request-id: 0123456789012345678901 630 Content-Type: application/pkcs7-mime 631 Content-Transfer-Encoding: base64 632 Content-Length: 512 634 [PAYLOAD - signed entity ] 636 [ INNER MIME END ] 637 [ OUTER MIME END ] 639 11. Author's Address 641 Tom Arnold 642 CyberSource Corporation 643 550 S. Winchester Blvd., #301 644 San Jose, CA 95128 645 E-mail: toma@cybersource.com 646 Phone: 408-556-9100 648 Jason Eaton 649 CyberSource Corporation 650 550 S. Winchester Blvd., #301 651 San Jose, CA 95128 652 E-mail: jeaton@cybersource.com 653 Phone: 408-556-9100 655 Michael Jimenez 656 CyberSource Corporation 657 550 S. Winchester Blvd., #301 658 San Jose, CA 95128 659 E-mail: mjimenez@cybersource.com 660 Phone: 408-556-9100 662 Hubert Chen 663 CyberSource Corporation 664 550 S. Winchester Blvd., #301 665 San Jose, CA 95128 666 E-mail: hubertc@cybersource.com 667 Phone: 408-556-9100 669 12. Acknowledgements 671 The authors wish to recognize and thank several individuals 672 (listed in alphabetic order) who have and continue to 673 support the development of requirements and improvement of 674 this protocol. 676 Mike Agostino (Vulcan), Ron Bose (LitleNet), David Burdett (Mondex), 677 Leonard Cantor (IBM), Dan Corcoran (Equifax), Steve Crocker 678 (Crocker Assoc.), Tony Curwen (Ingram Micro), Donald Eastlake (IBM), 679 Richard Frank (Intertrust), James Gavin (Commercenet), Paul 680 Guthrie (VISA International), Bengamin Hipp (FUSA/Paymentech), 681 Andy Jeffrey (Sonnet Financial), Helle Jespersen (IBM), 682 "Sean Kiewiet" , Connie Lindgreen (IBM), 683 Michael Myers (VeriSign), Allan Ottosen (PBS), John Pettitt 684 (Beyond.com), Jesse Rendleman (CyberSource), Don Sloan 685 (Tech Data), Carl Stucke (Equifax), Frank Tyksen (Portland 686 Software), Huy Vu (VISA USA), Sean Youssefi (CobWeb) 688 13. References 690 [SMIME] S. Dusse, et. al, "S/MIME Version 2 Message 691 Specification", RFC 2311, IETF, March 1998. 693 [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 694 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 695 3: Message Header Extensions for Non-ASCII Text", RFC 696 2047; "MIME Part 4: Registration Procedures", RFC 697 2048; "MIME Part 5: Conformance Criteria and 698 Examples", RFC 2049, IETF. 700 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 701 Levels", RFC 2119, IETF. 703 [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, 704 September 1989. 706 [PKCS-7] B. Kaliski, "PKCS #7: Cryptograpic Message Syntax" 707 RFC 2315, IETF, March 1998. 709 [RFC822] D. Crocker, "Standard for the format of arpa internet 710 text messages", RFC 822, IETF, August 1982. 712 [X.520] "ITU-T Recommendation X.520: Information Technlogy - 713 Open Systems Interconnection - The Directory: Selected 714 Attributes Typs, 1993.