RE: [dss] CMS

["Nick Pope" <pope@secstan.com>]

Trevor,

What I understand was that with some change in the flexibility in verify
schema it would be possible to use this to support CMS, and that you and Ed
were tasked to produce an equivalent to 3.3 / 4.3 to cover basic CMS
processing.

My understanding is that the requirements document
 http://www.oasis-open.org/apps/org/workgroup/dss/download.php/3926/oasis-ds
s-1.0-requirements-wd-12.pdf

does include requirement to allow creation & verification of CMS signatures.

The details relating to the different forms of CMS which do not relate to
XML signatures could be sorted in a profile.  I do not think that we need to
be too rigid about the complete picture being defined in the Core.  However,
it should not be so rigid as to preclude profiles defing particular use of
CMS.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 20 April 2004 09:12
> 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_wor
kgroup.php.