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

[<ed.shallow@rogers.com>]

Concur. Detached single is in. Leave detached multiple to profiles.

----- Original Message -----
From: "Nick Pope" <pope@secstan.com>
To: <ed.shallow@rogers.com>; "'Trevor Perrin'" <trevp@trevp.net>
Cc: <dss@lists.oasis-open.org>
Sent: Monday, May 10, 2004 5:30 PM
Subject: RE: [dss] Discussion on outstanding issues for the core.


> Ed,
>
> This suggests to me that for at least Multiple detached we do no try and
> solve everything in core, just make it extensible enough for this to be
done
> in a profile.
>
> I do not like the third option of mixing the input document and
> signatureObject structure.  This make things more complicated.
>
> I certainly would not like to remove detached signatures to profiles.
> However, delegating handling multiple detached signatures to a profile
seems
> reasonable.
>
> I believe that the SignatureObject is already flexible enough to be
> extensible to allow for alternative forms of signature.  So I see no need
to
> make it even more "unbounded".
>
> So my preference would be to keep the the handling of multiple detached
> signatures either unsupported or undefined in the core.  The syntax I
> believe is already flexible to enable this, the processing rule just need
to
> be suffiently this to be handled by profiles.
>
> Nick
>
> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 10 May 2004 19:26
> To: 'Nick Pope'; 'Trevor Perrin'
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Discussion on outstanding issues for the core.
>
>
> Nick,
>
>    Good question. I had thought that if it is XMLDSIG (not CMS) and
> detached, callers are presently encouraged to place the References in
> InputDocuments and the Signature in SignatureObject. Since the
> SignatureObject is not unbounded, we are stuck.
>
>    We could
>
> 1) make SignatureObject unbounded
>
> 2) relegate detached to profiles
>
> 3) callers place Referenced signed content in 1st InputDocument,
> Signature(s) in 2nd InputDocument, and
> SignatureObject|SignaturePtr|WhichDocument pointing to 2nd. This is
closest
> to what we have now.
>
> I had earlier held out the possibility that the WhichDocument element of
> SignaturePtr could be used as required by the implementation to locate
> signature(s). Please refer to original "Suggestions" note.
>
> As you can see, when you begin to tax the current spec in the
> SignatureObject area, it quickly shows its narrow focus. I would have
> preferred making InputDocuments the foundation of the request side of the
> verify protocol with qualifying elements to state things like "signature
> present", "target of reference", "multiple signatures present", and things
> like that. After all a signature is fundamentally a signed document, in
this
> case a signed InputDocument. InputDocuments can easily be specified to
> represent References, Signed Content, multi-signed Content, 2 of 5, etc
...
>
> Ed
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: May 10, 2004 12:13 PM
> To: ed.shallow@rogers.com; 'Trevor Perrin'
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Discussion on outstanding issues for the core.
>
> 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.
>
>
>
>
>
>
>
>
> 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
.
>