RE: [dss] CMS

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

Trevor,

    Yes I think you have summed up the positions well.

  - what are the semantics if the SignatureObject is omitted ? That the
input document *is* a signature?
<ed>
Yes. Enveloped or enveloping. Or you could introduce the
DocumentWithSignature element presently used on output within the spec. More
semnatically correct, and allow the caller to initialize as appropriate
under policy and/or profile guidance.  
</ed>

  That it must contain a signature ?

<ed>
If you are calling a Verify, and the SignatureObject is omitted, yes.   
</ed>

  That all the signatures contained therein will be verified?

<ed>
Under profile control. Don't see any problem here. The EPM profile will
state all signatures will be verified, as yes we'll find them.
</ed>  

Or only one the first one?

<ed>
If one wants. Then you are back to what we have, and I'd use SignaturePtr as
spelled out. More value in doing them all though.
</ed>

  Or whichever one(s) the server feels like?

<ed>
Yes, if your server is running a sweepstakes with prizes. 
</ed>


  (and what if there's multiple input documents)?

<ed>
I never said eliminate SignaturePtr. WhichDocument has its purpose. We're
into exceptions and the spec as is, is optimized for these exceptions, which
is my concern. 
</ed>


Probably you're going to say it's profile-specific.
<ed>
Yes. Default handling spelled out in the core. The way you are advocating,
it will be less value more work. The way I am suggesting, because you won't
allow me to do it in the core, is more value with less client work.
</ed>

The minutes will probably reflect another viewpoint. There was a lot of
talking going on. 

Nick and Juan Carlos and Frederick what did you hear ?

Ed




-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 20, 2004 3:12 AM
To: ed.shallow@rogers.com; dss@lists.oasis-open.org
Subject: RE: [dss] CMS

At 10:56 PM 4/19/2004 -0400, Edward Shallow wrote:
>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.

If I understand your last sentence: Yes!  My approach makes CMS support look
like a "copy" of DSIG support.  That's a good thing, because it makes CMS
fit nicely with our protocol.

With your approach CMS look very different from DSIG, which is why you're
trying to change the protocol to re-interpret or optionalize InputDocuments
and SignatureObjects.


>Besides, you have just scratched the surface of FULL CMS support.

How so?  My approach can verify any type of CMS signature.


>It just exacerbates the complexity on the CMS client side

True.  But...


>  which I thought was unnecessary for single signature XMLDSIG documents. 
> It would be
>especially painful for run-of-the-mill CMS enveloping signatures.

I don't think extracting a SignerInfo from a SignedData is that hard,
considering the benefits.

The IAIK S/MIME toolkit, for example, makes this easy.  Also, I've written
code to extract public-keys from certificates, which is similar in that you
just walk through the ASN.1 till you get to a certain point, and return the
bytes.  It took a couple hours and ~50 lines, not knowing ASN.1 at the
beginning.  Which pales in comparison to the time we'll have spent
discussing this :-)...


>What I suggested, and thought I heard consensus on, was the simple 
>introduction of either/or optionality of InputDocuments and 
>SignatureObjects for the Verify.

I didn't think there was consensus on this.


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

Well, we'll wait for the minutes.  I distinctly remember *not* agreeing to
this, and wanting more time to think it over.

I haven't spent much time on it, but I have some concerns:
  - how would you do client-side hashing with enveloping CMS signatures?
  - which CMS SignerInfos does the server verify?  All?  The first?  The one
indicated by the client?
  - what are the semantics if the SignatureObject is omitted?  That the
input document *is* a signature?  That it must contain a signature?  That
all the signatures contained therein will be verified?  Or only one the
first one?  Or whichever one(s) the server feels like?  (and what if there's
multiple input documents)?

Probably you're going to say it's profile-specific.  I don't like giving
profiles the power to completely define semantics as to what a bunch of
input documents mean.  We've talked about clients getting support from a
server without even knowing it's specific profile, and of a single
implementation of the core being re-used for lots of profiles.  These things
are only possible if the core lays out syntax and semantics which every
profile follows.  You're trying to throw those constraints off, so every
profile can do its own thing in the name of flexibility.  But those aren't
profiles then, they're just separate protocols with a vague resemblance and
a bit of element re-use....


>All other advanced CMS forms including CMS multi-signing, 
>counter-signing, detached signatures,

All these would be handled identically, in my approach.  The differences
between them disappear at the level of the SignerInfo.


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

No change of heart, I'd rather leave the core as-is and relegate CMS 
support to a profile.  However I thought the consensus was to put it 
in.  Maybe I'm wrong, and the consensus was just to beef it up a little, as 
you say.  I'll look at the minutes.


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
.