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

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

Inter-mixed. 

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

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.

<ed>
Yes, I believe your definition succintly paraphrases RFC3369 below.
... 
The countersignature attribute type specifies one or more signatures
on the contents octets of the DER encoding of the signatureValue
field of a SignerInfo value in signed-data.  Thus, the
countersignature attribute type countersigns (signs in serial)
another signature.

The countersignature attribute MUST be an unsigned attribute; it MUST
NOT be a signed attribute, an authenticated attribute, an
unauthenticated attribute, or an unprotected attribute.
...
</ed>

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

<ed>
Yes.
</ed>

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.

<ed
OK
</ed>


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

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

<ed>
Correct
</ed>

  - this is perhaps slightly inefficient, and is perhaps slightly a burden 
on clients

<ed>
Yes, this is my contention, but not relevant to the current thread
questioning the spec's ability to support CMS at all.
</ed>

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

<ed>
Yes, this is the "better way of doing it debate".
</ed>

  - this is a significant change to make late in the game

<ed>
Late in the game, yes. Significant, depends.
</ed>

  - I haven't seen convincing arguments that this feature is important 
enough to justify these changes. 

<ed>
I'll come back to this later, but basically my position is "you are
preventing profiles from pursuing it".
</ed>

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.

<ed>
My latest concern is that you cannot support CMS at all, one call, two
calls, regardless.
</ed>


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

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>


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

<ed>
You call it a change, I call it an oversight. The present spec does not
address our own stated requirement.
</ed>

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

<ed>
Fine. How do you point into specific CMS signatures in the spec (equivalent
of the Xpath element of SignaturePtr) ? I don't care for the moment whether
it is 2 calls or 1.
</ed>


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

<ed>
Fine. How do you support CMS even in the 2 call scenario ?
</ed>


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

<ed>
Prejudices CMS and is counter to the original directions of the TC.
</ed>


  Or we could have 
an equivalent to a <SignaturePtr> to say which co-signature and/or 
counter-signature to verify.

<ed>
Finally !!!! or you could take the simpler path of relaxing the core and
relegating specific handling of multi-sigs in both XMLDSIG and CMS to the
profiles.
</ed>

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

<ed>
Same use cases as would exist for XMLDSIG. I said I wouldn't go there but
one only has to look at the real world for countless examples of paper
documents signed by multiple parties. The number of use-cases should someone
decide to compile them are as numerous as their simpler cousins.
Additionally, and more behind my motive, existing desktop technologies
already handle signing documents more than once. It is these same desktop
technologies that DSS implementors will be obliged to support to stay
relevant.  
</ed>


>  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 

<ed>
Not all of them. Personally I could get away with simply changing
ProcessingDetails as a desired 1st choice, or simply reporting on the 1st
error encountered as a 2nd choice. In either case, SignaturePtr HAS TO
CHANGE.
</ed>


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.

<ed>
You have no choice. You must fix the CMS anomaly.
</ed>

Ed


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
.