Subject: RE: Delayed turnaround remark: nonrepudiation's cryptographicparameters in CPP vs CPA
Stefano.
The process of composing the CPA from two CPPs is definitely out of scope
for the TP team. However the TP requirements specification does state
(requirement number Spec 8): " Define how a CPA may be composed from two
CPPs. This refers to the nature of the composition rather than the process
of arriving at the composition". In my opinion, this requirement means
that we must keep composition in mind and define the contents of the CPP to
permit composition, to the best of our ability.
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
*************************************************************************************
Stefano POGLIANI <stefano.pogliani@sun.com> on 01/17/2001 03:07:51 PM
To: Martin W Sachs/Watson/IBM@IBMUS, "Moberg, Dale"
<Dale_Moberg@stercomm.com>
cc: ebxml-tp@lists.ebxml.org, ebxml-ta-security@lists.ebxml.org
Subject: RE: Delayed turnaround remark: nonrepudiation's cryptographic
parameters in CPP vs CPA
A little comment on Dale's mail.
If I understood correctly, the main issue raised by Dale is about the
"composition of 2 CPPs to form a CPA". Apologies if I am not catching the
point, but I think that the "composition rules" are outside of the scope of
the TPA specs.
With that I do not want at all to say that the issue is not important. On
the contrary! Simply I am saying that this is the candidate either for some
non-normative text or to "get back into scope".
Specifically, I was thinking that the intersection of two CPPs to form a
CPA
may not be a "strict, mathematical" intersection; the software that will
perform this may flag situations like the one highlighted by Dale and ask
confirmation to the user.
Of course, the more of these situations that are known in advance, the
better the specs will serve the vendors by providing a wide range of
situations where all the tools will behave the same.
/Stefano
» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: 17 January 2001 18:24
» To: Moberg, Dale
» Cc: ebxml-tp@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
» Subject: Re: Delayed turnaround remark: nonrepudiation's cryptographic
» parameters in CPP vs CPA
»
»
»
» 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
»
»
»
»
Powered by
eList eXpress LLC