Re: Re: [ubl-security] UBL-XAdES-Profile 1.0-RC1

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

At 2010-08-13 15:35 +0200, Roberto Cisternino wrote:
>We originally avoided binding the URI to a specific version of UBL because
>this methodology could be used with UBL 2.0 and later versions.
>
>I also would like to enphatise that this URI should be clearly represent a
>a profile for digital signatures with UBL.
>
>So the actual URI is in some way assciated to the above concept.
>
>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature
>
>But the new URI is too generic:
>
>http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/signature-defined
>
>I agree that pointing to a permanent location is valuable, so as UBL 2.1
>is a minor version I think the UBL-2.1 root is fine but the URI should be
>revised to meet the original intentions.
>
>For instance:
>
>http://docs.oasis-open.org/ubl/os-UBL-2.1/etc/profiles/dsig/signature-defined

What your message, Roberto, has brought to light 
in your very first sentence is that of course the 
current extension and methodology would work just 
fine with a UBL 2.0 instance ... which now makes 
me uncomfortable with labeling it UBL 2.1.

And add to that the need highlighted this morning 
of identifying the ordinal signature number in the party identifier:

At 2010-08-13 08:38 +0200, Andrea Caccia wrote:
>So we can have also
>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/ubldsig/N 
>(where N=1, 2, … ) instead of UBLDSIG or 
>UBLDOCDSIG to identify the document signatures? 
>But are we following the UBL common practices here?

Well, what we have done before in UBL for URI 
strings (e.g. namespaces) is use URN values, not URL values.

At 2010-08-13 08:38 +0200, Andrea Caccia wrote:
>We can try to change current assumption that 
>there is only a single cac:Signature and I propose the following:
>- there is a 1:1 mapping between cac:Signature 
>elements and UBLextension elements containing signatures
>- we add a <cbc:ID> optional element inside 
><ublsig:document-signatures 
>xmlns:ublsig="urn:X-figure-this-out-later"> (as 
>you proposed in another mail in place of 
><odsig:document-signatures>). This new element 
>MAY be present if there is a cac:Signature and, 
>if present, MUST be set equal to the cbc:ID in 
>the corresponding cac:Signature. I see here a 
>good reason to have a new schema defined. I have 
>indeed a little preference for 
><ublsig:signatures> as it is the most used signature container wrapper.
>- if there is more than one cac:Signature in the 
>UBL document, each MUST have a <cbc:ID> that 
>maps to <cbc:ID> element inside 
><ublsig:document-signatures> that MUST be 
>present too. So, in case a single signature is 
>present as in most cases, the cac:Signature is 
>optional and everything is as it is now.
>- for detached signatures I propose to have them 
>applicable only to the whole document as it is now

I agree with all the above.

So, consider the following:

(1) - the UBL TC defines a URN for the profile 
which is used for both the signature method and the extension identification:

    urn:oasis:names:specification:ubl:profile:dsig:signature

(2) - the UBL TC defines a URN for the document signatures:

    urn:oasis:names:specification:ubl:signatures

(3) - we standardize the convention that, when 
known a priori, the ordinal signature number is 
reflected in the URI as a suffix in order to 
uniquely identify which digital signature is 
associated with which cac:SignatoryParty:

    urn:oasis:names:specification:ubl:signatures:1

- this will be important in the example where we 
have four signatures in the document and we need 
to correlate that the first signatory party is the third signature
- note this ordinal suffix must be optional and 
not mandatory, because as signatories add their 
signature to the signature block, there is no way 
to go back in to the XML document and cite the 
particular ordinal number in the <cbc:ID> because 
that changes the document that was signed by prior signatories
- so, we document the convention so that if a 
processing system knows ahead of adding any 
signatures what the order of the signatories will 
be, then it adds the ":n" suffix, but if it must 
complete the document before any of the 
signatories adds their digital signature, then it 
cannot use the ":n" suffix because there is no 
guarantee that the signatures will be injected in the correct order
- this means if there is only one signatory, the 
suffix can either be absent or ":1"


I am now proceeding to make the UBL 2.1 PRD1 
Release Candidate 2 schemas ... if anyone reads 
this right away and has any major concerns, 
please voice them immediately.  But don't worry 
if the timing isn't right, we can change things for PRD2.

I've attached a ZIP file with a signed example 
reflecting the above (I hope!) and schema 
fragments that I will put into the release 
candidate later today ... and you can see that it 
validates by two W3C Schema processors:

~/u/UBL/UBL2.1/sig $ w3cschema xsd/maindoc/UBL-Invoice-2.1.xsd sigtest.xml
Xerces...
Attempting validating, namespace-aware parse
Parse succeeded (0.877) with no errors and no warnings.
Saxon...
No validation errors
~/u/UBL/UBL2.1/sig $

Oriol, are you in a position to remove from the 
example the faux-signature and replace it with a 
bona-fide signature and test it?

Please advise of any recommended changes.  Thank 
you for your patience with me while I wrestle 
through these issues in short order under the pressure of PRD1.

. . . . . . . . . . . . Ken

gkholman-sigtest-20100813-1710z.zip

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