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



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










[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC