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

[Trevor Perrin <trevp@trevp.net>]

At 01:28 PM 4/17/2004 -0400, Edward Shallow wrote:
>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).

To make sure I understand:

A CMS counter-signature is a SignerInfo added as an unsigned attribute to a 
parent SignerInfo, covering that parent's signature value.

A CMS co-signature means the presence of multiple SignerInfo structures 
within a SignedData.

So in the general case, a CMS signature consists of a set of co-signatures, 
each of which may have a chain of counter-signatures.


>  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.

What are the use cases for CMS counter-signatures and co-signatures?  Are 
they currently being used?  If so, for what, and how does current software 
deal with them?

Basically, the way I see this is:
  - the current verify protocol verifies a single signature
  - when faced with a document containing multiple signatures, the client 
would have to verify them one at a time
  - this is perhaps slightly inefficient, and is perhaps slightly a burden 
on clients
  - we could change the protocol to verify a document containing multiple 
signatures in a single call, and return differentiated output codes and 
options per each signature.
  - this is a significant change to make late in the game
  - I haven't seen convincing arguments that this feature is important 
enough to justify these changes.  True, an XML document or CMS message 
could theoretically have multiple signatues; but that doesn't mean it 
commonly happens, and even if it does, that doesn't mean we need special 
protocol support for it.


>  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.

I might even have volunteered to work on this profile, though I'll gladly 
hand it off to you (or anyone else).


>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.

well, it's a significant change.  The result codes, optional inputs, and 
<SignatureObject>, were designed under the assumption that only a single 
signature is in context at a time.


>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.

Why is that ugly?  It supports the use-case without changing the 
protocol.  It looks pretty attractive to me.


>  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.

The CMS "anomaly" could be fixed in ways beside what you suggest.  We could 
simply disallow co-signatures and/or counter-signatures.  Or we could have 
an equivalent to a <SignaturePtr> to say which co-signature and/or 
counter-signature to verify.

Whether these are good approaches I don't know, because I don't know what 
use cases or requirements we're trying to meet.


>  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 ?

It could.  But it requires changing all the options at the last minute to 
support an unusual case which we already support (though in a way you call 
'ugly').

I'm not saying this is impossible.  I'm just not convinced it's worth doing.


Trevor