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: Delayed turnaround remark: nonrepudiation's cryptographicparameters in CPP vs CPA

I fully concur with Marty's observations as well as agree
with Dale's assertion that we need the ability to
allow for multiple combinations of capabilities.



Martin W Sachs wrote:
> Dale,
> I fully agree with the point of your appended comments.  I do believe that
> the draft CPP spec does allow for advertising multiple capabilities in the
> areas you mention and others.  Advertising multiple capabilities for the
> same function is done by including as many delivery channel definitions as
> needed to display all the combinations of capabilities.  This might not be
> the most efficient way to do so and one could start thinking about element
> structures or attributes that convey the variability within a single
> delivery channel.  For cases where a value of an attribute or element can
> have any value out of a large set (e.g. timeout), one might simply state in
> the specification that the values of such attributes or elements are
> negotiable or we could define a specific value to mean "negotiable" or come
> up with an attribute that says "negotiable" (ignore stated value).
> Actually the tpaML heritage is more variable than it looks since it was
> understood (and, I think stated in one or two places), that the actual
> choice of many functions is up to the two parties and not mandated in the
> specification.  However at that point, our IBM team had not put much effort
> into the question of negotiation from profiles and so we did not think
> about how to indicate what values are negotiable on a continuum and what
> are restricted to a small set of choices.
> Plenty of room (and unfortunately little time) for invention.
> Regards,
> Marty
> *************************************************************************************
> 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
> *************************************************************************************
> "Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/17/2001 10:24:24 AM
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   ebxml-tp@lists.ebxml.org, ebxml-ta-security@lists.ebxml.org
> Subject:  Delayed  turnaround remark:  nonrepudiation's cryptographic param
>       eters in CPP vs CPA
> Hi Marty,
> Since you have taken care of some of the
> issues I mentioned in the doc,
> and we have to wait on others for us to
> finish the full story on many other issues,
> I wanted to add another issue to make
> sure we have enough to discuss!!
> Section 8.8.3 is on nonrepudiation
> and has in it details about
> hash algorithm, signature algorithm
> and so on. I wanted to use
> this example to illustrate some
> problems I have in switching
> between the CPP point of view
> and the CPA point of view.
> We have agreed to think of CPPs as advertised
> capabilities for conducting BPs and
> perhaps including a few other things.
> We are interested in capabililities because
> a match in capabilities indicates some
> level (transport at least) of
> interoperability between collaborators.
> However, when we derived CPPs from CPAs
> we did not always notice that sometimes
> the CPA information represented a specific
> choice out of a larger set of
> capabilities. So for nonrepudiation,
> a CPA (from its tpaML heritage) reflects
> the specific choice of a hash and a
> signature etc. But for CPP purposes, though
> we might wish to advertize just one way of doing it,
> that could restrict matches,
> and thereby restrict who I could collaborate with.
> In other words, I might be able to do DSA or RSA
> and at any key strength and
> I could do either SHA1 or MD5 for the hash.
> If in the CPP I wrote down my
> preference for SHA1 and RSA at 2048 bits,
> I might very well end up preventing
> a match, and not engaging in mutually
> advantageous b2b collaboration.
> What we way need for some of this
> kind of info is a way to enumerate all supported
> options, a way to indicate preferences
> among these, for use in the CPP.
> A related CPP vs CPA issue is where, instead of
> advertising a capability, it is more informative
> to call attention to a specific limitation, presuming
> that everything in that functional area can
> be done except this. For example, in a PKI context,
> one might note that SMIME software needs to have
> the full certificate chain included with the signature
> inside the PKCS7 or CMS structure. More flexible
> software might be able to deal with the message
> either way. (So far I am holding off modeling
> to this level of detail in the packaging area;
> we will see whether it is needed as we proceed.)
> At any rate, I think there are several
> places where we need to be aware of shifts in the
> CPP and the CPA point of view and perhaps note
> the contrast in the text, despite using the same
> element tags.
> Dale Moberg

                               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