[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] OASIS DSS "Request for Feedback" - Signing Templates
I think templates are out of scope for a standard. > -------- Original Message -------- > Subject: RE: [dss] OASIS DSS "Request for Feedback" - Signing Templates > From: "Edward Shallow" <ed.shallow@rogers.com> > Date: Mon, September 13, 2004 8:08 pm > To: kuehne@klup.de > Cc: "'OASIS DSS TC'" <dss@lists.oasis-open.org> > > More feedback on your point where youy state ... > > "... I want a signature server to be aware of every bit of the signature > output. That's assured by building the signature document from scratch ...". > > > ... Are you not confusing who is in charge here ? If a client wants a > signature of some arbitrary nature and complexity, and if that request, no > matter how it is presented to the server, is valid under the governing > signature policy, it is the DSS server's job to construct that signature for > the DSS service consumer. An analogy ... If a man hires a contractor to > build an add-on to his house, he stipulates dimension, material, time-frame, > etc ... The contractor follows all his wishes while making sure he is > following building code and zoning bylaws. However the man gets what he > wants as long as its legal. Policy enforcement is really all the DSS Server > can enforce, everything else is user dictated. > > Similarly, policy aside, how a DSS user specifies signature > specifications is really just a questions of efficiency. If you are saying > things can slip by, then I would respond that the explicit signature > creation inputs elements are inadequate or short of target. In other words, > even if you don't agree that templates are a legitimate mechanism for > expressing the desired signature target, then at least you must concede that > anything a template can express should at least be supported by DSS's input > element constructs. Semantics must be adequately and comprehensively > addressed in either scenario, the rest is simply request/response mechanics. > So if the core can't support a given construct which might "slipped by" in a > template scenario, then it is obliged to state so in its semantic scope and > further clarify that this construct is only supported in profiles. > > Ed > > -----Original Message----- > From: Andreas Kuehne [mailto:kuehne@klup.de] > Sent: September 13, 2004 2:48 AM > To: ed.shallow@rogers.com > Cc: 'OASIS DSS TC' > Subject: Re: [dss] OASIS DSS "Request for Feedback" - Signing Templates > > Hi Ed ! > > Let me express my discomfort with the template approach. > > I guess a template is useful in he case of a signing server which is not > capable of some ( new / strange ) aspects of a signature format. So it > would just sign but not interpret the rest of the template. That sounds to > me like putting your sign under a document you cannot read or understand ! > > I want a signature server to be aware of every bit of the signature output. > That's assured by building the signature document from scratch, not by > filling in some bits in a template document. > > Greetings > > Andreas > > >Folks, > > > > As a result of a discussion on the September 6th conference call, > >the OASIS DSS chairs would like your feedback and opinion on the > >potential use of "signing templates" as an option within DSS core. A > >brief description follows. > > > > Essentially signing templates are XML skeleton "signed documents" > >which are passed up to the Sign protocol as input. The template > >embodies all of the directives and format required of the resultant > >signature expressed as an XMLSig-compliant template. > > > > A signing template contains not only the data to be signed, but > >also the format and directives of the signature to be created, > >expressed as valid [XMLSig] elements. [XMLSig] elements such as > ><SignatureValue>, <DigestValue>, and <X509Certificate> are left empty > >on input, but are subsequently populated by the DSS service. The user > >simply leaves these selected element tags empty, and the DSS service > >would automatically include the generated content and return the signed > >document in the appropriate element of the <SignResponse>. > > > > The best way to illustrate a template is via an example. As one can > >see, things like transforms, signature placement, key name, certificate > >details, digest algorithms, and more can all be expressed in the > >template. Things like digest value, signature value, certificate body, > >etc ... Are filled in by the DSS service. > > > > It is just a convenient way of expressing signature requirements. > > > > The question to the team is "Should a generic non-specific notion > >of templating be incorporated in the DSS core ?" > > > > Feedback welcome and encouraged. > > > > > ><?xml version="1.0" encoding="UTF-8"?> > ><Document> > > <Data> > > <SubData1 MimeType="text/plain">This is some data to be > >signed.</SubData1> > > <SubData2 MimeType="text/plain">This is more data to be > >signed.</SubData2> > > </Data> > > <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#";> > > <dsig:SignedInfo> > > <dsig:CanonicalizationMethod > >Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> > > <dsig:SignatureMethod > >Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > > <dsig:Reference URI=""> > > <dsig:Transforms> > > <dsig:Transform > >Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > > </dsig:Transforms> > > <dsig:DigestMethod > >Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > > > ><dsig:DigestValue></dsig:DigestValue> > > </dsig:Reference> > > </dsig:SignedInfo> > > <dsig:SignatureValue> > > </dsig:SignatureValue> > > <dsig:KeyInfo> > > <dsig:KeyName>C=CA, O=Acme, OU=For Test Use Only, > CN=Joe Public, > >E=JoeP@yahoo.ca</dsig:KeyName> > > <dsig:X509Data> > > > ><dsig:X509Certificate></dsig:X509Certificate> > > > ><dsig:X509SubjectName></dsig:X509SubjectName> > > > ><dsig:X509IssuerSerial></dsig:X509IssuerSerial> > > </dsig:X509Data> > > </dsig:KeyInfo> > > </dsig:Signature> > ></Document> > > > > > > > > > > > > > >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 > . > > > > > > > > > > > > > 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]