RE: [dss] CMS

["Edward Shallow" <ed.shallow@rogers.com>]

Trevor,

    We've made some good progress. Once again, thanks for your patience and
unflappable professionalism.

I have always agreed with the semantics-to-syntax argument you make. I am
just at a loss on how to make it simple. What you are suggesting re: making
SignatureObject optional and leaving semantics for the profile works for me.
However, we would have to also make InputDocuments optional also for CMS. I
also agree that the semantics I wrote up are a mouthful, but they work.

Another option if you want to try something else is ... additional core
elements that would allow us to tighten up the semantics. A trade of
elements for semantic complexity. Maybe an optional DocumentWithSignatures
which would be initialized by XMLDSIG requesters only if multiple signatures
were involved. This could be complemented with an additional SignatureObject
sub-element something like MultiSignedCMSSignature. Or leave them as is and
just add a new optional "directive flag" that states the presence of
multiple signatures in the request. This approach still needs optionality in
most elements.

I would still leave in SignaturePtr for the reasons spelled out in the
semantic text I sent you. It is good for the "Verify this" scenario.

Ed   

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 21, 2004 6:28 AM
To: ed.shallow@rogers.com
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] CMS

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
.