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.
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).
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.
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