[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] OASIS DSS - SignatureObject on Input
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]