RE: [dss] CMS

[Trevor Perrin <trevp@trevp.net>]

At 11:38 AM 4/20/2004 -0400, you wrote:
>Trevor,
>
>     Yes I think you have summed up the positions well.
>
>   - what are the semantics if the SignatureObject is omitted ? That the
>input document *is* a signature?

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>].
  b) which SignerInfos does the server verify?  All?  The first?  The one 
indicated by the client?



[Trevor (again)]
>   - what are the semantics if the SignatureObject is omitted ?

[...]

>Probably you're going to say it's profile-specific.
><ed>
>Yes. Default handling spelled out in the core.

Which is the default?  I listed several possible semantics and you agreed 
with all of them!


Anyways, your proposal has 2 components:
  1) Make <InputDocuments> optional, so the input data could be contained 
in an enveloping CMS signature.
  2) Make <SignatureObject> optional, so an XML signature (or signatures) 
could be contained in an input document with profile-defined or 
server-defined semantics.

As for (1), I believe this approach to CMS is inferior to the "SignerInfo" 
approach because of questions (a) and (b), above.

As for (2), this is a syntax change whose semantics are still unclear.  I 
think allowing profiles and servers to define whatever semantics they want 
for this syntax is a mistake.  It would be better for different semantics 
to have different syntaxes, to avoid confusion.

In other words: profiles should try to extend and constrain things, not 
redefine/re-interpret them.  So if you want semantics like "verify every 
signature in this document", I would suggest a new <SignatureObject> 
sub-element like <DocumentAllSignaturesPtr> or something.  We already have 
flexibility to add <SignatureObject> sub-elements, so I don't think the 
flexibility to omit <SignatureObject> gains anything.


Trevor