RE: [dss] Discussion on outstanding issues for the core.

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

Ed,

Seems generally OK.

Are we only talking about multiple signatures in enveloped / enveloping
signatures?  What about detached signatures?

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 10 May 2004 17:48
> To: 'Nick Pope'; 'Trevor Perrin'
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Discussion on outstanding issues for the core.
>
>
> Nick and Trevor,
>
>    Nick seems to be favoring some basic rules for the core. I assume Nick,
> you feel that if one goes beyond these basic rules, we ought to
> relegate to
> profiles. O.K. so let's define the basic rules. Rather than repeat all the
> points in the "Suggestions" note, I'll only add to them. I'll
> just keep this
> to short point form for now. Here are some very basic rules to govern the
> crafting of the outstanding semantics. There is some repetition, but feel
> free to adjust as you see fit:
>
> - an InputDocument can contain a single signature or may contain multiple
> signatures
>
> - use of the SignatureObject element is optional when both
> signature(s) and
> References are self-contained in a given InputDocument
>
> - if multiple signatures are present, the implementation must either:
>      1) Verify all signatures, or
>      2) return urn:oasis:names:tc:dss:1.0:result:NotSupported if
> they cannot
> perform the Verify
>
> - implementations are free to support the verification of multiple
> signatures that may appear in a given InputDocument
>
> - implementations can limit their XMLDSIG verification support to one
> signature at a time either using the SignaturePtr, or without it
>
> - the SignaturePtr element should be initialized by the caller when
> verification of a "specific" signature is required
>
> - on a verify, SignatureObject can be omitted, in which case the caller is
> responsible for initializing the InputDocuments element with the signature
> and referenced content to be verified
>
> - in either scenario all signature References must be unambiguous and
> self-contained within the InputDocument as either an enveloped or
> enveloping
> signature
>
> - callers whose signature References make use of Id tags (e.g. of type ID)
> must ensure they are unambiguous through use of an included DTD
> declaration
> to ensure inter-operability
>
> Example:
>
> <!DOCTYPE testdoc [
>  <!ATTLIST Data Id ID #IMPLIED>
> ]>
>
>
>    see the rest of the "Suggestions" note for the remainder of the details
>
> Ed
>
>
>
>
>
>
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: May 10, 2004 9:48 AM
> To: Trevor Perrin; ed.shallow@rogers.com
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Discussion on outstanding issues for the core.
>
> Looks like we are just about there.
>
> I suggest if the <SignatureObject> not present the semantics that there is
> an enveloped  signature in the document.
>
> I am happy with defining some very basic rules for handling multiple
> signatures in the core such as Ed suggests, rather than leaving things
> undefined.
>
> Ed, Perhaps you can re-iterate what you suggest regarding
> handling multiple
> signatures.
>
> Nick
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 10 May 2004 09:18
> > To: ed.shallow@rogers.com
> > Cc: dss@lists.oasis-open.org
> > Subject: RE: [dss] Discussion on outstanding issues for the core.
> >
> >
> > At 02:05 PM 5/7/2004 -0400, you wrote:
> > >Nick,
> > >
> > >    I agree. When you boil it right down, we're fundamentally
> > talking about
> > >[Optionality] on 2 elements. I can't help but think that this is
> > >entirely consistent with the spirit of the "extensible" core
> > >protocol. But I would like to make sure that these very specific
> > >verification
> > scenarios will not
> > >pose a problem. So towards that end, can you (i.e. Trevor) me a
> > few signed
> > >documents which embody the verification concerns you have ?
> >
> > I'm concerned about protocol complexity, not any particular type of
> > signature.
> >
> > Anyways, I think there's consensus on the 1st of our 3 issues:
> >   - enveloping CMS should be explicitly supported
> >   - enveloping XML-DSIG " " " "
> >
> > As for the other issues, it seems there's consensus that we should
> > allow <SignatureObject> to be absent, but I'm not sure there's
> > agreement on the semantics.  I thought Nick was arguing they would be
> > undefined, and Ed was arguing the server would verify all signatures
> > that were present.
> >
> > If we can decide on that, I'll write something up.
> >
> > 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.
> >
> >
> >
>
>
>
>
>
> 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.