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

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

Trevor,

   Agreed. I buy that. Given the fact that CMS was officially removed from
the Requirements document back in August, I can't legitimately argue for too
much additional support in the core. Unfortunate, this one slipped by me. I
also buy your CMS suggestions below and will need some help in crafting it
into the profile.

   Back to the original discussion ... On the XMLDSIG support for multiple
signatures in a single InputDocument, are you and the team willing to do
some relaxing/tweaking in the following areas ? 

- the [Required] on the XPath sub-element, change to [Optional] with
non-normative comments pointing at the profiles

- some unboundedness on the ProcessingDetails optional output

   The rest of the options I can simply constrain in the profile to achieve
the desired co-sign and counter-sign objective for both CMS and XMLDSIG in
the EPM profile (and others that want to pursue this). The remainder of the
options would still naturally be available to callers when only one
signature is in play or when they are willing to point to the target
signature.

Ed



-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 18, 2004 3:41 PM
To: ed.shallow@rogers.com
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] "Required" Designation on SignatureObject within
VerifyRequest


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_minut
es_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 


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
.