OK lets get crunchy. You concede we need change, let's get down to
exactly what we have to change.
Edward Shallow wrote:
-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: September 16, 2004 3:13 AM
To: ed.shallow@rogers.com
Subject: Re: FW: [dss] OASIS DSS - SignatureObject on Input
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.
Decision 1: The notion of timestamping signatures which do not require
verification, utilizing the Verify protocol with ReturnUpdatedSignature
is dead. The Sign protocol, or better the Timestamp profile of the Sign
protocol, can legitimately timestamp inbound signatures thus producing
what is by definition a signature timestamp. This capability is not
mentioned anywhere in either the core or Timestamp profile and must be
added to the text of the core directly, or at a minimum mention it and
refer off to the Timestamp Profile for details.
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.
Absolutely wrong. In the case of a request for a Timestamp, which by
the way is on the Sign protocol, the timestamp (signature) IS the
primary signature. In your own words ...
"... In the Sign case, the server is treating the signature as just a
data element to be signed..."
Now the text is totally void on this subtlety because it is void on the
whole subject of signature timestamp !!!
When are you going to concede that the core doc needs fixing ?
You're proposing that the
client can use optional inputs to control the time-stamp as well.
No I'm not. If I remember correctly all I asked was that you provide
better support AND text for signatures on Sign (i.e. Timestamp)
requests. Essentially, either add SignatureObject (preferred), or add
text which officially legitimizes use of the Document w/ MimeType
"application/pkcs7-signature" claiming it was always there, because it
is not.
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>.
You are not controlling multiple signatures. It is fundamnetally a
simple sign whose scope is part of the incoming thing as you call it.
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).
Decision 2: DocumentWithSignature only addresses XML and must be
generalized if you are advocating returning the timestamped signature
this way. Additionally the text must reflect the rationale as to why
this generalization exisits.
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.
Decision 3: Change DocumentWithSignature to be a subclass of Document
so as to pick up the choices.
P.S. What I was suggesting earlier, is to simply collapse
DocumentWithSignature and use Document. The flexibility of MimeType
already supports your arbitrary separation of these 2 elements. Then
you have a nice simple setup where your only dealing with Documents and
Signatures. Due to all the optional choices and attributes of
SignatureObject, I agree we should resist a more total collapse. The
only down side is that you have the possibility of signatures in both
constructs. But at least it is down to 2 instead of 3 possible
vehicles.
Either way you have change.
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.
I can buy this semantic distinction.
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.
Do remember it is the primary signature under this interpretation. This
was the motive in the first place of making Timestamp a profile of Sign.
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.
Decision 4: See above. I vote for a partial collapse eliminating
DocumentWithSignature which is already handled admirably bu Document.
In the real world a document is a document regardless of whether it is
signed or not. The signature is in fact just an attribute (read
MimeType) which qualifies the Document. It is not an entirely different
thing. This is the beauty of advanced dialects like XML.
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.
If you agree with the above, then this is a non-issue.
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.
I buy this.
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.
Decision 5: More than not mentioning it to me, you haven't included any
text at all in the core covering this scenario and MimeType use. At
least a sentence or 2 !!!
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 is dead.
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.
I can changed this. The XAdES Profile may also have to change.
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.
Just give us some text. (i.e. Decision 5)
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.
I can live with this semantic generality. You like "Input" adjectives,
I like generalization because I like simplicity.
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
|