RE: [dss] CMS

["jmessing" <jmessing@law-on-line.com>]

My concern in this thread is a hint of tinkering with profiles as a way of deciding whether specific matters should be dealt with by the core or not.

I think we should consider carefully as a group beforehand the possible impacts on the duration and complexity of interoperability testing of a minimalist core, in light of OASIS requirements for adopted standards.

---------- Original Message ----------------------------------
From: Trevor Perrin <trevp@trevp.net>
Date:  Wed, 21 Apr 2004 04:28:05 -0700

>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 
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>
>