[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Discussion on outstanding issues for the core.
A couple of questions, 1. I would substitute mentions to DTDs by DTDs or Schemas, just for avoiding questions. 2 should the DTD (XML schema) being necessarily transmited or could also be possible just incorporate a URI pointing to the place where it is published? I would initially be in favour of allowing both mechanisms. Juan Carlos. At 19:23 10/05/2004 -0700, Trevor Perrin wrote: > >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.p hp. > > >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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]