[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]