Subject: RE: Delayed turnaround remark: nonrepudiation's cryptographicparameters inCPP vs CPA
I agree with that, sorry if I was not clear in my mail. I simply wanted to say that we should collect all of these information but avoid to specify how a tool would have to use them /Stefano » -----Original Message----- » From: Martin W Sachs [mailto:mwsachs@us.ibm.com] » Sent: 17 January 2001 22:22 » To: Stefano POGLIANI » Cc: Moberg, Dale; ebxml-tp@lists.ebxml.org; » ebxml-ta-security@lists.ebxml.org » Subject: RE: Delayed turnaround remark: nonrepudiation's cryptographic » parameters inCPP 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