Delayed turnaround remark: nonrepudiation's cryptographic parameters in CPP vs CPA

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

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