Fwd: Re: SCMP V.07 to Informational RFC

I've just posted a revised draft of SCMP (it should be up in a few days) 
that deals with the negotiation of payload content between trading partners 
prior to processing requests.

In Patrik's notes, he raises a few additional points (one of which is 
transport negotiation). I'm wondering if this should be handled in the same 
manner as payloads or if I should specify http?  Any thoughts?

>X-Sender: pfaltstr <at> nordic.cisco.com
>Date: Thu, 10 Aug 2000 06:56:45 +0200
>To: Tom Arnold <toma <at> cybersource.com>
>From: Patrik Fältström <paf <at> cisco.com>
>Subject: Re: SCMP V.07 to Informational RFC
>Cc: "Jeffrey I. Schiller" <jis <at> mit.edu>, Ned Freed <Ned.Freed <at> innosoft.com>,
>         "Marcus Leech" <mleech <at> nortelnetworks.com>
>
>At 11.48 -0700 00-07-31, Tom Arnold wrote:
>>Patrik, this is a resend as I had your old email address... I also sent a 
>>copy of this to Jeff and Marcus, Security Area Directors.
>
>I have checked draft-arnold-scmp, and I don't see that it can be published 
>now either.
>
>The document doesn't specify enough to ensure interoperability between two 
>independently developed applications which each is developed with _only_ 
>the paper in question as a basis.
>
>For example, you don't even define the error codes or transport protocol 
>to be used! How is that to be negotiated?
>

Re: SCMP

SCMP is still a draft. Our company implemented the protocol to process 
transactions for e-commerce sites. We want to finish posting this as an 
informational RFC describing an application implementation of a messaging 
protocol using SMIME. In recent comments, we were asked to describe the 
mechanism that a client and server negotiate the payload of an SCMP 
message. We're still playing with this.

At 03:11 PM 3/12/2001 -0700, you wrote:

>RE:http://www.imc.org/draft-arnold-scmp
>
>I found this paper while researching e-commerce.
>What is the current status of the SCMP project?
>
>Thank you,
>
>Paul Clark
>Albuquerque TVI
>E-Commerce Instructor

Thomas A. Arnold
Chief Technical Officer
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
PGP Fingerprint: 2EB6 F7F0 6D80 A8E5 9BEC  A05A 0295 0ADE 8F42 EB0D
PGP keys located on PGP and MIT servers at pgp.com and mit.edu
--------------------

SCMP V.07 to Informational RFC

Patrik, Jeff, and Marcus,

We feel that the latest version currently posted at 
http://search.ietf.org/internet-drafts/draft-arnold-scmp-07.txt
is ready to advance as an informational RFC. SCMP is an application 
implementation of a transaction messaging protocol of S/MIME v3. We feel 
that this should probably be through the applications area as the most 
obvious current use is as a real-time request and reply messaging protocol 
supporting electronic commerce. We have spent a lot of time working out the 
protocol and it is currently being used in passion, processing over 15M 
transactions a month. Additionally, two other companies have constructed 
independent implementations of SCMP to provide their own services on the Net.

Lastly, in light of the announcement by John Pawling related to the release 
of Version 1.7 of the S/MIME Freeware Library (SFL) as an implementation of 
SMIME v3, ESS for SMIME v3, and other functions, we feel this is very 
timely for the release of an RFC documenting an application of these RFC's. 
We are also investigating the prospect of replacing the current licensed 
RSA toolking that provides the SMIMEv3 functions with the SFL. Should this 
workout, we may release a SCMP reference library.

Please let me know your thoughts on moving this forward and what our next 
steps might be.

All the best,

Tom

===========================================
toma <at> cybersource.com

Re: SCMP ver 06 posted

> 
> No. We want to have the payload signed by the sending agent's private key, 
> authenticating that she produced the message and allowing us to verify the 
> integrity of the message. Then, we want the sending agent's application to 
> include the request_id, including this in the inner mime headers when the 
> inner MIME message is formed. Once this is done, the inner MIME message is 
> enveloped (encrypted to insure privacy). In accordance with the 
> construction of an SMIME message, this is MIME encapsulated, forming the 
> outer MIME message. The receiving agent's server opens the enveloped inner 
> MIME message using the receiving agent's private key, evaluates the signed 
> payload using the sending agent's private key, and then is ready to process 
> the request.
> 
> Would it help clarify this, if we added some explanation in with the example?
> 
I was irritated by the fact that the SCMP header were not signed at all. 

I think it would help to replace 

> >     [PAYLOAD - signed entity ]

by [SIGNEDPAYLOAD - a SignedData with payload as encapsulatedContent] 

Regards

> 
> 
> >[ OUTER MIME START ]
> >Content-Type: application/pkcs7-mime
> >Content-Transfer-Encoding: base64

Re: SCMP ver 06 posted

At 03:45 PM 5/31/00 +0200, you wrote:
> >
>[snip]
>the question was whether the SCMP-request-id is signed or not?

the request ID is in the inner MIME message and is enveloped.

the payload is signed. If there's a section of the text that is not clear, 
we need to fix it. Section 2 describes the message construction correctly 
and is consistent with the example. In essence, the payload is signed, then 
MIME encapsulated, forming the inner MIME message. This inner MIME message 
is enveloped (encrypted), then MIME encapsulated, forming the outer MIME 
message.

>The text and the example is not clear to me:
>Do you first encapsulate and then sign or the other way around?
>
>You example puts first a 'signed entity' and around it an
>'enveloped entity'. This doesn't seem to correspond to the
>text of the outer/inner construction.
>
>Do you actualy want to first encrypt the payload, and then
>add a signature around with the SCMP headers?

No. We want to have the payload signed by the sending agent's private key, 
authenticating that she produced the message and allowing us to verify the 
integrity of the message. Then, we want the sending agent's application to 
include the request_id, including this in the inner mime headers when the 
inner MIME message is formed. Once this is done, the inner MIME message is 
enveloped (encrypted to insure privacy). In accordance with the 

Re: SCMP ver 06 posted

Thanks for the comments Peter. Answers below.

At 07:34 PM 5/27/00 +0200, Peter Sylvester wrote:
>hi,
>
>Why is there a 'commerce' in the protocol name?

The first few implementations of the protocol have all been related to 
transport of messages related to commerce transactions. Also, as the 
protocol evolved, the clear use is related to a sending agent making a 
request from some receiving agent, then getting a reply from the receiving 
agent. After evaluating the implementations, it's clear the protocol is 
'simple' to implement and very efficient for handling many types of 
commerce transactions. Ergo, the name.

>Maybe somehow I am confused about the ordering of the signed and
>enveloped data. It seems to me that the example does it the wrong
>way, in particular the SCMP-request-id: 0123456789012345678901
>is not signed? Or do you mean by
>  [ OUTER MIME START ]
>a signedData structure, thus triple wrapping of ESS?

We looked at mandating triple wrapping, but opted not to implement this. We 
wanted the SCMP-request-id to be outside the encrypted payload so that the 
receiving agent's server could have a unique handle to the message prior to 
decrypting should an error condition exist. In this manner, both the 
receiving and sending agent's systems would have a known value to reference 
the error condition.

>Some nit-picking:

SCMP ver 06 posted

Version 06 of the SCMP draft has just been posted. The major change in this 
draft was to revise a few of the terms (specifically the definition related 
to RFC 2119), and to move the definition of terms up before the 
requirements section (where some of the terms are used.....  'duh')....

Thomas A. Arnold
Chief Technical Officer
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.

Fwd: Revised version of SCMP posted.

Revised version of SCMP posted.

I-D ACTION:draft-arnold-scmp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Simple Commerce Messaging Protocol (SCMP)
	Author(s)	: T. Arnold, J. Eaton
	Filename	: draft-arnold-scmp-04.txt
	Pages		: 12
	Date		: 05-Oct-99
	
The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 
electronic commerce message protocol for secure, real-time 
communication of a set of data from a sending agent's application 
to a receiving agent's server. Additionally the response by the 
receiving agent's server to the sending agent is the reply from the 
request represented by the set of data in the message's payload. The 
intent of this protocol is to define a method where trading partners can 
perform on-line business requests in an environment where the sending 
partner is fully authenticated, and the message cannot be repudiated.
The taxonomy of the SCMP message payload is not in the scope of this 
document. The SCMP protocol does not specify payload definitions or 
how trading partners are expected to process the payload, beyond basic 
server-level functions related to processing SCMP headers. This intent 
is to permit trading partners the flexibility to implement either a 
standard commerce message format as in ANSI-X12 Electronic Data 
Interchange (EDI) or some other non-standard payload format. This 
document does give an example implementation of a payload format
based on [XML]. 
The only requirement on the message payload is that it be prepared
as specified in [MIME].
In this manner, SCMP fundamentally differs from many emerging  
commerce message protocols. Beyond specifying the method for
encryption, authentication and handling, these other protocols 
specify the contents of the message and details how a server is to 
process and respond to a given message payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arnold-scmp-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-arnold-scmp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-arnold-scmp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<19991005121948.I-D <at> ietf.org>

ENCODING mime
FILE /internet-drafts/draft-arnold-scmp-04.txt

<ftp://ftp.ietf.org/internet-drafts/draft-arnold-scmp-04.txt>

RE: Update

Manros brings up a good point. I blew it and included the incorrect
signature file to my last mail message. If I offended anyone, please excuse
this indescretion. Hope you all will take a look at the document as it is
filed when it comes out.  

Tom

>From: "Manros, Carl-Uno B" <cmanros <at> cp10.es.xerox.com>
>To: Tom Arnold <toma <at> cybersource.com>
>Cc: "Manros, Carl-Uno" <manros <at> cp10.es.xerox.com>
>Subject: RE: Update
>Date: Tue, 5 Oct 1999 10:25:37 -0700 
>X-Mailer: Internet Mail Service (5.5.2448.0)
>
>Tom,
>
>The note at the end of your message is a strange one for an open IETF email
>list!
>I assume it is attached to ALL your outgoing mail, but still...
>
>Carl-Uno Manros
>
>> -----Original Message-----
>> From: Tom Arnold [mailto:toma <at> cybersource.com]
>> Sent: Tuesday, October 05, 1999 6:49 AM
>> To: ietf-scmp <at> imc.org
>> Subject: Update
>> 
>> 
>> We have taken comments on draft 3 (currently posted) and have produced
>> draft 04. The primary changes are in two areas:
>> 
>> - Some wordsmithing related to non-repudiation
>> 
>> - Added an XML payload example. This has actually been a hot 
>> issue in that
>> our original intent was to define a protocol that was 
>> completely payload
>> independent. That being said, we went ahead and produced a section
>> describing how a XML DTD and data would be encapsulated and 
>> transported in
>> an SCMP message. We have struck a compromise in that we 
>> illustrated how an
>> XML message would be delivered, not defining any type of 
>> message taxonomy.
>> Groups like Rosetta Net, CompTIA, DISA, EDIInt, IOTP, OBI, 
>> and others using
>> private protocols are responsible for providing actual 
>> message definition.
>> 
>> Our intent and belief is that this version is ready to become an
>> Informational RFC. Once I receive confirmation that the draft has been
>> posted, I'll notify the list.
>> 
>> 
>> 
>> Thomas A. Arnold                                CyberSource 
>> Corporation
>> Chief Technical Officer                         550 S. 
>> Winchester Bl. #301
>>                                                 San Jose, CA 95128
>> toma <at> cybersource.com                            Direct: 1.408.260.6010
>> http://www.cybersource.com/                     Main: 1.408.556.9100
>> --------------------------------------------------------------
>> -------------
>> This Email and any attached files are confidential and may also be 
>> privileged. It is intended only for the individual or entity to whom 
>> it is addressed. If you are not the recipient or an authorized agent 
>> of the recipient, you are hereby notified that any use, 
>> dissemination, 
>> distribution or copying of this communication is strictly prohibited. 
>> If you have received this message in error, please contact 
>> CyberSource 
>> Corporation immediately at (408) 556-9100.
>> 
>> Thank you.
>> 
>
>