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

[<ed.shallow@rogers.com>]

Yeah, looks pretty good. See minor tweaks inter-mixed.

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


>
> Okay, I think I got it.  These are the changes I'll make, unless someone
> objects:
>
>   - <SignatureObject> can contain a CMS detached or enveloping
> signature.  If enveloping, <InputDocuments> is omitted.
>
>   - <SignatureObject> can contain an XML enveloping signature.  If
> enveloping, <InputDocuments> may or may not be present, and
at least a partial DTD
> identifying ID attributes needs to be transmitted as part of the document.
>
>   - <SignatureObject> can be omitted entirely, if there's only a single
> Input Document.  In this case, the Input Document *must* contain at least
> one <ds:Signature> element.  The server will find and verify this
> element.  A DTD identifying ID attributes must be transmitted
as part of the document.  If there
> are multiple <ds:Signature> elements, the server must verify them all, or
> else return a NotSupported error.  If an error occurs verifying multiple
> signatures, the first error will be returned.  Signature-specific optional
> inputs or outputs are not allowed if the server is verifying multiple
> signatures.
We should invite implementations to explore the InvalidDetail unbounded
element of ProcessingDetails if they wish to return error information on 2nd
and subsequent signatures.
>
>   - If there are multiple Input Documents,
> <SignatureObject/SignaturePtr/WhichDocument> can be used to indicate the
> input document containing the signatures, which will be processed as
above.
>
>   - In the preceding 3 cases, the server may find that some ds:Reference's
> point to XML content within the signature's Input Document
(in the case of enveloped signatures)
or Signature Object (in the case of enveloping signatures),
and some point to other Input Documents.
The server should first check any <ds:Reference/@URI> that may be present
against each Input Document's RefURI, and if a
> match is not found, then try to resolve barename XPointers against the
> signature's Input Document or Signature Object.
It was for this reason that I wanted to collapse SignatureObject,
SignaturePtr, and WhichDocument into simpler constructs within a tweaked
InputDocument structure. Given what we are doing, it improves readability.
I'll defer to the will of the majority though.
>
>   - Otherwise, verification proceeds as currently spec'd
>
>
> Trevor
>
>
> At 12:47 PM 5/10/2004 -0400, Edward Shallow wrote:
> >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_workgroup.ph
p.
>