ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: initial draft of CPP/CPA Specification


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?

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;-)

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.

Agreed. This is TBD.

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?

It can, yes. I think that we may need to think about this more

8.8.3 Nonrepudiation

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

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

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.

The cert would be the signing cert, yes.

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

Good point.

                               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
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
title:Sr. Staff Engineer
fn:Christopher Ferris

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC