[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Incorporation of signature timestamp in XML signatures.
Carlos, I really think that we should stop the discussion on XAdES properties incorporation mechanism after this message: it is time consuming, and we should focus on the issues within DSS scope....so I will reply to your comments here and if you want, we can go on with this in a more adequate context where this type of discussions take place....but let me give a reply to you (in this way we will have two messages each ;-) See intermixed... Carlos González-Cadenas wrote: >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. > > > <jc>My long reaction was caused by your wording : "XAdES INCORPORATION definition for signature properties is **INCOMPATIBLE** with the XMLDSig spec (note the ds: SignatureProperties vs xades:QualifyingProperties approach...)." In my opinion you made a really strong assertion dealing XAdES in general, which I thought that required a quick answer....just for avoiding spreading of the feeling that was in XAdES things forbidden by XMLDSIG.... </jc> >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> > > > > <jc>I was trying to put in clear the trade-off between what would have been great, ie, W3C and OASIS maybe colaborating in the production of a XML time-stamp and what it had to be done then. Let me be clear, I do not oppose at all to that, what I am saying is that I still consider valid to keep XML time-stamp definition in the DSS standards... should the future bring some kind of collaboration with W3C and a re-elaboration of the XML time-stamp I would see it as a great an definitive movement, but this future does not seem to be so near as to fit within our timeframe for the completion. Maybe I did not correctly understand you but it seems that you would prefer not to inlcude this XML time-stamp definition in our standards and push for a colaboration with W3C, looking for the creation of some group for that, etc, etc... my point is that although this colaboration could be good, this is a time-consuming process , and this purported W3C-OASIS joint standard would not be produced within our timeframe... </jc> > >(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> > > > > > > <jc>OK...</jc> > > > >>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> > > > > <jc>Well, I would say that semantics are extremelly important in standards. CAN, MUST and SHOULD determine in the end compliance with standards... and the word "incompatible" has a not "standarized" semantics in the standard arena... and for me it looks like "not permitted by the standard", and that was the reason for my long reply. Now, if you actually do not mean "not permitted", as I understand from your text, as I said, this is a discussion that already had in the group, and of course, we can go on, but in other context, please...the important thing is that by no means as far as people that designed it are aware, XAdES breaks any mandatory rule from XMLDSIG and that XAdES signatures are perfectly good XMLSig signatures. As for what you call "PRACTICAL" incompatibility... I would say that the word "incompatibility" is too strong and does not corresponds with reality: the simple fact is this: XMLSIg gave some container for optional usage. XAdES team decided to define new containers with clear associated semantics, ie, refused to make usage of an optional feature and made usage of another optional feature: define its own elements with their own semantics.</jc> >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> > > > <jc>Not mentioned on purpose: no properties of this type were defined in the standard, just a container for potential future definitions. As I was talking on actually defined properties I did not mentioned the container....</jc> >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...) > > <jc>Well, I would not say that distinction is artificial, and the example of CAdES does not serve at this level, as I will try to point out here. Artificial: not at all, in XML Sig we have one signature, any property qualifying the signature is implicitely related to that signature. On the other hand, XMLSig may sign more than one objects.... now, properties that may individually qualify one of the signed data objects must identify the object they are qualifying... I do not see anything artificial in saying "by signing this document I endorse this commitment and by signing the other I endorse a different commitment"...it is just a possibility that XMLSig puts in our hands..... As for CAdES, I would say that there is a main difference, inherited from CMS: CMS does not has explicit mechanisms for doing what XMLSig does, ie, individually deal with each document it signs: CMS does not incorporate referencing mechanisms for the signed data... so what is signed, from the perspective of CAdES (of CMS actually) is a unity, which only after signature verification is broken if required.... XMLSig allows to break this unity, which puts on our hands the possibility of operating in different ways. I think that XAdES actually did the right thing: make use of XMLSig features....in the end CMS was there when XMLSig was written, if their authors had wanted to do exactly the same things in the same ways as CMS, they would have just "translated" to XML CMS fields and XMLSig would be nowadays very different...the usage of ds:Reference elements actually was a radical shift to the way in which signatures were thought so far...CAdES was designed inheriting CMS behaviour and features, XAdES was designed inheriting mechanisms from XMLSig. As for reinventing the wheel... well, having said that for XAdES team it was important to diferentiate between properties qualifying signatures and properties qualifying the signature, and between signed properties and unsigned properties, it was clear for us that fournew elements incorporating these semantics would be good.... and if you think of names, even here we have followed XMLDSIG naming mechanism: they are SignedSignatureProperties, SignedDataObjectProperies, etc... we were did not think that we were "reinventing the wheel" but puting in place new XML elements for indicating semantics in a more precise way, which is, in the end, what all XML is about...</jc> >*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> > > <jc>So, in the end we are arguing about using xades:SignedSignatureProperties and xades:SignedDataObjectProperties instead ds:SignedProperties? Well, yes, I still REALLY think that it is simpler and clearer to identify which properties qualify signature and which ones qualify signed objects by the reasons I mentioned above...I am not saying that it is not arguable and obviously it is BUT I do not think that it deserves all the time that we are spending within this TC....</jc> > > > > >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 > > > >--------------------------------------------------------------------- >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]