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

["Edward Shallow" <ed.shallow@rogers.com>]

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