draft-arnold-scmp-03.txt

>            Simple Commerce Messaging Protocol (SCMP)
>                  Version 1 Message Specification
>                    (draft-arnold-scmp-03.txt)

I have some comments on this draft.

Based on discussion on this list, I believe this is intended to document
current SCMP implementations for informational purposes (rather than to
describe a version 2 standards-track candidate).  If so, I think a
clarification to this effect in the introduction would be helpful.

In view of this, I have limited my comments here to aspects of this
document that might bear some clarification, rather than suggestions for
refinements in a version 2 protocol.

I think that a section or appendix giving a formal syntax for a complete
SCMP request and response would be helpful.  (I also suggest citing RFC
2234 rather than RFC 822 for ABNF syntax elements.)


>1. Introduction

(Insert description of status of this SCMP version?  See my comment above.)

>The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 

[...]
>1.1.10 Service Level Guarantee

I'm not sure that "Service Level Guarantee" is the right heading here:  I'd
suggest "Response Time Guarantee".

>The receiving agent should guarantee a response within the time 
>designated by the sender, or reject the message with an appropriate 
>error message.
>
>1.1.11 State Independence
>
>State dependency by either a sender's or receiver's application should 
>be minimalized as to support multiple transport mechanisms.

I think this might need to be slightly expanded;  as it stands it doesn't
make too much sense to me.  I think you are trying to say something like
either or both of:

# The protocol must not depend on state information maintained by the message
# transfer mechanism, to minimize constraints on the mechanisms that can be
used.

# The need for sender of receiver to maintain state information should be
# kept to a minimum, thus allowing the protocol to scale reasonably well.

Also, I think the term "transport" as used here is not universally
accepted.  I have seen it claimed that HTTP (and SMTP) are more than just
message transports.

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

This (i.e. MUST implement signed/enveloped, SHOULD implement signed) seems
to contradict the requirements at 1.1.2 ("privacy ... should be assured")
and 1.1.4 ("SCMP requests and SCMP replies MUST be authenticated").

Also, I note that the later requirement to not encrypt error responses
implies "MUST implement signed" (rather than just SHOULD).

>For non-repudiation concerns, the trading partners MUST exchange 
>signed or signed/enveloped SCMP message types.
>
>SCMP error messages MUST be of signed type and NOT encrypted.

[...]
>2.1 SCMP Protocol Version
>
>The SCMP-protocol-version header is used to designate the SCMP protocol 
>version. Server implementations MAY reject the request based upon 
>protocol version, before any message processing occurs.
>
>An example SCMP-protocol-version header will be in this format:
>
>  SCMP-protocol-version: 2.0

Since this document describes version 1 of the SCMP protocol, this example
seems a little perverse.

I would suggest wording like:

# An SCMP-protocol-version header has the following general format
# (using ABNF per RFC 2234).
#
#   "SCMP-protocol-version" ":" 1*DIGIT "." 1*DIGIT
#
# A message conforming to this specification must contain the following
# SCMP-protocol-version header:
#
#   SCMP-protocol-version: 1.0


>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: SomeCompany
>
>The sender name MUST be the subject's common name of the x.509 
>certificate that belongs to the signer of the SCMP message. As 
>specified by [X.520].

Is the subject's X.520 common name really enough for this purpose?  As I
understand it, there is no requirement for the common name alone to be
unique.  I would have thought the X.509 'subject' distinguished name, or
'subjectAltName', would be more appropriate (I'm using RFC 2459 as a source
here).

[...]
>3.3. Request ID
> 
>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. 
>
>The format of value of the request id header is 22 digits, where 
>digits is defined by [RFC822].
>
>An example of a request scmp-request-id is:
>
>	scmp-request-id: 0917293049096167904518
>
>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. 

How is the client identified for the purpose of this uniqueness requirement?

[I notice that, later in the document (7.2.2), the DN of the signer is
indicated for this purpose.  I think some mention of the fact at this point
would be helpful.]

>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.
>
>Servers MAY use a scmp-request-id as a reference and handle to the 
>original request during server message processing. 

Surely, the request ID plus client identification must be used:  two
different clients may legitimately generate the same request identifier.

>Servers MUST return the submitted request id back to the client via 
>the SCMP reply message in the SCMP-request-id header.

>7.2.1. Request Serialization
>
>A server SHOULD NOT guarantee serialized request processing.

I think this should read "A server is not required to guarantee..." or
"A client SHOULD NOT expect serialized request processing by a server".

[...]
>9.3.2 Certificate Authentication and Revocation
>
>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.
>
>A server certificate revalidation policy, related to the frequency 
>certificates are revalidated against a certificate authority's 
>certificate revocation list, is not specified by SCMP. This matter is 
>left as a policy decision for the operator of the SCMP server.
>
>The timestamp of a certificate revocation event SHOULD be the time the
>private key was known to be comprimised, or the time that the revocation
>event was made.

Which of these times should be used?  Either?  The earlier?  Or the later?

(Also: typo in "compromised" here)


>10. SCMP Message Example
>
>[ OUTER MIME START ]
>Content-Type: application/pkcs7-mime
>Content-Transfer-Encoding: base64
>Content-Length: 1024
>SCMP-protocol-version: 2.0
........................^^^  Isn't this version 1.0?


[...]
>[RFC822]           D. Crocker, "Standard for the format of arpa internet
>                   text messages", RFC 822, IETF, August 1982.
>
>[X.520]            "ITU-T Recommendation X.520: Information Technlogy -
>                   Open Systems Interconnection - The Directory: Selected
>                   Attributes Typs, 1993.

Suggest maybe also citing:  RFC 2234 (ABNF),  RFC 2256 (directory
attributes).  Possibly RFC 2249: PKIX X.509 certificate profile.


#g

------------
Graham Klyne
([email protected])