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

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

Good stuff Trevor I think we're getting there,

   I concur in general but am afraid we have not gone far enough in our
quest for improvement. If we collapse DocumentWithSignature (in content thru
extension, but not in name) then we still have a number of problems. The
fact that these subtleties have eluded us (who are clearly well versed in
the protocol) for so long, and the fact that it takes so long so clarify our
positions which each other, tells me that outside readers will glaze over in
confusion. It is not sufficiently simplified. Then throw in the various
interpretations and decisions that exist within the profiles (especially
XAdES and EPM), and I wager readers will be further confused. 

   What I am saying is that the exercise to harmonize the EPM and XAdES has
taken us back to the core, and the Timestamp profile. We seem to have made
modest progress in harmonizing XAdES and the EPM, but they will not be read
first, the core will be the primary focus for readers. They all must read
clearly and support the desired notion of "core" and "extensions to core"
via profiles. The whole area of timestamping presently can be achieved under
at least 4 frameworks rach supporting similar timestamp types: 1) out of
core with things like AddTimestamp and ReturnUpdatedSignature; 2) as
advocated by the Timestamp profile; 3) within the EPM which supports both
core notions and extended receipting notions, but still lacks sufficient
consistency with core; and finally 4) XAdES which simply attempts to allow
the requesting of very established and solidly approved ways of producing
signature "forms" and has stood the test of time through ASN1 variations
right up to XMLDSIG.

   JC's initial editorials in the XAdES profile, his comments on the EPM,
and this latest round of discussions needs to be fully appreciated by the
key stakeholders.

  I think our little "transport element" debate is interesting, but my
larger unaddressed concern is the text across these 4 documents as they
pertain to timestamping.

  Forget about the mechanics of SignaturePlacement, DocumentWithSignature,
SignatureObject, (Document, DocumentBaseType, InputDocuments), Poperties (as
they might apply to timestamps as Gregor suggests), ReturnUpdatedSignature,
UpdateSignatureOnly, AddTimestamp, DocumentWithTemplate, SignatureForm,
DocsToBeTimeStamped, GenerateAsCounterSignature, and the list goes on ...

  Can this "text improvement" issue, across all documents, be officially
addressed as an Action ? 

*****************
Now I'd like to get back to the DocumentWithSignature discussion and the
larger "transport element" issue.

Collapsing DocumentWithSignature "in content but not in name" is simply
confusing, especially when one is allowed to qualify documents as signatures
through attributing. Further, attempts to add clarity by adding an Input
prefix in front of names when the element clearly appears in the Request
structure is redundant. Then we complicate all the above when we introduce
adding timestamps to incoming signatures, adding timestamps to incoming
signatures in documents, requesting standalone timestamps, returning
standalone signatures, adding timestamps to verified signatures which are
returned standalone, adding timestamps to verified signatures which are part
of incoming documents, and this list goes on ...

As one can see the permutaions and combinations of where one puts things on
the way in and where one puts things one the way out is exponetially
increased as we increase the arbitrary splitting of "the transport
elements". All these elements share a majority of their attributes and beg
reuse. I think we have done a great job on the DocumentBaseType. Let's
exploit it more. A Document on a Request is obviously an Input Document, and
a Document on a Response ... you get the picture.

I think we are almost there, please consider more collapsing as a path to
consistency. This will also help when one is faced with updating the text.

Ed        

      
   

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: September 17, 2004 2:41 AM
To: dss@lists.oasis-open.org
Subject: Re: FW: FW: [dss] OASIS DSS - SignatureObject on Input

At 01:34 PM 9/16/2004 -0400, ed.shallow@rogers.com wrote:
>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>mailto:trevp@trevp.net]
>>Sent: September 16, 2004 3:13 AM
>>To: <mailto:ed.shallow@rogers.com>ed.shallow@rogers.com
>>Subject: Re: FW: [dss] OASIS DSS - SignatureObject on Input
>>
>>At 05:30 PM 9/15/2004 -0400,
>><mailto:ed.shallow@rogers.com>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.

Agreed.


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

Okay.



>>>>>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 case of <AddTimestamp>, the timestamp is the secondary signature.
Your request, I thought, was to add text about using <SignaturePlacement>
with <AddTimestamp> to apply to the 2ndary signature.  I pointed out that
<AddTimestamp> doesn't apply to the 2ndary signature, but to the primary
one.



>"... In the Sign case, the server is treating the signature as just a 
>data element to be signed..."

We need to be careful to distinguish:
  - Use of <AddTimestamp> on a Sign Request to produce a signature timestamp
as a secondary signature
  - Use of timestamp profile to produce a signature timestamp as a primary
signature


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

I agree this is subtle and not mentioned.  Adding text to explain things is
fine with me.


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

At this point we're talking about different things.  I was responding to 
your request under "Examples:", above, not your proposal as a whole.


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

Agreed.



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

Maybe we should have a DocumentType, which <Document> and 
<DocumentWithSignature> are both instances of.  The problem with just using 
<Document> as an optional output, is it might become ambigous which 
optional input this corresponds to (say some other profile wants to return 
a <Document> optional output).  So calling it <DocumentWithSignature> makes 
its semantics clear, and ties it to the the <SignaturePlacement> input.

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

I vote for collapsing them in contents but not name (see previous).

[...]
>>
>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 !!!

I'll make a text proposal before the next meeting.



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
.