Comments: draft-arnold-scmp-02.txt

[Graham Klyne <[e-mail]>]

In reviewing this, I see SCMP as potentially useful for more than just
*commerce* applications.  For example, requirements for legally sustainable
exchange of arbitrary message contents (e.g. contract exchange), or a
variety of other message passing applications with a need for
non-repudiation.  Thus, I see the specification of SCMP without reference
to any specific payload format as being a considerable strength.

One problem I will highlight up-front:  this has been last-called for
proposed standard, but contains normative references to an informational
RFC (RFC2311).  I don't think this is permitted.

The other difficulty I have with this, as presented, is that it seems to
lay down a number of requirements which I think would more properly be
indicated by the particular service being invoked (i.e. the
SCMP-message-type header value).

In making my comments to this document, I am sensitive that you have
indicated implementations already exist.  I don't believe any of my
comments would require any change to existing implementations.

And so to my detailed comments:


>            Simple Commerce Messaging Protocol (SCMP)
>                    (draft-arnold-scmp-02.txt)

[...]
>1. Introduction

>The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 
>commerce transport protocol for secure, real-time communication of
..........^^^^^^^^^ might this be better described as "message transfer"?

>a set of data from a sending agent's application to a receiving 
>agent's server. Additionally the response by the receiving agent's 
>sever to the sending agent is the reply from the request represented 
...^ (typo)

>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.

This last sentence seems to capture much of the intent;  I think that much
of the purpose outlined here could be described without specific reference
to "commerce" or "trading".  E.g.

# The intent of this 
# protocol is to define a method where communicating parties can perform 
# on-line message exchanges in an environment where the sending partner 
# is fully authenticated, and the message cannot be repudiated.

I can even see the SCMP acronym as "Simple Confirmed Messaging Protocol".

[...]
>The only requirement on the message payload is that it be identified to 
>the receiver utilizing MIME naming and formatting [MIME] and is used to 
.............................................................^
Is something missing here?

>identify the type of payload contained in the SCMP data area.


>1.1.1	Real-time Request and Response
>
>A single message containing all credential and payload data is 
>prepared by a sending agent and sent to a receiving agent. The 
>receiving agent, upon verification of sender's credentials, MUST 
>process the payload, format a reply, and respond to the sender as 
>the response to the inbound connection.
.............................^^^^^^^^^^  The term "connection" seems
wrong here;  "message" or "contact"?


>1.1.2	Message Privacy
>
>Through use of cryptographic methods, the privacy of the sender's 
>message payload MUST be assured should a message payload be 
>intercepted.

This seems to conflict with statements given later (section 2).

The use of a (capitalized) normative language keyword in a section that
purports to describe trading partner requirements (as opposed to protocol
requirements) seems out-of-place.

(Similar comments about normative language apply to the remaining 1.1.x
sections.)

[...]
>1.1.3	Authentication of Sending and Receiving Agents
>
>Messages between trading partners, as represented by sending and 
>receiving agents, MUST contain attributes that assure a given request 
>could only be from a specific trading partner.

I think it is also important (or can be important) that the response is
authenticated.

>1.1.4	Non-repudiation
>
>When a receiving agent's server receives a request to process a payload, 
>the receiving agent's application SHOULD guarantee that the sender 
>cannot, at some later time, refute having sent the request.
>
>Non-repudiation is defined as, the inability of either trading partner 
>(sender or receiver) to refute the sending of an SCMP request or SCMP 
>reply.

In reading through this document, I find other statements that seem to
emphasize non-repudiation of the original request, but not the response.
E.g. section 7.1.2 deals with support for request non-repudiation, but
there is no discussion of response non-repudiation.

One repudiation-related matter that I think bears some discussion is the
possible situation of a rogue server that does not send a response to a
request.  I believe that a watertight solution to this requires that (a)
one of the parties is trusted, or (b) use of a trusted third party.  I also
understand that, for many practical purposes, the partial solution proposed
is sufficient (e.g. for legal purposes) provided that an esablished pattern
of communication can be demonstrated, and proper transaction records are
maintained.  I think that some of these issues should be discussed in a
"security considerations" section.

>1.1.10  State Independence
>
>There MUST be no state dependency by either a sender's or receiver's 
>application on the messaging protocol.

I think that this conflicts with other parts of this document.  For
example, section 7.2.2 detection of duplicate requests, requires that a
server maintain state regarding requests that have been processed.

Also, to make sense of the request/response pattern of interactions, a
sender must maintain some state regarding outstanding requests in order to
take appropriate action when a response is received (or not received).

I think the appropriate requirement here is that state dependency should be
minimized.


>1.3. Definitions
>
>Several terms will be used when specifying SCMP.
>
>Trading Partners     Two entities wishing to perform some on-line 
>                     request processing where authentication, 
>                     privacy, integrity and non-repudiation of the 
>                     requests are important. Trading partners have
>                     established a trusted relationship between each
>                     other.

I can imagine applications where an established trusted relationship is not
needed before any exchange is initiated.   E.g. if I am using a credit card
to purchase from a Web site, there is not (in general) an established
relationship.

>Sending Agent        An entity that operates or uses a Client for 
>                     requesting on-line services from a server.
>
>Receiving Agent      An entity that operates a Server, receives and
>                     processes requests from a plurality of Clients.

I think the "agent" terminology is unfortunate here, in light of common
e-mail usage (where the "user agent", "transfer agent" typically refer to
software applications).

>Request              A discrete unit of service embodied in a single 
>                     SCMP message/reply pair.

Again, I think this terminology is unhelpful when compared with (say) HTTP
request/response usage.  "Exchange" or "transaction" might be less confusing.

>Message              An interchangeable term used to mean a Request.

Er... isn't this a (non-terminating) recursive definition?

[...]
>Services             Algorithms implemented by the server application
>                     which are executed as designated by the payload. 
>                     Each available algorithm is a service.

I would have thought a service was more than just an "algorithm".


>2. Payload Encapsulation
>  
>The payload of an SCMP message MUST be prepared as a standard MIME 
>entity as defined in the [MIME] specification. The [SMIME] document  
>describes how the resulting MIME entity SHOULD be cryptographically 
>enhanced according to [PKCS-7].

[SMIME] is a reference to RFC2311, which is an *informational* RFC and has
IPR encumbrance.

Personally, I would not want to see S/MIME version 2 mandated.

A solution, I suggest, is to mandate use of RFC 1847 security
encapsulation, and to allow the details of the security used to be dictated
by the SCMP-message-type header value.  (More comments on this later.)

>An SCMP compliant server SHOULD implement the three message types as 
>described in [SMIME], signed, enveloped, and signed/enveloped. A SCMP 
>compliant server MUST implement signed/envelope message type as 
>described in [SMIME]. 

I think these are service-dependent requirements.

>It is recommended, for non-repudiation concerns that the trading 
>partners SHOULD exchange signed or signed/enveloped SCMP message types.

This is a fair comment, but I'd avoid the normative language at this point
(since I see the issue as being service dependent).

>It is also recommended that strong enough cryptographic methods 
>be used to insure authenticity, integrity, non-repudiation, and privacy 
>of the payload. But, if the trading partners form a private agreement,
>clear data or signed-only data MAY be exchanged. However, an SCMP 
>compliant server MUST support encryption even if encryption is not being
>used. 

I disagree with the "MUST support encryption".  Again, I think this is
service dependent, and many applications would not need encryption.  There
is a possibility that this would impede global deployment of some
applications that don't need encryption.  Also, if I were to mandate
anything, it would be authentication.  

>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 [SMIME]. 
..........................................................^^^^^  [MIME]?

>Use of the remaining standard SMIME (outside MIME entity) headers are 
...............................^ ?
>assumed. This includes any additional implementation-specific headers.  
>These headers will most likely be ones that need to be processed prior 
>to payload decryption.  


>2.1 SCMP Protocol Version
>
[...]
>The possible protocol versions MUST be agreed upon by the trading 
>partners.

Why?  It would be a simple matter for a server to reject a protocol version
it cannot handle.  I think it would be more helpful to describe such
behaviour.

I think some formal syntax for the version number should be indicated, as
well as the value for this instance of the protocol.

>2.2 SCMP Sender Name
>
>The SCMP-sender-name header is used to designate the SCMP sender name.
>Thereby the sender name can be accessed before any decryption of the
>request is performed. Server implementations MAY reject the request
>based upon sender name, before any message processing occurs.
>
>An SCMP-sender-name header will be in this format:
>
>  SCMP-sender-name: CyberSource
>
>The possible sender names MUST be agreed upon by the trading partners.

I think some formal syntax for the sender name is needed (what are the
allowable characters, etc).

I think it might be useful to employ a scheme similar to that used by
RFC1894 to identify thne type of name; e.g.

    SCMP-sender-name: rfc822;[e-mail]

For backward compatibility, some default syntax could be applied in the
absence of the name type tag.  An IANA registry could be created for the
name type tags.


>3. SCMP Payload-based Headers
>
>This section describes the payload-based extensions that MUST be 
>implemented by both the client and server to insure correct and proper 
>request processing. 

This is a general comment about all headers:  it would be helpful to
indicate whether they MUST or SHOULD or MAY be included in request and
response messages.  (Saying that they must be implemented by both client
and server is not clear to me.)

[...]
>3.1. Request Time to Live
> 
>This describes the amount of actual processing time in seconds the 
>client expects the server to complete payload processing prior to 
>responding with an appropriate reply.

It's not clear to me whether a request MUST specify this header.  It is
clearly not needed in a response.

I would suggest that it's use should not be mandatory, and that in its
absence a server can take any "reasonable" (service dependent) amount of
time to service a request.

I think some comments about message transit times may be appropriate;  if
HTTP is being used then the TTL concept seems plausible, but if e-mail is
used, what is the value?  (But note there exists an SMTP deliver-by proposal.)

>The time to live header will be in this format:
>
>    SCMP-request-time-to-live: 0..n (seconds)

Again, a formal syntax would help here.

What is the meaning of a zero TTL?

>3.2. Message Type
>
>This value specifies the type of payload that is contained in the SCMP 
>message. The intent of this header is to provide a meta-level 
>description of the message payload and allow a receiving server to 
>decide which services or associated algorithms to use in processing 
>the payload.

To say that this specifies the "type of payload" suggests that it might be
a MIME content-type value.

I concur with a previous reviewer's comment that simply indicating prior
agreement between trading partners is not really satsifactory.

I think that an IANA registry of message types should be created, where
each registered message type indicates a number of related requirements:
   - the nature of the service
   - allowed payload content-type (request and response)
   - requirements for signing/encryption
   - allowed and required cryptography (e.g. S/MIME V2, S/MIME V3, OpenPGP,
etc.)
   - any other service requirements
   - message transfer mechanisms (HTTP, e-mail, etc.)

This information should be indicated separately for each version of a
message type.

I also think the message type name space should be constructed as a tree to
allow both IETF-approved values and private-use "vnd" values, similar to
the structure for MIME content sub-types.

>Message type is specified as follows:
>
>    SCMP-message-type: [service-name]/[version-number]

Again, formal syntax?

>The assignment of service names MUST be provided by the server to a 
>client at the time a service is published.

I don't really understand this.  In the presence of a regisry, I think the
poibnt is moot:  if a server receives a message type that it doesn't
understand, it can immediately respond with an error.

Finally:  I think that it should be permissable, or even the norm, to place
the message type *outside* any encryption envelope.

>3.3. Request ID
> 
>A value in the format described in [822] that identifies a 
>specific instance of a request. Request ID's MUST be generated 
>by the client application, thus assuring that the scmp-request-id 
>is available in the event that the request cannot be sent to 
>the server due to errors. 
>
>An example of a request scmp-request-id is:
>
>	scmp-request-id: 0917293049096167904518

I assume that the reference to "the format described in [822]" is a
reference to a "msg-id" value.  If so, the above example is incorrect,
because an RFC822 msg-id has the form of an e-mail address (e.g.
"[e-mail]").

>The scmp-request-id MUST be unique in the domain of a client 
>application and SHOULD NOT be easy to predict so as to prevent a 
>potential replay attack. 

Highlight this in a "security considerations" section.

>A client application, when preparing the scmp-request-id, SHOULD 
>perform a random number generation with sufficient degrees of 
>randomness, to ensure unpredictability, and generate a client side 
>time value, to ensure uniqueness of the result. These two data items 
>together SHOULD form the resulting scmp-request-id.

Highlight this in a "security considerations" section.

>Servers MAY use a scmp-request-id as a reference and handle to the 
>original request during server message processing. 

I assume the request-id should be specified in the server's response, so
the cliebnt can tie a response to its original request.


>4. SCMP Data Block (Message Payload) 
>
>The payload or data block can be any arbitrary data type in the format 
>as specified by the SCMP-message-type. This payload forms the content 
....^^^^^^^^^ "allowed"?

>of the SMIME message as described in [SMIME]. 


>5. Certificates 
>
>Every trading partner implementing SCMP MUST exchange certificates that 
>have been issued and signed by one or more mutually trusted certificate 
>authorities. Prior to establishing trading partner relationships, the 
>sender and receiver MUST acquire mutually acceptable public root  
>certificates from the agreed upon certificate authority or authorities.

I think the issue of establishing a trading partner relationship is service
dependent.  Also, the nature of CA used.

>Trading partners, upon receiving or exchanging public key certificates 
>for the first time, SHOULD validate the certificate and certificate 
>chain before processing an SCMP request.
>
>Prior to performing any application functions on a SCMP request
>payload, the receiving agent's server MUST verify that the request has 
>been made by an authorized sender and that the sender's certificate has 
>not been revoked.

I think these requirements should be service dependent.


>6. Transport Implementations
>
>SCMP can be implemented using any variety of transport methods as agreed 
>between trading partners. Here are a few examples.

I suggest "as agreed between trading partners" would more usefully be
"defined by the service provided".

[...]
>7. Receiving Server Functions
>
>This section describes minimal server functions required to implement 
>SCMP.
>
>7.1. General
>
[...]
>7.1.1. Message Timestamp
>
>The time a request was sent SHOULD be derived from the standard SMIME 
>date header. Clients and servers SHOULD be synchronized using [NTP] 
>or Secure NTP. 

"standard SMIME date header"?  Can you please provide a detailed reference,
including section number?

>The sender of an SCMP message MUST place the time a message was 
>dispatched into the SMIME header in [MIME] format. 

"SMIME header in [MIME] format"?  Again, detailed reference please.

[...]
>7.1.2 Support for Request Non-Repudiation
>
>Support for non-repudiation SHOULD be included in any complete SCMP
>implementation, as described in the following subsections. If the
>message is of signed or signed/enveloped type, the receiving 
>agent's server MUST implement support for non-repudiation. 
>
>7.1.2.1 Establish Trusted Trading Relationship
>
>Prior to exchanging messages, sending and receiving agents MUST 
>exchange public key certificates. 

I don't see this is always needed.  Certificates can be included with a
message signature, and the recipient may be able to verify the certificate
at the time of receipt.  I think this is another service-dependent matter.

>7.1.2.2 Client Private Key Storage
>
>The sending agent, maintaining a SCMP client application, MUST 
>maintain the private key in a secure location. Should a sending
>agent loose control of their private key, they MUST notify 
>the receiving agent at the earliest possible time.

How is such notification to be achieved?

>7.1.2.3 Client Message Signing
>
>The client application signs SCMP messages using their private 
>key as described in [SMIME]. 

I think the specific security protocol used whould be service-dependent.

[...]
>7.1.2.5 Server Accounting
>
>The receiving agent's server application MUST store the original signed/
>encrypted message in an unprocessed state along with the timestamp for
>identifying when the message was received. As the server processes the
>sending agent's message, a record describing the processing steps along
>with the appropriate timestamp MUST be appended to a accounting log 
>for the sending agent's request.

I think this is useful advice, but not a normative element of the protocol.


>7.1.2.6 Revokation
>
>All messages signed by a sending agent's client application in accordance
>with [SMIME] and sent to a receiving agent's server SHALL be considered
>non-repudiable. Repudiation occurs when the sending agent notifies 
>the receiving agent that the sending agent's public key certificate is
>revoked. The timestamp of this revokation event MUST be the current time
>at the receiving agent's server. Should a receiving agent's server 
>receive a request after being notified that the public key certificate 
>used to evaluate the sending agent's digital signature has been revoked, 
>this request MUST be considered invalid. 

I think this wording is muddled -- you start by saying X cannot be
repudiated, then go on to state the conditions when X can be repudiated.

>7.2. Application issues
>
>The server MUST evaluate the signature of the message, if the message 
>is of signed or signed/enveloped type, prior to processing the message 
>payload. Within this process the server SHOULD obtain the senders 
>certificate via the distinguished name in the certificate as described 
>in [SMIME].

This last sentence doesn't make much sense.

>... In performing this authentication process, the server MUST
>validate the senders certificate and verify that the sender's
>certificate is not listed in any available revocation systems. 

Again, useful advice, but I don't think it should be normative (given that
there is not indication of how to contact "available revocation systems").

[...]
>7.2.1. Request Serialization
>
>A server MAY NOT guarantee serialized request processing. If 
>requests must be serialized, it is expected that all of the 
>serialized transactions will be received in a single message 
>payload or that other content specific serialization systems will be 
>used.

I think that this is really a service dependent issue.  It is probably
appropriate to include some advice about the problems of trying to
guarantee request serialization.


>7.2.2. Server Errors
>
>A server may encounter several classes of error conditions. The 
>server MUST be capable of reporting an error as described in section 8 
>of this document. Error Detection may vary based on specific 
>implementation.

... and service.

>A server MUST be capable of detecting a duplicate scmp-request-id 
>and reply to the sending client application with the reply of the 
>original request. Duplicate request detection MUST be based on the 
>scmp-request-id and the distinguished name of the signer to prevent 
>denial of service attacks. 

This is a can of worms, I think.  To implement this as stated requires that
a server maintain information about every request that it has ever serviced.

Ultimately, I think the importance, and associated cost/benefit trade-off
for this capability is service-dependent.  I see that this is sometimes an
important issue, and I think some more discussion about (or reference to)
implementation options might be in order.

[...]
>8.1. Format
>
>SCMP error messages are returned by a server as signed data. SCMP errors 
>MUST NOT be encrypted to permit clients to process encryption related 
>errors.
>
>The format of SCMP errors is:
>
>     SCMP <error number> <error message text>

Internationalization issues?

What are the SCMP error code values?  Since application errors are
specifically excluded, it should be possible to enumerate (or register) the
possible SCMP error codes so that language-neutral imp-lementations can be
constructed.

(Personally, I would like to see the RFC1893 status code format extended
and used.)


>8.2. Client Application Error Handling
>
>Client action in the case of error return is error specific and not 
>defined. If the server fails to return any reply within twice the 
>time to live requested (due to unspecified server or network 
>failure) the client SHOULD re-send the request. Upon receipt of a
>duplicate request the server will respond as described in 7.2.2. 
>Clients MUST NOT retry a request in an interval which is less than 
>the time to live value of the original request.

Twice TTL seems rather arbitrary.  Twice TTL + some allowance for message
transit time might be reasonable.  And in the absence of a specified TTL I
think there should probably be a service-dependent timeout.



That's my lot!  I hope you find this constructive.

#g

------------
Graham Klyne
([e-mail])