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

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

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.