Re: [dss] Incorporation of signature timestamp in XML signatures.

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

Ed,

Thanks for your reply...see intermixed...

ed.shallow@rogers.com wrote:

>Agree on the expedience advantage. One cannot argue that option 1) allows quick handling. But is this the only design objective i.e. to wrap things up ? I guess it is convenient but it now makes the standard asymmetric with regard to signature timestamp handling across CMS and XMLDSIG. If one does not have a problem with this, then I guess we are OK with option 1.
> 
>  
>
Obviously to wrap things up is not the only design objective...

>But JC's old argument that "If CMS signature timestamp handling is exactly as defined in ES 101 733 or RFC 3126" then why not take them out also. This would preserve symmetry between level of treatment of CMS versus XMLDSIG in the core. The argument for keeping signature timestamps in the core, is that the core deals directly and unequivocally with signatures, and timestamps often come along for the ride or need to be created at the same time. This is why we we forced to get into it. Furthermore we broke new grounds by defining for the first time in the industry an XML representation of a timestamp using XMLDSIG-based signatures (unlike ANSI X9).
> 
>  
>
I agree with what you say...

>If we are going to endorse XAdES, which is by the way ETSI TS 101 903 and the XML equivalent of ETSI TS 101 733 which is its CMS counterpart, then lets endorse right across the board.
> 
>I will admit I argued against blindly endorsing another standard, but perhaps this resurrects the issue. I did not realize that INCOPORATION was a problem. But if we are not going to step up to creating something new, we might as well be consistent in endorsing the exisiting standards in a consistent way. This would mean an option that removes both CMS and XMLDSIG treatment and refers off to ETSI ES standards for both CMS and XMLDSIG signature timestamps. Notice I said ETSI ES 101 733 not RFC3161 which only tangentially covers signature timestamps in an Appendix as an example use-case. 
> 
>  
>
Well, the second alternative was precisely to endorse ETSI TS 101903, 
and as we said, we had detected certain reluctances to endorse it in the 
core... are you saying that you would prefer to endorse ETSI TS to take 
the signature time-stamp in XML format out from the core and put in AdES 
profile? I would admit that if this would be the consensus in the group, 
I personaly would not have any problems in doing that (and it would be 
easy to get the final and aligned text). I guess that then would anyone 
in the future appear with new time-stamps formats and/or incorporation 
mechanisms this could be dealt with in a new profile....

Juan Carlos

>Ed 
> 
> 
>
>----- Original Message ----
>From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
>To: DSS TC List <dss@lists.oasis-open.org>; Juan Carlos Cruellas <Cruellas@ac.upc.edu>; Nick Pope nickpope@secstan.com
>Sent: Wednesday, May 31, 2006 12:28:43 PM
>Subject: [dss] Incorporation of signature timestamp in XML signatures.
>
>
>Dear all,
>
>Nick and myself have gone through some of the open issues of the core 
>directly related with signature time-stamps.
>
>After some talk we have found that the situation of RFC 3161 signature 
>time-stamp tokens and XML signature time-stamp tokens are different as 
>per the facility to be incorporated in the core: while RFC 3161 defines 
>both a FORMAT for a time-stamp token AND a STANDARD WAY FOR 
>INCORPORATING IT WITHIN A CMS SIGNATURE, XMLSig does not define neither 
>a format nor a standard way for incorporation in XML signatures. Now, 
>this TC has defined a format and XAdES has standardized a WAY OF 
>INCORPORATING this signature time-stamp (as well a way of incorporating 
>a RFC 3161 signature time-stamp) in a XML signature.
>
>Section 4.3.2.1 (verification processing of CMS RFC 3161 timestamp 
>tokens) text is based on RFC 3161 when considering both aspects, format 
>AND INCORPORATION (step 1. makes a reference to this incorporation), 
>which makes the processing of a RFC 3161 signature time-stamp of a CMS 
>signature completely unambiguous.
>
>Such level of unambiguity is NOT ACHIEVABLE in section 4.3.2.2 UNLESS WE 
>USE AS BASE A STANDARDIZED MECHANISM FOR INCORPORATING OUR XML 
>TIME-STAMP TOKENS WITHIN XML SIGNATURES. And so far, the only standard 
>with  growing acceptance specifying this is XAdES.
>
>Faced with this situation, we think that whilst RFC 3161 signature 
>time-stamp tokens in CMS signatures management does not put special 
>problems to our core document, it does not happen the same for XML 
>time-stamp tokens or for RFC 3161 signature time-stamp tokens of XML 
>signatures by the reasons we have mentioned above.
>
>This would mean that we do see good reasons for keeping within the core 
>sections 3.5.2.1, 4.3.2.1,
>
>Now, after some talk we have been able to identify three different 
>alternatives for solving the problem of  signature time-stamp tokens in 
>XML format (and the RFC 3161 signature time-stamp tokens OF XML SIGNATURES):
>
>1. We just take them out of the core (allow us to be clear: ONLY THE XML 
>time-stamp tokens), and put the corresponding text in the AdES profile 
>conveniently aligned. This would mean to take out of the core sections 
>3.5.2.2 and 4.3.2.2. The core would offer then different solutions 
>depending on the time-stamp token format selected (and even depending on 
>the signature format) but this would not be other thing that making 
>explicit the differences in the standardization in both fields, CMS and 
>XML. This would allow us to quickly solve the problem of the core and 
>likely not to have too many problems in AdES profile as everything 
>should be aligned with XAdES.
>
>2. We keep sections 3.5.2.2 and 4.3.2.2 in the core AND eliminate the 
>ambiguity by aligning them with XAdES, as it is the only existing 
>standard specifying how to incorporate signature time-stamps within XML 
>signatures. Voices claiming not to align too much the core with XAdES as 
>well as voices answering that if this is the only standard solving the 
>problem justifies this alignment have been heard in the discussions held 
>in our committee, which seems to anticipate further discussions....
>
>3. We keep sections 3.5.2.2 and 4.3.2.2 in the core and we solve 
>ambiguity on the incorporation by defining a new mechanism.... with all 
>the problems that this would raise: not alignment with the standard that 
>has faced the issue previously, time consumption in discussions on the 
>concept, writing and discussions of specific proposals, etc.
>
>After our conversation and assessment of the situation, we tend to be 
>more aligned with solution 1 as a way of quickly solve the issues in the 
>core and provide a clean (and complete) solution for the market in the 
>XML signatures arena with our AdES profile, based on a standard solution.
>
>Regards
>
>Nick and Juan Carlos
>
>
>
>---------------------------------------------------------------------
>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
>  
>