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.
Cheers,
Chris
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
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
Powered by
eList eXpress LLC