Conflicting conformance statements in UBL-XAdES-Profile-1.0-RC2.doc

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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