RE: [dss] CMS

[Trevor Perrin <trevp@trevp.net>]

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