RE: initial draft of CPP-CPA Specification

[Martin W Sachs <mwsachs@us.ibm.com>]

Richard,

Thank you for your set of comments.  Here are some preliminary replies,
embedded in this copy of your comments:

Regards,
Marty


8.6 Delivery Channels

How are the Characteristics validated against the Transport and Document
Exchange specifications?  Are they validated?  For example, if
nonrepudiationOfReceipt is required, how can I know it is provided by the
lower layers?

MWS:  I suspect that validating the choices in the transport and document
exchange sections of an individual CPP or CPA against the referenced
specifications is well outside our scope.  I can imagine some vendor
building a CPP/CPA creation tool that contains built-in knowledge of the
specifications to which our specification makes normative references. We
could provide some non-normative suggestions as to how a CPA installation
tool should proceed if it recognizes invalid choices.  However recognizing
invalid choices in many cases would require that the installation tool also
have knowledge of all the normative references, which is not something this
team should assume.  If anyone wants to provides some words for this
situation, please do so.

8.7 Transport

The issue of sending vs. receiving specifications was discussed in a call
two weeks ago.  I guess we are putting this off to the next version.  If
the goal is to be able to merge two CPPs to create a CPA, then we will need
sending specifications, including some detail.  The interpretation of other
specifications might vary for sending and receiving.  For example, timeouts
for a sender might indicate required maximum times, while the timeout on a
receiver might be a minimum capability.

MWS:  Send specifications is definitely on our must-do list.

8.7.6 Transport Security

How are encryption/authentication specified?  The elements specify a
protocol and a certificate?  Does the protocol (SSL, for example) imply
encryption/authentication?

MWS:  This and the following points are definitely open questions.  We will
need more advice from the Security team on these points.

8.8.3 Nonrepudiation

What is the meaning of EncryptionAlgorithm in this section?  Isn't the
SignatureAlgorithm sufficient?

Is the certificate the signing certificate?  Is it necessary to specify
this in a CPA? The signing certificate and its validating certificates can
be sent in a S/MIME message.  Perhaps only the root need be specified.

8.8.4 Digital Envelope

More should be specified about the Encryption algorithm.  The symmetric
algorithm (RC2, DES, etc.), the asymmetric algorithm (just RSA? D-H?), and
their respective key lengths must be specified.  Both parties must be able
to handle the algorithms and lengths.  Public key lengths are specified in
the certificates.



*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Richard Bigelow <rbigelow@ipnetsolutions.com> on 01/16/2001 07:37:39 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-tp@lists.ebxml.org,
      ebxml-ta-security@lists.ebxml.org
cc:
Subject:  RE: initial draft of CPP-CPA Specification



Marty,

My comments follow, a bit late.  I hope they are useful.

Regards,
Richard