RE: [dss] CMS

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

Trevor,

That is not quite what I heard. I had simply suggested making InputDocuments
and SignatureObject [Optional] in the Verify protocol. This is arguably a
good idea for XMLDSIG and a must for CMS. What you have below simply moves
(correction, copies) our debate from an XMLDSIG playing field to an ASN.1
playing field. Besides, you have just scratched the surface of FULL CMS
support. It just exacerbates the complexity on the CMS client side which I
thought was unnecessary for single signature XMLDSIG documents. It would be
especially painful for run-of-the-mill CMS enveloping signatures.

What I suggested, and thought I heard consensus on, was the simple
introduction of either/or optionality of InputDocuments and SignatureObjects
for the Verify. There is no need to change the Sign. Basic CMS support is
there, extended forms should be relegated to profiles, where specific
handling can be addressed by the profile author and scope can be controlled.
XAdES 101733 is a perfect example. I believe the DSS core should stay out of
this detail, the CMS suggestions below is exactly what you end up. 

If you have an enveloping PKCS7 just place the entire SignedData PKCS7
(which every tool on the planet produces) in dss:Base64Signature, no
InputDocuments required. If you have a single XMLDSIG enveloped/enveloping
signature just place it in InputDocuments, whether and when the SignaturePtr
is required or not should be relegated to policy and profiles. This was also
discussed and agreed to.

All other advanced CMS forms including CMS multi-signing, counter-signing,
detached signatures, PKCS#1 signatures, S/MIME, WAP Signed Content, ES-C
timestamps, or whatever else you want to support, should be the domain of
the profile. The profile should be responsible for the scope and degree of
pain it does or does not want to put its clients through, based on what it's
basic value proposition is.

I agreed that the DSS TC core was "... primarily focused ..." on XMLDSIG. It
presently has rudamentary support for CMS, and I simply pointed out a small
anomaly in the Verify in pursuing that rudimentary support. I think it would
be a good idea to beef up the Basic Processing sections (Sign and Verify,
text only) to at least say something about this rudimentary CMS support. I
thing everyone likes the XMLDSIG emphasis without totally ignoring CMS. I
did not hear anyone say "bring it up to par with XMLDSIG". I didn't want the
added complexity in the core any more than you did. Why the sudden change of
heart ? 

Ed

P.S. I have attached both a counter-signed and multi-signed P7 for your
perusal. Open them up with your favorite BER Viewer. Its not as simple as it
seems. Maybe for us, but not for my clients.

            

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 19, 2004 3:40 PM
To: dss@lists.oasis-open.org
Subject: [dss] CMS


The consensus on the call was that CMS support should be fully spec'd in the
core.  Here's a proposal:

To recap, a CMS SignedData contains a set of co-signatures, each of which
could be the root of a *tree* of counter-signatures (not a chain, like I
thought before).

Each of these sub-signatures is of type SignerInfo.  So far, we've assumed
the client sends a SignedData for verifying.  I think it would be better to
send a SignerInfo:
  - SignerInfo is self-contained: it contains signed & unsigned attributes,
the hash type, and signature value.  A SignerInfo should be easy to extract
from a SignedData: at best, your library will provide access to it.  At
worse, you do a bit of ASN.1 parsing.
  - This avoids the difficulty with determining which co-signature or
counter-signature to verify.  The client just encodes the desired SignerInfo
inside a <Base64Signature>.
  - This supports enveloping & detached signatures identically, and allows
for client-side-hashing (via <DocumentHash>) in either case.

On the signing side, we probably still want to return a full SignedData, so
the client doesn't have to piece one together.

Comments?


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
.

cosignedPKCS7Data.p7

multisignedPKCS7Data.p7