RE: [dss] OASIS DSS - SignatureObject on Input

[Trevor Perrin <trevp@trevp.net>]

At 12:27 AM 9/15/2004 -0400, Edward Shallow wrote:
>Trevor,
>
>As it applies to the "timestamp this CMS signature please" scenario, your
>suggestion works technically (although it is much messier for you and the
>protocol), but not semantically. Both the request and the response are just
>CMS/PKCS7 SignedData signatures. If one assumes that this is all driven by
>an AddTimestamp optional input and the SignatureType is RFC3161, then why
>would the client be sending in more than one signature/document ? Hence
><SignaturePlacement> and <WhichDocument> are superfluous in the CMS
>scenario. For XMLSig everything is fine. However, the AddTimestamp optional
>input section could use some beefing up in the XMLSig area as well.
>Examples: If the AddTimestamp attribute specifies a content timestamp, then
>SignaturePlacement should be used; If the AddTimestamp attribute specifies a
>signature timestamp, then the timestamp will be placed in the same document
>as the signature, and SignaturePlacement should be be used to specify the
>exact placement (i.e. XpathAfter). This whole timestamp area should be
>clarified for both CMS and XMLSig.
>
>In summary, I really see no down side in simply allowing an existing element
>(i.e. SignatureObject) to appear in a Sign request for semantic integrity.
>Your changes to <DocumentwithSignature> will start to make it look like
><DocumentBase>, and THAT will really get confusing.

I don't see why.

>Do you have a good reason not to add it ?

We already have a mechanism for telling the server what to sign (Input 
Documents) and suggesting the signature be inserted in one of them 
(SignaturePlacement).  I'd rather not change the behavior of the Sign 
protocol so much that there's an alternate way of doing these things.  That 
seems messy, and a big change at this point.

I consider this a special case because we're asking the server to insert 
the signature into a particular type of thing.  What if I have to insert 
the signature into a different type of thing.  Like a mortgage 
application?  Why don't we add a <MortgageApplication> element to the core 
so the client can pass in a mortgage application, and so on?  My suggestion 
to extend <SignaturePlacement> would generalize to inserting a signature 
into any type of document, binary or not, whereas special-casing for input 
Signatures would not.

Also, we had long discussions of how to do signature updating earlier, 
where we considered many options, such as adding a separate Update 
protocol, or adding this to Sign.  We settled on Verify / 
UpdateSignature.  Yes, it does an extra Verify, but at the time people were 
willing to live with that.  So I had hoped we were done with the issue, in 
the core at least, though of course you can do whatever you want with your 
profile.

If you spec out an optional input, though, it might help other other people 
decide whether they like this or not.

Trevor