Subject: Re: Delayed turnaround remark: nonrepudiation's cryptographicparameters in CPP vs CPA
Thoughts adding to all of this:
- The issue of combinations of choice leads to thinking that we need to
define XML Choice structures (True/False, Multiple Choice, etc).
this would lead us to consistency for expressing choice types throughout
the CPP.
- Just because a match can be made, the business need to further agree that
they will use that match with each other.
- Dale's notes on CPP and CPA perspectives are correct. Tags can be the
same but the semantics differ where used. The original
tpaML was focused more on the CPA perspective than CPP perspective given
the tpaML text.
- I originally thought also of an attribute for "negotiable". Further, I am
thinking that the CPA should have sections, what is
still under negotiation, etc, for partitioning concerns in implementation.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
christopher ferris <chris.ferris@east.sun.com>@east.sun.com on 01/17/2001
11:59:13 AM
Sent by: Chris.Ferris@east.sun.com
To: ebxml-tp@lists.ebxml.org, ebxml-ta-security@lists.ebxml.org
cc:
Subject: Re: Delayed turnaround remark: nonrepudiation's cryptographic
parameters in CPP vs CPA
I fully concur with Marty's observations as well as agree
with Dale's assertion that we need the ability to
allow for multiple combinations of capabilities.
Cheers,
Chris
Martin W Sachs wrote:
>
> 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
--
Christopher Ferris
_/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced Development
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
Powered by
eList eXpress LLC