[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Conflicting conformance statements in UBL-XAdES-Profile-1.0-RC2.doc
Fellow UBL Security SC members, Per my earlier announcement I have created a basic library for adding the necessary UBL scaffolding for a digital signature, and the basic XML digital signature itself. Based on a *lot* of education this morning about XAdES, I will soon design the onion-skin wrappers for this environment so that a user can add their required form of XAdES (or other specification) to a UBL document using my basic library. The ETSI document at: http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf ... eloquently summarizes the implementation of XAdES with this paragraph: "The XML advanced electronic signatures defined in the present document will be built by incorporating to the XML signatures as defined in [3] XMLDSIG one new ds:Object XML element containing the additional qualifying information." So ... the point of my message today ... while reviewing our UBL-XAdES-Profile-1.0-RC2.doc document, I noted a conflicting pair of statements regarding conformance: - line 292 - "A conformant implementation of this profile MUST support XAdES" - line 353 - "It is RECCOMENDED that XAdES extensions are implemented" The title of our document is "UBL Electronic Signature Profile Version 1.0" which doesn't make reference to XAdES, and the scaffolding and use of XML digital signatures alone will be useful to communities who choose alternatives other than XAdES. Section 2.3 underscores that no single XAdES form can be mandated by our specification, and so I think this supports limiting the conformance of our specification solely to scaffolding plus XML digital signatures. Lines 273 through 293 can then be moved to the start of section 2.3 for those readers who need to know about the context of XAdES within the UBL Profile. Of course other edits will be required in order to separate the base specification from that of XAdES. I wondered if we could have "profiles of conformance", but I think it doesn't make sense to have a "conformance to XAdES" when our users have to decide *which* form of XAdES to use. Since XAdES is added to XML digital signatures using mechanisms of XML digital signatures outside of our purview (per the paragraph cited above), we (as a UBL committee) really have nothing to say about XAdES in UBL. By enabling XML digital signatures in UBL as we have done, we have said it all: we have *implicitly* enabled XAdES in UBL. We should explain this in our specification, but I don't think our specification can simultaneously mandate it and make it optional. And I don't think our specification should mandate XAdES because others who use XML digital signatures can use our specification without using XAdES. I hope this is considered helpful. I'd like to offer my assistance in the editing of the text to reflect the above if we agree. . . . . . . . . . Ken -- XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01 Vote for your XML training: http://www.CraneSoftwrights.com/o/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]