Re: [dss] CMS Timestamps Core Review - PostScript

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Ed,

Starting by the end, yes, I think that we should have a skype call this 
week before Monday's call.... I think that Nick is not available until
Friday... which could be a bit late... would it be OK for you to have 
this skype meeting tomorrow in my afternoon/evening? Something about 
11:00am Eastern time (that woule be 17:00 CET) would fit me....
Now, some remarks intermixed:

Edward Shallow escribió:
> Hi Nick, Juan-Carlos, and Stephan,
> 
>   I have reached an impasse as I got deeper into the XML Timestamp review.
> Content Timestamps in an XML setting are very tricky and greatly overlap
> with the scope of the signature References themselves. I do not see an easy
> way forward if I stay on this track. We could look at removing this
> treatment altogether. That is, the handling of content timestamps on both
> Sign and Verify altogether. The related problem is that the text for
> Timestamp verification which is nailed down fairly nicely might also have to
> be de-scoped to remove references to content Timestamp treatment.
> 
I am not sure of understanding the details of the issue. You mean that 
the XML time-stamp should have ds:Reference elements referencing those 
data objects that at the same time are referenced by the enclosing XML 
signature, isn't it? and this causes problems... and that in the light 
of that it would be better to defer this issue to some profile instead 
to mix everything in the core...is that what you mean?

>   The last problem is that AddTimestamp as it is, ONLY covers adding
> Timestamps to existing signatures and does not address adding Timestamps to
> the signature being created which by definition excludes the possibility of
> supporting content timestamps for the Sign protocol. At least not without a
> re-write.

OK... then in my previous email I missinterpreted one of your comments.
Specifically, in your Point 5) you suggested to substitute:

"In this case the DSS server MUST create a valid signature timestamp 
who’s MessageImprint is derived from the signature value of the 
signature passed in on the request"

by
"In this case the DSS server MUST create a valid signature timestamp 
who’s MessageImprint is derived from the signature value of the 
signature just created."

This lead me to the interpretation that you were opening the doors to a 
SignRequest for creating a signature and a time-stamp on the content and 
suggest changes in the text of AddTimeStamp... But now I remember that 
in a former call this was told not to be allowed..... BTW, I see 
Trevor's message also asking if that is not allowed... anyway, whatever 
it is, it has to be clearly stated ....


> 
> Here is my recommendation:
> 
> - remove all references and handling of content Timestamps from the core in
> both the Sign and Verify protocols as it pertains to both CMS and XML. That
> would be Combinations 1, 2, 5, and 6
> 
> - beef up the intro to 3.5.2 to make this scope more clear
> 
> - we may have to encourage users to utilize SignedProperties or the XAdES
> profile if they want to do any more advanced content Timestamping
> 
> - augment the Timestamp profile to handle most of this stuff that has been
> pushed from the core
> 
> - make references in the core to where one should seek support for Timestamp
> handling not covered as per this new scope
> 

Let us talk through skype. I guess that whatever solution leads to sth. 
coherent among core, timestamp profile and xades profile, with the 
suitable indications in the core would be OK.


> 
>    This is a scope change but would involve a lot less work. As long as we
> are consistent, it should be OK. This however requires a Timestamp profile
> update as it is now serving little purpose. It needs to take responsibility
> for standalone Timestamp handling in a more informative manner dealing (at
> least at some cursory level) with the numerous use-cases.
> 
> Stephen, please ignore my post of last Friday until we agree on a course of
> action.

> 
> Nick I suggest we get on a Scype call this week as opposed to waiting for
> next Monday ? What do you think ?

See above

Regards and thanks
Juan Carlos
> 
> Ed  
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php