RE: [dss] "Required" Designation on SignatureObject within VerifyRequest

[Trevor Perrin <trevp@trevp.net>]

Ed,

I think we're making progress - or at least we've narrowed the issue.  I 
agree that the current core spec doesn't provide a full-fledged solution 
for CMS.  However I think the core does enough so that a CMS profile can 
easily fill in the details.

In particular, note that <dss:SignatureObject> is extensible, so it's 
possible for a profile to add a <CMSSignaturePtr> if it wants, which could 
indicate which of the input documents contains the CMS Signature.  For 
indicating the particular SignerInfo *within* the signature, it might be 
better to use Optional Inputs, since a CMS signature can also be delivered 
through <SignatureObject/Base64Signature>.

More work is needed - but I think profiles have the tools they need to 
achieve CMS support.

Other comments inline -

At 12:42 PM 4/18/2004 -0400, Edward Shallow wrote:

> >  Should a legacy caller present
> >one of these to a DSS implementation (this is in scope), how do recommend
> >the Verify call be constructed ?
>
>Good question.  To answer it, I think we need to anchor this discussion in
>some real-world use cases.
>
><ed>
>No, you can't take us all the way to requirements here. You have a solution
>approach under the current spec for XMLDSIG involving multiple calls and use
>of SignaturePtr to address the solution. This already implies you
>acknowledge the need to support this scenario. Or more succinctly put, "it
>is supportable". Putting aside my request for a moment, the current spec
>simply cannot handle a CMS co-signature (or countersignature). The spec
>falls short and needs to be fixed.
></ed>

It falls short, but I would argue it doesn't need fixing - it needs 
extending.  And that's a job for a profile.


> >  Granted XMLDSIG is infintely richer and
> >will over time displace CMS, however this TC is committed to supporting
> >both. We tend to forget about it from time to time (although the XAdES
> >profile has stepped up to it, and so will the EPM). Why does section 4.3
> >Basic Processing (Verify Protocol) not have both an XMLDSIG "and" a CMS
> >sub-section write up ?
>
>As I recall, at the F2F we decided to focus on XML-DSIG for the core, with
>CMS as a profile, to keep the core workload manageable.
>
><ed>
>Disagree completely. Basic CMS support is all over the spec. You had better
>check the list back last April.
></ed>

Here's the minutes from the F2F.  It says "We will focus on XML-DSIG 
signatures", and lists "CMS & S/MIME" as a profile, though it also says 
"Deployed signature solutions such as CMS are also important", so I guess 
there's ammo for both sides:
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/3124/dss_minutes_24-25July03.txt

As I recall, some people didn't want to support CMS at all, but we swayed 
them by saying that CMS was mostly either analogous to XML-DSIG or a 
subset, so we wouldn't have to do much special work on it.


>I might even have volunteered to work on this profile, though I'll gladly
>hand it off to you (or anyone else).
>
><ed>
>Now we are getting somewhere. If the common vote is to entirely relegate
>CMS-handling to profiles (which would be revising history in my opinion),
>the TC has to do 2 things at a minimum. 1) Generalized the very specific and
>evident support for CMS that is already in the spec (which is a reversal in
>my mind and should not be pursued) and 2) allow the flexibility in the core
>to perform this CMS-handling. This second requirement is exactly where this
>entire debate started when I asked you to simply relax the [Required] on the
>SignatureObject.
></ed>

Wrt (2), I think we already have this flexibility.  You need to indicate 
the signature some way, so <SignatureObject> is required, but you can pass 
a detached signature via <Base64Signature>, or extend <SignatureObject> 
with something analogous to <SignaturePtr>.


Trevor