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

[Trevor Perrin <trevp@trevp.net>]

At 05:30 PM 9/15/2004 -0400, ed.shallow@rogers.com wrote:

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

I don't mind signing signatures.  I mind digging a new trench in the 
protocol just for this.  Signing a signature should be like signing 
anything else.


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

Sure.


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

I wasn't planning on it.  With <AddTimestamp> the server sticks a 
time-stamp on the produced signature.  The client can control the 
time-stamp only by specifying a "Type" URI (a profile could define URIs for 
content timestamps, signature timestamps, etc).

In other words, optional inputs like <SignaturePlacement> don't control the 
time-stamp, they control the "primary" signature.  You're proposing that 
the client can use optional inputs to control the time-stamp as 
well.  Controlling multiple signatures in a single Request would get 
complicated, which is why we've specified only a minimal, simple form of it 
with <AddTimestamp>.


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

Sounds good to me.

>  <SignaturePlacement>  would not be required on a signature timestamp of 
> this type, because there is only one place to put it.

Normally, the server doesn't "put" the signature anywhere, it just returns 
it in the <SignatureObject>.  For consistency's sake, it would be good to 
still use <SignaturePlacement> to signal "insert the time-stamp into this 
Input Document", and <DocumentWithSignature> to return the time-stamped 
Input Document (i.e. signature).


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

Like I've said, I'd prefer to handle to-be-signed signatures like any other 
to-be-signed element.


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

Sounds fine to me.  Except that currently <DocumentWithSignature> can only 
be XML, so we should extend it to contain the same things <Document> can.

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

It's fine to pass it up to the server.  But in the Verify case I would call 
it a Signature Object, and in the Sign case an Input Document.  In the 
Verify case, the server is treating the signature *as* a signature, parsing 
and verifying it etc.  In the Sign case, the server is treating the 
signature just as a data element to be signed, and to have the resultant 
signature potentially inserted into.  This element happens to be a 
signature, but the server doesn't really deal with it as such.

>Why didn't we consider using Document for all transport duties, in and out 
>to simplify the above ?

Then we'd have a protocol with no structure.

>>
>>>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" ?

I did.  Well, I didn't mention the MimeType.


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

consider it blessed.  I don't know why it would be prohibited.

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

I don't think they're masquerading as base64Data in an Input 
Document.  They *are* base64 data in an Input Document.


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

cooling, at least...  I'm glad we're getting feedback from profilers / 
implementers, though..  that's the best kind.  Clarifications, fixes, 
cleanups, etc. based on experience are desperately needed... I just hope we 
can integrate them without drastic changes or new features.


Trevor