RE: [dss] CMS

[Trevor Perrin <trevp@trevp.net>]

At 02:00 AM 4/21/2004 -0400, Edward Shallow wrote:
>[Trevor]:
>I had 2 previous questions about your approach to CMS:
>   a) how would you do client-side hashing with enveloping CMS signatures?
>[i.e. if an enveloping signature is included in a <Base64Signature>].
>
><ed>
>In the CMS world, there is really only detached and enveloping. Presently
>the core is not sufficiently specific on SignatureType for a Sign, although
>I suppose we can add additional URNs in section 7.1 to further specify CMS
>sub-types.

Yeah, we'll have to do something like that.


>b) which SignerInfos does the server verify?  All?  The first?  The one
>indicated by the client?
><ed>
>We would not be working with SignerInfos in the core in this scenario, so
>this is rhetorical. See below for the XMLDSIG answers.

In your proposal, the client sends a SignedData.  When a SignedData 
contains multiple SignerInfos (co-signatures or counter-signatures), what 
does the server do?

Well, there's several choices, and I presume we can choose one.  I see 
pluses and minuses to each of our approaches to CMS.  I'll try to summarize 
them in a separate email.


Anyways, moving on to the issue of allowing <SignatureObject> to be absent 
with XML-DSIG.  You suggest some default semantics (ie processing rules) 
for a missing <SignatureObject>.

I don't like the idea of profiles overriding default semantics with new 
semantics.  Also, the default semantics you suggest are fairly complicated, 
and their benefit is minor - allowing the client to omit a 
<SignatureObject> in a particular case.

However, you make a good point that I was trying to use <SignatureObject> 
sub-elements as flags or directives, which isn't appropriate.

So I would agree with making <SignatureObject> omittable, but I would 
prefer to leave the semantics undefined in the core.  This way, we don't 
complicate core processing, but profiles have the lattitude to implement 
"document-centric" verification, if they want.

Is this a good compromise, on the "optional <SignatureObject>" issue?

Trevor