[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Discussion on outstanding issues for the core.
My comments (a bit later due to differences in time) intermixed. At 22:30 10/05/2004 +0100, Nick Pope wrote: >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 do not like either this mixture of documents and signatures... >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". > My view is that if we can ensure that the minimum behaviour described by Ed for enveloped signatures can be provided by making this element unbounded, I would initially be in favour of including it as it would offer a balanced core, with the same capabilities for all the types of signatures whatever their type would be. >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. Again I would rather prefer a balanced solution offering the same capabilities for all the singature types (specially if the only price paid is to make an element unbounded). Juan Carlos. > >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. > > > > > > > > >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]