[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Incorporation of signature timestamp in XML signatures.
Dear All, First of all, thanks Juan Carlos and Nick for the great analysis. As a summary of my position, I think that timestamps are a ***VERY INFRASTRUCTURAL*** thing, and should be taken as a PREREQUISITE for DSS work (DSS is a high-level protocol that builds on several previously-specified things, like XML and CMS signatures). So, I consider that is an error to include timestamp FORMAT and INCORPORATION definitions in the DSS specification. As I said in the conference last day, CMS and XML signatures are asymmetric when dealing about timestamps: CMS signatures, via RFC3161, have standard FORMAT and INCORPORATION definitions. But the problem for XML signatures is not only that there's a lack for a FORMAT and INCORPORATION definition, is also that the XAdES INCORPORATION definition for signature properties is **INCOMPATIBLE** with the XMLDSig spec (note the ds: SignatureProperties vs xades:QualifyingProperties approach...). It's clear for me that a "standardized" definition for a XML timestamp FORMAT and a standardized way of INCORPORATION SHOULD be defined (all the needed technical work for this is almost done in the DSS and XAdES specs). I was very surprised the first time I saw the "pseudo-timestamp definition" in the XMLDSig spec http://www.w3.org/TR/xmldsig-core/#sec-o-SignatureProperty... Closing this issue would be very, very beneficial for everyone... I understand and fully support Juan Carlos and Nick's point, regarding not to block DSS because of these issues, and I propose the following 1) Work in the timestamp spec (I'm offering from now on to help in that work), I mean, recovering and putting together all the work already done... I think not too much work. 2) In parallel (not blocking DSS), contribute this work to the relevant places (you know better than me these places, that is, IETF, W3C, ..., some of them) 3) ASSUME this spec (interim spec for some time) as a prerequisite and align the XML Timestamp wording style in DSS with the one used for CMS timestamps (that assume RFC3161 as a prerequisite). 4) When the spec is published as a standard, change ONLY the references in DSS to point to RFCXXXX/W3C Recommendation (or whatever...). Even the point 1 does not need to be completed to release the new DSS spec version, can be Work-In-Progress. Comments? Kind Regards, Carlos Carlos González-Cadenas Chief Security Officer netfocus Diagonal 188-198 Planta 2 08018 Barcelona tel: 902 303 393 fax: 902 303 394 gonzalezcarlos@netfocus.es www.netfocus.es -----Mensaje original----- De: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] Enviado el: miércoles, 31 de mayo de 2006 18:29 Para: DSS TC List; Juan Carlos Cruellas; Nick Pope Asunto: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]