Re: initial draft of CPP/CPA Specification

[christopher ferris <chris.ferris@east.sun.com>]

Cpa-cpp-spec-0.1-interim.pdf

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?

<CBF>
Good question. The answer I would give at this stage is that
they aren't validated per se. They could be given enough time
I suppose;-) My thinking was that they would be ascribed to a
DeliveryChannel by an engineer that understood the characteristics
that are provided by the delivery channel's components (the
transport and the doc exchange).

The idea was that by associating a set of characteristics to
a delivery channel that farly closely mapped to the BP's notion
of required characteristics as regards security, that the
matching of available delivery channels could be made easier.

I'm more than willing to consider alternative approaches;-)
</CBF>

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.

<CBF>
Agreed. This is TBD.
</CBF>

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?

<CBF>
It can, yes. I think that we may need to think about this more
carefully.
</CBF>

8.8.3 Nonrepudiation

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

<CBF>
Good point. EncryptionAlgorithm should not be there as it has nothing
to do with nonrepudiation.
</CBF>

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.

<CBF>
The cert would be the signing cert, yes.
</CBF>

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.

<CBF>
Good point.
</CBF>

-- 
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development 
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard