Re: FW: [dss] OASIS DSS - SignatureObject on Input

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

Before we proceed , some background.

I assumed we all agreed that ReturnUpdatedSignature on the Verify when in fact we are not even doing a Verify is too fundamentally inconsistent and is a semantic mortal sin. I also assumed that we had consensus on performing timestamps of existing signatures on the back of the Sign protocol. I'll send you the list links if you can't find them. We also discussed this subject on a July conference call where again I assumed we had consensus. JC and Nick can back this assertion.

Now on to the task of passing up the signature under this scenario, see below.

 

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: September 15, 2004 11:21 AM
To: dss@lists.oasis-open.org
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.
    

So this does not get lost in the shuffle, will you be improving the text here ?

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.
  

Let's review the possible options for sending in a signature.

1) We could pass it in as an InputDocument which would require a specifc MimeType of "application/pkcs7-signature" on the Base64Data element of the current Document element. This would require no change at all. <SignaturePlacement>  would not be required on a signature timestamp of this type, because there is only one place to put it.

2) Add SignatureObject as a valid optional input element as suggested.

Issue: The problem with current spec if that there isn't sufficient generalization of a base Document, or consistency across usage scnearios. We have documents, we have signatures, and we have documents with signatures, Documents can only be used on input, DocumentWithSignature can only be used on output, SignatureObject can only be used on output. If it is an enveloped signature, we call it a document. If it is a CMS signature being verified on a Verify call, we pass it up in a SignatureObject, even though it contains eContent. So passing a CMS signature up in a Verify call is good for you, but passing a CMS signature up to be timestamped on a Sign call is not ?  Where's the consistentcy. Why didn't we consider using Document for all transport duties, in and out to simplify the above ?

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 wager that messiness has already slipped in. As we get into these use-cases, this is becoming evident. The text is in need of additional clarifying prose, unless of course we fix it.

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.
  

Then why did you not suggest passing the signature up as an InputDocument with Document attributed as MimeType "application/pkcs7-signature" ?

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.

This in fact has changed. If the Verify fails, the user doesn't get his timestamp when in fact they never wanted a Verify. I have already given you the use-case with the internal corporate PKI, and I believe the team agrees that ReturnUpdatedSignature on the back of a Verify doesn't cut it. 

  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.
  

Already done in the EPM Profile where SignatureObject is an optional input on a Sign. The team saw the inability to timestamp a signature (w/o a Verify that is), and had me post this question. Either allow SignatureObject as a valid vehicle for a CMS signature on input, as it currently is supported on the Verify, or bless use of signatures in InputDocument where Document MimeType attribute can be "application/pkcs7-signature", which is a valid MimeType. I really thought I'd be breaking less rules by asking for SignatureObject as valid Sign input, than encouraging use of  signatures masqueraded as base64Data in InputDocument. All I have managed to do is point out the inconsistencies of the current delivery elements (i.e. Document, SignatureObject, and DocumentWithSignature). There has not been a change to the core since the June Committee Draft. I had not heard that is was frozen. Is this the case ?

We have a problem requiring fixing.

Ed

Trevor 


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
.