OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] OASIS DSS "Request for Feedback" - Signing Templates


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]