RE: [dss] OASIS DSS - SignatureObject on Input

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

Intermixed. 

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: September 14, 2004 12:00 AM
To: ed.shallow@rogers.com
Subject: Re: [dss] OASIS DSS - SignatureObject on Input


Right now, the Signing protocol always returns a Signature Object.
Presumably the client can insert that Signature Object into a document
itself.  If the client doesn't want to do that, it can have the server
insert the signature into an Input Document, and return that document, with
the <SignaturePlacement> / <OutputDocument> options.

Not the use case I am refering to.

You're considering the case where the client wants the Signature Object (a
timestamp) inserted into a particular type of document (a different
Signature Object).

No, not that one either. I clearly stated the use case involved the client's
need to timestamp an "existing" signature whether it be an ASN1 or XMLDSIG
one. The scenario could be an internal corporate PKI wishing to have an
independent timestamp applied to an existing internally created signature.
Clearly the client needs to pass the signature in.

This need simply be a single call to the Sign protocol instructing the
server to timestamp "this" signature. No need for multiple calls, no need
for ASN1 or XMLSig embedding by the client. Just "Update this Signature ...
please". Everyone liked it on the Verify, but I don't need a Verify, it
likely has already been Verified. I just want a standard signature
timestamp, CMS example would be an unauthenticated attribute ... 
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 14 }
That is 1.2.840.113549.1.9.16.2.14

... to an "existing" signature.

I don't think that needs to be a special case.

This is only special in that it has been omitted.

So I don't see a need to add this to the core.

Please add it.

Ed



At 02:33 PM 9/10/2004 -0400, Edward Shallow wrote:
>Folks,
>
>    Another feedback question I was tasked with on the September 6th 
>conference call (That's what happens when you miss a call, they punish 
>you when you get back ;).
>
>    One of the questions in the Editorial Section of the EPM Profile 
>relates to the need for a minor change to the core. As such the chairs 
>thought it best I post this request for feedback to the list so people are
aware.
>
>    It relates to the need to include the <SignatureObject> element as 
>a valid element in Sign input, which today it is not. The need arises 
>in the EPM profile which wants to support the embedding of timestamps 
>into existing signatures, a common occurrence. Here is the text from 
>the EPM Profile explaining the <SignatureObject> optional input. This 
>stemmed from the consensus not to "bend" the Verify protocol when in 
>fact no verify is being requested. This will be common when the 
>Validation Authority either does not perform timestamping or these 2
services are separated.
>
>The <SignatureObject> optional input is only used when users are 
>requesting a timestamp <SignatureType>, and additionally would like 
>that timestamp embedded into an existing signature they may have in 
>their possession. When creating timestamps, the EPM supports the 
>embedding of the requested timestamp into an "existing" signature 
>structure. As such the user must be able to pass in the signature to be 
>timestamped on the request. For this reason the EPM profile is 
>leveraging the existing <SignatureObject> schema type as an optional input
to carry the user's signature to be timestamped.
>The EPM will add a signature timestamp as defined in section 3.1.2.2 above.
>Usage of the <SignatureObject> element is required because the 
>signature into which the timestamp will be added already exists and is 
>not being generated as part of this request.
>
>    Can the <SignatureObject> be included into the core and the 
>necessary text and semantics added ?
>
>Ed
>
>
>
>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.ph
p.