Re: [ubl-security] Re: [ubl] Re: Making references

[JAVEST by Roberto Cisternino <roberto@javest.com>]

Hi Ken,

---
G. Ken Holman ha scritto:

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">At 2009-12-01 19:57 +0100, JAVEST by Roberto Cisternino wrote:

I see, but please try to see this case from the other side:
1) The creator of the extension assignes a unique ID within extensions
2) the ds:signature content is located into ext:ExtensionContent
3) The creator of the extension copies the above ID in the cac:Signature/cbc:ID as a valid Signature identifier

Thus, not the opposite process, in fact it seems correct to create the signature instance first and after the reference.

Fine ... but there is a mismatch between the two identifiers by their definition.

The definition of ext:UBLExtension/cbc:ID is:

  "An identifier for the Extension assigned by the creator of the extension."

The definition of cac:Signature/cbc:ID is:

  "An identifier for the Signature"

If the user doesn't use the information UBL correctly, I don't see that we have to support incorrect use of the defined semantics.  A user can use *any* UBL information item incorrectly and it is not up to us to prevent it.

Anyway, sig:Signature/ds:Signature is mandatory.  If we make sig:Signature/cbc:ID also mandatory then the user won't misplace the information and it will end up always in the correct location.

Starting wih the creation of the extension there is no change of meaning and both the IDs meaning are respected.

I disagree.  ext:UBLExtension/cbc:ID means the identity of the extension, not the identity of the signature.

And, if my suggestion to go with one extension point for multiple signatures is considered useful by the SC, then users couldn't abuse the extension identifier or want to abuse the extension identifier because it is obvious it cannot be associated with more than one signature.

About schema validation I think this is something for the 2nd value validation step (schematron/xslt) and not for the structure.

I disagree.  A mandatory identifier is a matter of syntax.

mandatory is just the cac:Signature ID in case the aggregate is instantiated.
And this ID can be validated by the XSD, but it is not sufficient.

The extension is abstract... I do not want its ID to be mandatory at all, I just want use the extension to envelop the signature which is in another namespace and the cac:Signature is meant to specify where the signature instance is located.

I really preferred xpointer because it was perfect to be used as an URI and there is no need to have a support by XML engines because the developer can just extract the xpath to query the signature nodes.  The best should if XPath could be used as an URI directly...

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">
I do agree that a *matching* identifier is a business rule.  A business rule can check that for every one or more cac:Signature/cbc:ID values there exists a single matching sig:Signature/cbc:ID value.  But the presence of a mandatory sig:Signature/cbc:ID identifier associated with the sig:Signature/ds:Signature signature is not a business rule but an information completeness rule.  Without it the information is not completely expressed, let alone completely consistent.

But UBLExtensions are not only signatures and their ID cannot be mandatory at all... I think this is just a profile, exaclty what the guide for signatures is.   The guide is to recommend how the UBL document must be used with a signature in a consistent way.

If we add a specific container sig:Signature we have the possibility to have a mandatory ID... but the ext:ExtensionContent is not validated at all... as it is meant to be used with any namespace.

So how we can validate a new mandatory sig:Signature/cbc:ID ?

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">

Is optional like most of UBL IDs because it is up to profiles to decide which constraints are required... and subsetting or restrictions are not mandatory as we could just provide a value validation using Schematron in order to check such ID references (aka: business rules cross-references)

My understanding of the requirement would indicate that *all* profiles for signatures would mandate the associated identifier (especially because of the lexical space of values).  If *all* profiles must make it mandatory, then it must never be optional and doesn't sound to me like a profile issue at all.

This is a unique profile that talk about just the relationship between an UBL document and a generic enveloped signature. It is just to recommend a unique consistent way to express enveloped signatures with UBL.  Specific e-Signature profiles available from bodies like ETSI are out of scope here because the ds:* namespace provides the signer to use every part of XAdES.

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">
But that is beside my main point is that the established UBL meaning cannot be co-opted by the security SC through edict or practice.

I do not want to make the ID mandatory in the schema at all... this is a business rule between two parts on the same document.

I mean the ID of the extension... extension are useful because are free and generic.

The reference from cac:Signature is just to be used by software to locate the signature instance when provided inside the UBL Extension (enveloped signature use case)

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">Then I am confused.  I understood the *existence* of the ID was mandatory, thus making it a schema constraint.  You say "between two parts on the same document" and that, to me, is a value constraint and not an existence constraint.  And I totally agree that a value constraint is a business rule and not a schema rule.

The existance of the cac:Signature/cbc:ID is mandatory if a signature is referenced.  We can have detached, enveloped or enveloping signatures.   When the signature instance is enveloped we need to show its location in the best way we have.

If the UBL document is expected to contain a signature and the signature cannot be found the document is not valid at all... and this is without XSD or Schematron validations...
This is the third validation step, or if you prefere, the 1st.

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">
At today's UBL TC meeting I suggested that UBL 2.1 be published with the optional signature extension point schema pre-packaged and ready to use out-of-the-box.  Especially if it meets legal and technical requirements for governments today.  And it will illustrate a completely thought out extension development, and give UBL users an example to follow in their own extension development.

I appreciate the effort but I think that if we do not move faster we will loose the train...

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">
But we need more people on the Security SC to express their opinions on this issue.  It would seem that Roberto and I are at an impasse and we need other perspectives on the issue.

And if my suggestion to have multiple sig:Signature elements inside of the top-level sig:Signatures element, then this confusion for improperly using the extension identifier disappears.

Would other members please express their assessment of the situation?

Thanks!

And thank you for your patience with me, Roberto, as I feel strongly the UBL TC is making some exemplary precedents with the decisions we make on this issue.  I feel we cannot be seen to be breaking our own established rules.

I agree 200% let's find the best road, but we need to provide concrete solutions.
5th December we had the possibility to see UBL and XAdES as a recognized signed document by the Italian P.A..... I am pretty sure we have just lost this.

Actually in Italy only PDF/A and EDIFact are approved...

Instead of UBL there will be an Italian XML format for the Invoice, including the XAdES signature and guidelines to start their adoption.
UBL will be supported maybe later, maybe, and I have lost my time since 2006....................................

7.0.1.0.2.20091201155241.02508030@wheresmymailserver.com" type="cite">
. . . . . . . . . . . . . Ken

--
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com 
Versione: 8.5.426 / Database dei virus: 270.14.88/2538 -  Data di rilascio: 12/01/09 07:59:00

  

--

JAVEST by Roberto Cisternino

* Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor

Roberto Cisternino

mobile: +39 328 2148123
skype: roberto.cisternino.ubl-itlsc
[UBL Technical Committee]	http://www.oasis-open.org/committees/ubl
[UBL Online Community]	http://ubl.xml.org
[UBL International Conferences]	http://www.ublconference.org
[UBL Italian Localization Subcommittee]	http://www.oasis-open.org/committees/ubl-itlsc
[Iniziativa divulgativa UBL Italia]	http://www.ubl-italia.org

PPlease consider the environment before printing this email.