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

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

All,

    Many legacy products (CMS-based ones including our own) already support
both counter-signing (over existing PKCS7 as input) and multi or co-signing
(add an extra SignedInfo in exisitng PKCS7). Should a legacy caller present
one of these to a DSS implementation (this is in scope), how do recommend
the Verify call be constructed ? 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 ? 

    I am bringing this up because it factors in our discussion. We have
Verify inconsistencies that must be resolved. The fundamental need to just
"Verify this PKCS7" or "Verify this DocumentWithSignature" even if it
contains 2 signatures is a simple request. If we decide to satisfy it, it
need not turn the protocol upside down. You can't however ignore it. At
least in the DSIG world, we have the ugly option of calling twice and
specifying different SignaturePtrs on each call. We do not (realistically
speaking) have this option in the CMS/PKCS7 world. Fix the CMS/PKCS7 anomaly
and you'll fix the XMLDSIG one. We are committed to doing this in the EPM
profile for value-based reasons, even if it amounts to returning error
results on only the first failing signature, and constrain inappropriate or
incapable options. The real question is why must these options be incapable
? We already have notional support for returning multiple things each
associated with a WhichReference in the TransformedDocument option section
4.5.8. Why cannot this rationale be applied to the multiplicity challenge on
the other options ?

    If a) below means ... call DSS for a signature, then call it again for a
counter-signature, we already have it "OR" call DSS for a signature, then
call DSS with a Verify on the 1st and apply a 2nd counter signature over it
.... that is not what we are debating and something entirely new. b) below
is not a solution on its own, but simply an API tweak

c) below is what I am suggesting that the TC consider to be within a
profile's scope to pursue     

Ed    

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

At 10:45 PM 4/16/2004 -0400, Edward Shallow wrote:
>You are missing the point. Are you saying that profiles are 
>categorically restricted from pursuing scenario-specific support of 
>multiple signature verification ?

Not necessarily.  We support time-stamped signatures for example, which are
similar to counter-signed signatures.

As long as there's a single main signature, profiles are welcome to add
other stuff.  Support for counter-signed signatures would be a good idea for
the core or XAdES profile.

However, changing the verify protocol so it can verify multiple *main*
signatures is a big deal: you'd need to change or disallow all the core
options, define entirely new result codes, change the processing rules, and
omit the <SignatureObject>.

In my opinion, profiles shouldn't have this much flexibility.  Profiles
should constrain and extend the core, not redefine it.  So if we want this
functionality I think we should add it to core.  Loosening the core syntax
so that profiles can do whatever they want is a recipe for chaos.


Anyways, this dicussion touched on a few possible features:
  a) counter-signatures  (or other "subsidiary" signatures)
  b) ability for client to not send <SignatureObject>
  c) ability to verify multiple signatures in a single call

I think (a) would be the easiest, (c) would be the hardest.  If you would be
happy with (a) or (b) then perhaps we should focus on that.


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
.