Privacy

 At Citibank we have implemented an S/Mime based payment file delivery 
system.(You will find the "Global file Handler" listed on the S/Mime 
interoperability matrix at the RSA site). I am not involved in real-time 
processing, such as would be facilitated by the HTTP mechanism, so concern my 
comments to the S/Mime implementation of the SCMP only.

 There have been a number of references to applications only needing a signed 
reply. This may be true but I do not know what these applications are, even so 
I still cannot conceive of a situation where it would be unacceptable to 
encrypt a reply as well as sign it. You will understand that a financial 
organisations' standpoint is frequently to err on the side of caution; If it 
can be signed and encrypted then it MUST be, if it can not be encrypted then is 
the information insensitive enough to transmit it signed only and if it can not 
be signed then the exposure is almost certainly too great.

 At the time of development we were unaware of the existence of the SCMP and 
have implemented simply signed-THEN-encrypted S/Mime. In order to try to 
protect the identity of our customers we have mandated that the minimum only 
Mime headers required for successful routing should be specified outside the 
encrypted message body.

 We would be very interested in enhancing our solution to be SCMP compliant but 
consider that the public "SCMP-protocol-version" and "SCMP-sender-name" field 
present an unacceptable and unnecessary exposure of sensitive information. We 
would like to see the following, material, alterations:

2. Payload Encapsulation
:
(In my interpretation the following paragraph actually contradicts itself.)
>An SCMP compliant server SHOULD implement the three message types as 
>described in [SMIME], signed, enveloped, and signed/enveloped. An SCMP 
>compliant server MUST implement signed/envelope message type as 
>described in [SMIME]. 

An SCMP compliant server MUST implement signed/envelope message type as 
described in [SMIME]. An SCMP compliant server SHOULD implement the two
message types signed and enveloped as described in [SMIME]. An SCMP compliant
server SHOULD support nesting of message types as described in [SMIME].
:
(Error messages which relate to security failures should be sent via another 
communication mechanism.)
>SCMP error messages MUST be of signed type and NOT encrypted.

SCMP error messages MUST be signed and MUST be encrypted according to the 
encryption
status of the incoming message to which they relate i.e. An error message 
relating to an 
encrypted incoming message MUST be encrypted and an error message relating to a 
signed only incoming message MUST NOT be encrypted. 
:
(I do not think that it is acceptable for ANY fields to exist outside a signed 
component.)
(I think that, unless they are approved headers, they are required to have an 
x- prefix.)
>In addition to the standard MIME headers, a compliant implementation 
>MUST define "SCMP-protocol-version" and "SCMP-sender-name". These 
>headers added to the outer MIME entity, as described in [MIME]. 

Remove this paragraph and incorporate in section 3 SCMP payload-based Headers. 
There are a number of follow-on
effects as a result of removing these as outer headers.

--

The following are more general suggestions for enhancements:

1.1.5   Non-repudiation
:
>An Electronic Commerce provider will typically provide financial based 
>functionality such as authorization, settlement, and crediting, of 
>credit card accounts and/or merchant accounts. This functionality 
>requires that the Electronic Commerce Provider execute financial 
>transactions on behalf of the merchant, or trading partner. Therefore it 
>is desirable that the transaction directives which are given in an SCMP 
>message are non-refutable. 

An Electronic Commerce provider will typically provide financial based 
functionality such as authorization, settlement, and crediting, of 
credit card accounts and/or merchant accounts. This functionality 
requires that the Electronic Commerce Provider execute financial 
transactions on behalf of the merchant, or trading partner. Therefore it 
is mandatory that the transaction directives which are given in an SCMP 
message are non-refutable. 

2.1 SCMP Protocol Version
:
>The value of the protocol-version header MUST be in the following 
>format, any number of digits, followed by a the special character ".", 
>followed by any number of digits. Where special character, and digits is 
>defined in [RFC822].

(I would prefer to see an explicitly defined version number in this document
which implementations could be compliant with. In the same way as 
"Mime-Version: 1.0"
is specified in [MIME].)


7.1. General
:
>A SCMP server receives a message from a client, processes the message 
>and generates a reply. If the message type is signed or signed/enveloped
>the server initially validates the outer signature. If the outer 
>signature is not valid the server MUST NOT process the request further. 

A SCMP server receives a message from a client, processes the message 
and generates a reply. If the message type is signed or signed/enveloped
the server initially validates the outer signature. If the outer 
signature is not valid the server MUST NOT process the request further. A copy
of the file MUST be saved and the event MUST be logged in the server logfile
and an alert SHOULD be sent to the system administrator.

7.1.2 Support for Request Non-Repudiation
:
(The internet is an EXTREMELY dangerous place. Non-repudiation of all messages 
is highly 
desirable but non-repudiation of ALL commerce related transactions MUST be 
mandatory.
A perpetrator may generate spurious error messages which will fool the client 
into believing that
the server is experiencing severe problems or has had a complete failure. In 
the worst case, by
sending false "Time To Live exceeded messages" the client may be fooled into 
repeatedly
re-sending all transactions.)
>Implemenations MAY support non-repudation of error message replies. This 
>document addresses the non-repudation concerns of the server or 
>receiving agent. The non-repudiation concerns of the client or 
>sending agent MAY be fulfilled by the same means as the server or 
>receiving agent supports non-repudiation.

Implementations MUST support non-repudiation of error message replies. This 
document addresses the non-repudiation concerns of the server or 
receiving agent. The non-repudiation concerns of the client or 
sending agent MAY be fulfilled by the same means as the server or 
receiving agent supports non-repudiation.


Regards,
Bartley,



Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-171-500-6473
Fax +44-171-500-8880