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

[Trevor Perrin <trevp@trevp.net>]

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 a DTD 
identifying ID attributes needs to be transmitted somehow.

  - <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.  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.

  - 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 or Signature 
Object, and some point to other Input Documents.  The server should first 
check a <ds:Reference/@URI> 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.

  - 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.php.