Re: Delayed turnaround remark: nonrepudiation's cryptographic parameters in CPP vs CPA

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

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