idnits 2.17.1 draft-arnold-scmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-arnold-scmp-00.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-arnold-scmp-00.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-arnold-scmp-00.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-00.txt)', but the file name used is 'draft-arnold-scmp-00' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 496 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 a Security Considerations 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 21 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 6 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: Security', 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) == Missing Reference: 'HOUSLEY' is mentioned on line 335, but not defined ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-05 == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-06 ** Obsolete normative reference: RFC 1119 (ref. 'NTP') (Obsoleted by RFC 1305) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS-7' Summary: 15 errors (**), 1 flaw (~~), 8 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: Security Jason Eaton (CyberSource) 3 August 31, 1998 Michael Jimenez (CyberSource) 4 Expires in six months 6 Simple Commerce Messaging Protocol (SCMP) 7 (draft-arnold-scmp-00.txt) 8 Version 1 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and working groups. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 1. Introduction 30 The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 31 commerce transport protocol for securely communicating a set of data 32 from a sending agent's application to a receiving agent's server. And, 33 where the response by the receiving agent's sever to the sending agent 34 is, in fact, the reply from the transaction represented by the set of 35 data in the message's payload. The intent of this protocol is to 36 define a method where trading partners can perform on-line business 37 transactions in an environment where the sending partner is fully 38 authenticated, and the message cannot be repudiated. 40 The SCMP message content, hereinafter referred to as message payload, 41 is not intended to be defined or specified. SCMP does not specify 42 payload contents or how trading partners are expected to process 43 the payload, beyond basic server-level functions related to processing 44 SCMP-headers.This intent is to permit trading partners the flexibility 45 to implement either a standard commerce message format as in ANSI-X12 46 Electronic Data Interchange (EDI) or some other proprietary 47 transaction format. 49 The only requirement on the message payload is that it be identified to 50 the receiver utilizing MIME naming and formatting [MIME] and used to 51 identify the type of payload contained in the SCMP data area. 53 In this manner, SCMP fundamentally differs from many emerging 54 commerce message protocols. Beyond specifying the method for transport, 55 encryption, authentication and handling, these other protocols 56 specify the contents of the message and details how a server is to 57 process and respond to the message payload. 59 SCMP is intended as both an on-line and batch protocol. The exact 60 content of the message and the processing constraints are specified in 61 SCMP-headers. 63 1.1. Document Overview 65 This document describes SCMP from the standpoint of how trading partners 66 would implement a client/server transaction processing system where a 67 sending agent requests services via an untrusted network connection from 68 a server-based receiving agent. 70 In this environment, the typical requirements for authentication, non- 71 repudiation, message integrity, and privacy as discussed in [SMIME] and 72 assured by the proper use of the Secure/Multipurpose Internet Mail 73 Extensions [SMIME]. Beyond this, the trading partners require service- 74 based extensions to standard MIME and SMIME security services. These 75 service-based extensions are described within this document, while it is 76 assumed the trading partner will implement MIME and SMIME services as 77 described in [MIME] and [SMIME] respectively. 79 1.2. Terminology 81 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 82 are used in conformances to the definitions in [MUSTSHOULD]. 84 1.3. Definitions 86 Several terms will be used when specifying SCMP. 88 Trading Partners Two entities wishing to perform some on-line 89 transaction processing where authentication, 90 privacy, integrity and non-repudiation of the 91 transactions are important. 93 Client An application program that executes on a remote 94 system, used by a trading partner to request 95 services from a server via an un-trusted or 96 publicly switched packet network, like the 97 Internet. 99 Server An application program used to process SCMP 100 messages received from a client, and generate 101 appropriate replies which are sent back to the 102 client. 104 Transaction A discrete unit of service embodied in a single 105 SCMP message/reply pair. 107 Payload The meaningful content provided by a client to a 108 server, encapsulated in an SCMP message. Similarly 109 the meaningful content provided by a server to a 110 client, encapsulated in an SCMP message. 112 Request An SCMP message sent from a client to a server. 114 Reply An SCMP message sent from a server to a client. 116 Services Algorithms implemented by the server application 117 which are executed as designated by the payload. 118 Each available algorithm is a service. 120 2. Payload Encapsulation 122 The payload of an SCMP message MUST be prepared as a standard MIME 123 entity as defined in the [MIME] specification. The [SMIME] document 124 describes how the resulting MIME entity SHOULD be cryptographically 125 enhanced according to [CMS], which is derived from PKCS #7, [PKCS-7]. 127 An SCMP compliant server MUST implement three message types as described 128 in [SMIME], signed, enveloped, and signed/enveloped. 130 This document does not designate specific encryption algorithms or SMIME 131 message types. However, it is recommended, for non-repudiation concerns 132 that the trading partners SHOULD exchange signed or signed/enveloped 133 SCMP message types. 135 It is also recommended that strong enough cryptographic methods 136 be used to insure authenticity, integrity, non-repudiation, and privacy 137 of the payload. But, if the trading partners form a private agreement, 138 clear data or signed-only data MAY be exchanged. However, an SCMP 139 compliant server MUST support encryption even if encryption is not being 140 used. 142 3. SCMP Service-based Headers 144 This section describes the service-based extensions that MUST be 145 implemented by both the client and server to insure correct and proper 146 transaction processing. Processing the SCMP service headers is the 147 responsibility of the application processing the request. 149 3.1. Quality of Service: 151 This describes the amount of actual processing time in seconds the client 152 expects the server to fully complete payload processing prior to 153 responding with and appropriate error message, or reply. 155 An SCMP server receiving a SCMP message MUST evaluate the quality of service 156 value and determine if it can execute the required service(s) in the amount 157 of time designated by the quality of service header. Assuming the server 158 believes it can complete the work within the allowed time, it will accept 159 the job. If not, it MUST return an error to the client stating it could not 160 accept the transaction. 162 Once a server has accepted a job, it MUST process it until the quality of 163 service value has been reached or until completion. If the quality of 164 service value is reached during execution, the server MUST return an error 165 to the client stating that a timeout has occurred. Measures to ensure data 166 integrity after the quality of service value has been exceeded will be the 167 responsibility of the implementation. 169 The quality of service header will be in this format: 171 SCMP-quality-of-service: [batch | {0..n seconds}] 173 An SCMP-quality-of-service value of "batch" MUST cause the server to 174 respond with an acknowledgement reply to the client. The server SHOULD 175 then process the message according to an appropriate schedule and respond 176 to the client as appropriate after completing the actual processing. 177 Additionally, "batch" designates that there are no "real-time" quality of 178 service requirements for that SCMP message. 180 3.2 Return Path: 182 This describes the method used to respond to the client after completion 183 of a "batch" request. The client will not be notified upon "batch" 184 request completion if the return path is empty. 186 Return Path is specified as follows: 188 SCMP-return-path: "[protocol]:[destination]" 190 The list of protocols supported MUST be furnished via a private agreement 191 between trading partners. 193 Destination MUST be a valid value relative to the specified protocol. 194 For example: 196 SCMP-return-path: smtp/someone@host.domain 198 3.3. Message Type: 200 This value specifies the type of payload that is contained in the SCMP 201 message. The intent of this header is to provide a meta-level 202 description of the message payload and allow a receiving server to 203 decide which services or associated algorithms to use in processing 204 the payload. The message type value SHOULD NOT be the sole 205 specifier of the services being requested by a client from a 206 server. The list of services to be performed on a specific payload 207 SHOULD be included in the message payload. 209 Message type is specified as follows: 211 SCMP-message-type: "[service-name]/[version-number]" 213 The assignment of service names MUST be provided by the server to a 214 client at the time a service is published. For instance, if a service 215 was published called "CommerceService", the SCMP-message-type might 216 be represented as: 218 "SCMP-message-type: CommerceService/1.0" 220 It is assumed that trading partners will agree on service names 221 before transactions are processed. Additionally servers MUST allow 222 service names to be configurable, reguardless of what the algorithm 223 which implements the service does. 225 3.4. Transaction ID: 227 A value in the format described in [822] for the Message-ID header 228 with the left part constrained to be a numeric value "message-number 229 @host.domain". Transaction ID's MUST be generated by the client 230 application. The Transaction-ID of the reply will be the inbound 231 Transaction-ID with a "Reply-" pre-appended. 233 An example of a request Transaction-ID is: 235 SCMP-transaction-id: 123456789@host.somewhere.com 237 A corresponding example reply Transaction ID would be: 239 SCMP-transaction-id: Reply-123456789@host.somewhere.com 241 The message-number portion of a Transaction ID's SHOULD (except as 242 required for error recovery) be unique and SHOULD NOT be easy to 243 predict to prevent a potential denial of service attack. A client 244 application when preparing the message-number portion should perform a 245 random number generation with sufficient degrees of randomness 246 so as to insure uniqueness and unpredictability of the result. 248 Servers MAY use a Transaction-ID as a reference and handle to the 249 original transaction. 251 3.5. Additional Header Information: 253 In addition to to the payload (inside MIME entity) headers stated in 254 sections 3.1-3.4, use of the remaining standard SMIME (outside MIME entity) 255 headers are assumed. This includes any additional implementation-specific 256 headers. These headers will most likely be ones that need to be processed 257 prior to payload decryption. 259 4. SCMP Data Block (Message Payload) 261 The payload or data block can be any arbitrary data type in the format as 262 specified by the SCMP-message-type. This payload forms the content of the 263 SMIME message as described in [SMIME]. 265 5. Certificates 267 Every trading partner implementing SCMP MUST exchange certificates that 268 have been issued and signed by one or more mutually trusted certificate 269 authorities (CA). These certificates are used to guarantee the 270 authenticity of public keys. Prior to establishing trading relationships 271 on the basis of SCMP transactions, sender and receiver MUST have 272 acquired mutually acceptable trusted public root certificates in a trusted, 273 secure, out-of-band manner. 275 Trading partners, upon receiving or exchanging public key certificates 276 for the first time, SHOULD validate the certificate and certificate chain 277 before processing an SCMP transaction. 279 It is also recommended that the trading partners re-validate any 280 certificates and certificate chains on a scheduled basis. 282 Upon establishing a relationship between trading partners, the recipient 283 of a new certificate (the server in most cases) SHOULD validate the 284 certificate as soon as is practically possible. Certificate re- 285 validation policy, related to the frequency known certificates are 286 revalidated against a certificate authority's certificate revocation 287 list, is not specified by SCMP. This matter is left as a policy decision 288 for the operator of the SCMP server. 290 6. Transport Implementations 292 SCMP can be implemented using any variety of transport methods as agreed 293 between trading partners. Here are a few examples. 295 http: This delivers a SCMP message to a server URL and should 296 use a PUT function. 298 electronic mail: This will support a queued batch processing service 300 diskette: SCMP message as a text file 302 7. Receiving Server Functions 304 This section describes minimal server functions required to implement 305 SCMP. 307 7.1. General 309 A SCMP server receives a message from a client, processes the message 310 and generates a reply. If the message type is signed or signed/enveloped 311 the server initially validates the outer signature. If the outer signature 312 is not valid the server MUST NOT process the transaction further. 314 7.1.1. Message Timestamp 316 The time a transaction was sent will be derived from the standard SMIME 317 date header. If a client is specifying a quality of service other than 318 "batch", the client SHOULD be synchronized using [NTP] or Secure NTP. 319 The sender of an SCMP message will place the time a message was 320 dispatched into the SMIME header in [MIME] format. The message timestamp 321 SHOULD be included in the SCMP payload if possible and used, in 322 combination with the transaction ID, by the server to prevent a replay 323 attack. 325 It is recommended that servers run a client-visible NTP server to 326 allow sending agents running SCMP client applications to synchronize 327 clocks as required. 329 7.2. Application issues 331 The server SHOULD evaluate the signature of the message, (if the message 332 is of signed or signed/enveloped type ), prior to processing the message 333 payload. Within this process the server SHOULD obtain the senders 334 certificate via. the distinguished name in the certificate as described 335 in [HOUSLEY]. 337 Assuming the SCMP message's signature is valid, the server will process 338 transactions based on the SCMP-message-type value. Transactions may be 339 processed on-line or in batch mode, depending on the value of the 340 SCMP-quality-of-service header. 342 7.2.1. Quality of Service and Time 344 Assuming the SCMP-quality-of-service header is integer representing a 345 number of seconds (i.e., not "SCMP-quality-of-service: batch"), the 346 receiving server MUST determine if the quality of service is 347 attainable. In this function, the server will evaluate if sufficient 348 time has been allotted for the application functions to be completed. 349 Assuming the server determines the quality of service time allotted 350 is attainable, the server will begin processing the transaction. 352 Once a server has started processing a transaction, the server MUST 353 NOT terminate due to inability to meet the quality of service time 354 value. 356 In the event the server is unable to complete and reply within the 357 quality of service time value, the server MUST reply to the client 358 with a time-out error message. The server will finish processing the 359 transaction and continue processing the next SCMP message. 361 A client, having received a time-out error message, SHOULD send a 362 "request status message" to the server, referencing the original 363 SCMP-transaction-id (from the message that timed out) in the message 364 payload. The server's reply to this status message would be the reply 365 that would have been sent had the processing time not exceeded the 366 quality of service metric. 368 7.2.2. Transaction Serialization 370 A server may not guarantee serialized transaction processing. If 371 transactions must be serialized, it is expected that all of the 372 serialized transactions will be received in a single message 373 payload or that other content specific serialization systems will be 374 used. 376 7.2.3. Server Errors 378 A server may encounter several classes of error conditions. The 379 server MUST be capable of reporting an error as described in section 8 380 of this document. Detection may vary based on specific implementation. 382 A server MUST be capable of detecting a duplicate SCMP-transaction-id 383 and notify the sending client application of the duplicate transaction. 384 Duplicate transaction detection MUST be based on the SCMP-transaction- 385 id and the distinguished name of the signer to prevent denial of service 386 attacks. Servers MUST take steps to prevent error conditions in which 387 transaction retries overlap the original transaction processing. In this 388 case the server MUST NOT respond to the retry until the original result 389 is available. 391 In the event of a duplicate transaction being detected the server MUST: 392 1) lookup the prior transaction 393 2) verify the sender is the same; and 394 3) return an appropriate error message to the client. 396 8. Protocol Level Error Messages 398 In general SCMP does not concern itself with application level errors. 399 Such errors MUST be returned in an SCMP reply with appropriate 400 application specific formatting. 402 8.1. Format 404 SCMP error messages are returned by a server as signed data. Errors MUST 405 NOT be encrypted to permit clients to process encryption related errors. 407 The format of SCMP errors is: 409 SCMP-Error: 411 [To do - Need to define error numbers/error message text or domains 412 of error numbers -something like http? ] 414 8.2. Client Application Error Handling 416 Client action in the case of error return is error specific and not 417 defined. If the server fails to return any reply within twice the 418 quality of service requested (due so unspecified server or network 419 failure) the client SHOULD re-send the transaction. Upon receipt of the 420 duplicate transaction the server will respond as described in 7.1.3. 421 clients MUST NOT retry transactions in less than the quality of service 422 interval of the original transaction. 424 A server MAY want to provide the function to allow a client application 425 to send a status request referencing the original transaction-ID. In 426 this situation, a server SHOULD return the values of the reply from the 427 original transaction request (identified by the transaction-ID). 429 9. Author's Address 431 Tom Arnold 432 CyberSource Corporation 433 550 S. Winchester Blvd., #301 434 San Jose, CA 95128 435 E-mail: dptom@cybersource.com 436 Phone: 408-556-9100 438 Jason Eaton 439 CyberSource Corporation 440 550 S. Winchester Blvd., #301 441 San Jose, CA 95128 442 E-mail: jeaton@cybersource.com 443 Phone: 408-556-9100 445 Michael Jimenez 446 CyberSource Corporation 447 550 S. Winchester Blvd., #301 448 San Jose, CA 95128 449 E-mail: mjimenez@cybersource.com 450 Phone: 408-556-9100 452 10. Acknowledgements 454 Several persons (in alphabetic order) have contributed, and continue to 455 contribute significantly through their participation in an industry- 456 based EMAP (Electronic products Messaging and Protocol) committee. 457 Through their participation and continued support SCMP will continue to 458 develop into a functioning, on-line Internet commerce messaging 459 protocol. Their contributions are greatly appreciated. 461 Ron Bose (LitleNet), Len Cantor (IBM), Hubert Chen (CyberSource), Tony 462 Curwen (Ingram Micro), Mike Myers (Verisign), John Pettitt (Beyond.com), 463 Jesse Rendleman (CyberSource), Don Sloan (Tech Data), Frank Tyksen 464 (Portland Software) 466 11. References 468 [822] D. Crocker, "Standard for the format of ARPA Internet 469 text messages." RFC 0822, IETF, Aug. 1982. 471 [SMIME] Blake Ramsdell, "S/MIME Message Specification", 472 work in progress, IETF Internet Draft, draft-ietf- 473 smime-msg-05.txt, Aug. 1998. 475 [CMS] R. Housley, "Cryptograpic Message Syntax", work 476 in progress, IETF Internet Draft,draft-ietf- 477 smime-cms-06.txt, June. 1998. 479 [MIME] "MIME Part1: Format of Internet Message Bodies", RFC 480 2045; "MIME Part2: Media Types", RFC 2046; "MIME Part 481 3: Message Header Extensions for Non-ASCII Text", RFC 482 2047; "MIME Part 4: Registration Procedures", RFC 483 2048; "MIME Part 5: Conformance Criteria and 484 Examples", RFC 2049, IETF. 486 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 487 Levels", RFC 2119, IETF. 489 [NTP] D. Mills. "Network Time Protocol", RFC 1119, IETF, 490 September 1989. 492 [PKCS-7] B. Kaliski, "PKCS 7: Cryptographic Message Syntax 493 Version 1-5", IETF, March 1998.