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 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
 
 
 
 








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

Powered by eList eXpress LLC