[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Incorporation of signature timestamp in XML signatures.
Juan Carlos, My real interest was to deal about XML timestamps and their incorporation of signatures, but, due to the content of your response, I am forced to enter also in the XAdES arena. 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: jueves, 01 de junio de 2006 13:20 Para: gonzalezcarlos@netfocus.es CC: 'DSS TC List'; 'Juan Carlos Cruellas'; 'Nick Pope' Asunto: Re: [dss] Incorporation of signature timestamp in XML signatures. Hi, See my replies intermixed... Carlos González-Cadenas wrote: >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. > > First of all, as for the XML time-stamp format inclusion, I will make a mention to the history of this TC: by when this committee was created, XMLSig was finished and the W3C group almost to be disbanded if not already (I do not remember very well)...the important issue was that it was pretty clear by that time that there was no XML time-stamp format and there was not any foreseen initiative to do the work. This made that this aspect would be in the charter since the very beginning. It was not so extrange: there was a lack for a standard protocol for requesting generation and verificaiton of signatures usable in Web services context, time-stamps were relevant for the signatures, there was not a XML format for time-stamp and there were people eagerly wanting to work in those areas.... I admit that one could say that in his opinion certain types of standards should be done by one body and other type should be done by others, or even in co-operation.... and this would work in a perfect world with plente of time, resources etc... but enginnering usually deals with non perfet things, and at that moment I would say that it *****WAS NOT ONLY AN ERROR BUT A SENSIBLE CHOICE**** <cg> I have understood (please correct me if I'm wrong) that the purpose of this thread was to clarify what to do NOW (not several years ago) with signature timestamps in the core. In that direction, I don't see that DSS, Digital Signature Service, is the best place to finally include a timestamp format/placement definition. I acknowledge that DSS could be used as a "driver" for pushing this XML timestamp issues. BTW, I didn't say that including timestamps in the DSS charter was an error (please look at my text), but that keeping timestamp definitions is IMHO an error. I'm not here to judge other's actions, but to contribute to the work of the TC. My proposal was to use the information about timestamps and their incorporation already produced in the several standards available (DSS in the format, XAdES in the incorporation) to create a XML timestamp standard (I don't see any strange in that). IMHO this is the solution that makes more sense, and was asking you at least to evaluate if this would be interesting and, after that, if it would be possible (most of you have been involved in the standardization arena since many years). Sincerely, Juan Carlos, I don't know where you want to go with the "engineering in a perfect world" diatribe... and, sorry, but I'm not going to follow you on that. </cg> (for giving the same emphasis that Carlos gives to his assertion) to include in the charter the time-stamp issue. <cg> Emphasis was on the very infrastructural thing, not in the error. </cg> >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...). > > > As Carlos may anticipate I firmly and strongly disagree with his assertion.... I am affraid that I must now give a reply longer than I would like to do in this thread, as this is not by far a crucial issue for this committee but once the assertion has been done, I can not avoid to put my hat of one of the authors of XAdES spec and give a reply, expecting that this discussion will not go further in this thread... certainly there are other places and better occasions for doing that... Carlos says that the incorporation mechanisms defined in XAdES is incompatible with XMLSig....From my point of view for something to be incompatible with any standard that has to be explicitly forbidden. Let us examine the XMLSig standard:ç ds:SignatureProperties. XMLSig literally says: "Additional information items concerning the generation of the signature(s) can be placed in a SignaturePropety element (i.e. date/time stamp or the serial number of cryptographic hardware used in signature generation)". I do not see any MUST anywhere ... I do not see even a SHOULD, only a CAN. Conclusion is clear: this is an optional feature that by no means forbids usage of other ways of incorporating qualifying properties in a different way. I have mentioned the SHOULD intentionally: if they would have put a SHOULD instead a can, then XAdES would have need to explicitly justify why puts the time-stamp within QualifyingProperties within a ds:Object....but the fact is that they did not put...I do not think that authors with so much experience in standards production would make it unpurportedly: they put CAN because they wanted to do it, and they were perfectly aware of what they were doing...so, under no perspective is the incorporation decided in XAdES incompatible.... <cg> Agree totally. My wording is not correct, it should say: "the XAdES INCORPORATION definition for signature properties is **INCOMPATIBLE** with XMLDSig's one". I mean, if there's a place to handle signature properties, why invent another?. There should be strong reasons to do that, but I will get on that below. My intention was not to enter into semantic discussions about MUST, MAY or CAN in XMLDSig spec, but to see the "PRACTICAL" incompatibility between these two. </cg> I admit that somebody could think that XAdES should have used ds:SignatureProperties for incorporation.... this is a perfectly valid discussion, that we had in the group that designed XAdES... and it was not the one selected because, XAdES defines three types of properties: properties qualifying signatures and covered by the signature, properties qualifying signatures but not covered by the signature and properties qualifying objects covered by the signature. <cg> Four types, as far as I remember, the "UnsignedDataObjectProperties" is the fourth. </cg> Now, a clean usage of ds:SignatureProperties would have implied to have one ds:SignatureProperties element with two children, one for signed and one for unsigned, and in addition to have a ds:Object with the properties qualifying the signed objects...result: two ds:Reference elements for signing properties, distribution of properties in two different elements....we decided to incorporate everything in an element clearly indicating that this was the place for XAdES properties for giving a more compact solution. Again, people may think that it would have been better to use ds:SignatureProperties, <cg> Sincerely, Juan Carlos, I don't think that this rationale justifies to "reinvent the wheel". Let me elaborate *Normally you want two holders for properties, signed ones and unsigned ones (I think the separation between "dataobject" and "signature" is ok semantically, but not necessary at all (in my opinion artificial)... we can generate AdES signatures with CAdES without getting so far and dividing the properties in "sub-boxes" depending whether they qualify the signature or the dataobject, only signed and unsigned...) *The solution for that is very easy (unless I'm missing some crucial point): one ds:Object, two ds:SignedProperties inside (one for signed ones and one for unsigned ones), and a reference established to the ds:SignedProperties containing the signed ones. Please, do you REALLY think that this is not a simpler (and even cleaner) solution?. </cg> but what IMHO people can not say is that this is incompatible with XMLSig.... <cg> Agree on that, explained above. </cg> Ah, BTW, XAdES v1.1.1 was submitted to W3C as a Note, and you may find in the W3C website, it was reviewed by people very active in XMLSig: NO MENTION WAS MADE TO THIS PURPORTED INCOMPATIBILITY. Successive versions of XAdES have been submmitted to XMLSig list, and we have got some comments: I do not remember having got a comment suggesting the usage of SignatureProperties, and of course, nobody from that group has said at all that what was done in XAdES was incompatible with XMLSig... BTW, just as a final remark: one of the other authors of XMLSig was Gregor Karlinger: and he was very active by that time in XMLSig group.... >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 was not a member of the XMLSig group, but looking to the standard, I would say that their objective was to give a basic format for digital signatures in XML, put in there mechanisms for extensibility and give advice but also a high degree of freedom for ulterior developments based on that standard. My opinion as a person that was out of the group was that if they did not work more on the time-stamp issue was because they did not want as a group to do that... and we do not know the reasons for that... we only know that some time later some people felt the need to do that and found in OASIS a place for doing it.... I could agree that a joint effort OASIS / W3C would have been great.... but we all know that there are lots of things to be taken into account and arranged before such initiatives come true, and that most of times they do not depend at all on us, poor techician people, but on mangement people.... >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. > > > I do not understand what you mean by that...are you suggesting changing the format of the XML time-stamp? <cg> Why change the format of the timestamp?. I'm only trying to find the best place to put the work on XML timestamps that's already done. </cg> >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) > > > I do not discard this but I am affraid that we have two main obstacles for achieving more than an expression of interest: our own timeframe and the resources required by the final estabilization of our standards. <cg> Agree, and that's because I'm proposing to do it in parallel (or maybe in the future). </cg> >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 > > > > > --------------------------------------------------------------------- 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]