OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: CMS Timestamps Core Review - PostScript


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.

  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.

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


   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 ?

Ed  





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]