Re: [ubl-security] New draft (UBL-XAdES-Profile 1.0-20100321)

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

Hi folks.

Please forgive my tardy response over the holiday 
week and weekend and my earlier overseas travel.

At 2010-04-06 00:35 +0200, Andrea Caccia wrote:
>I try to summarize, so I am able to update the draft:
>- for enveloper signatures, there are will be 2 
>RECOMMENDED places for the URI defined by this SC:
>- in cac:Signature/cbc:SignatureMethod , and
>- in ext:UBLExtensions/ext:UBLExtension/ExtensionURI

Sounds fine so far I suppose.  The definition for 
ExtensionURI is simply "A URI for the extension", 
which doesn't say a lot.  I can accept that the 
purpose of the extension is identified uniquely 
by a URI.  The ExtensionVersionID would then help 
in the interpretation of the extension defined by 
the URI.  If there are different implementations 
of the same kind of URI then the version would be used to distinguish them.

Would this mean you should have 
ExtensionVersionID equal to, say "1.0" or, if absent, be assumed to be "1.0"?

>at least one MUST be present. If both are 
>present and not equal the verification fails.

But what if there is another UBLExtension with a 
different ExtensionURI for a different 
purpose?  Would the above rule trigger?  How 
would you avoid triggering the above rule?

Say I have an extension for Crane's timesheets, 
and an extension for a signature with an absent ExtensionURI.

Should the rule perhaps be:  the ExtensionURI is 
omissible if there are no other extensions in the 
instance, but if there are other extensions it is mandatory.

>- for detached signatures cac:Signature/cbc:SignatureMethod MUST be present
>- for enveloped signatures 
>ext:UBLExtensions/ext:UBLExtension/ext:ExtensionReasonCode 
>MAY contain an identifier for the purpose of the 
>signature. A code list qualified with 
>attributes: agency, version… --> I ask Roberto to provide some text here

Good.  We will include that in the special-purpose directory.

>I'm expecting also some comments from Ken

The last version I have is labeled "XAdES-Profile 1.0-20100321-ob.doc".

>and the correct xpath from Juan Carlos,

I see a reference to XPath on line 441, but I'm 
not sure what it is supposed to be pointing 
to.  I think there is an assumption to something 
the reader must know in advance to reading this 
specification.  The wording is "applying a single 
transformation" and I don't know what that means in this context.

Line 447 should read <ext:ExtensionURI> and not <ExtensionURI>

Line 420: Why is ext:UBLExtension/cbc:ID 
mandatory?  It has no semantic other than 
uniquely identifying one extension from 
another.  It has no persistence nor outside referential integrity.

Line 435 makes reference to "the root of the UBL 
document instance".  This should be reworded.  Do 
you mean that cac:Signature must be a child of 
the doucment element (the "document element" is 
the top-most element that wraps all content)?  I 
see that is true for 29 of the 31 document types 
(not for CatalogueRequest nor 
CertificateOfOrigin).  I also see there are 
signatures allowed in <cac:Endorsement> and 
<cac:CertificateOfOriginApplication> ... does the 
methodology exclude using those?

Line 474 states there can only be a single UBL 
extension in the document ... what if I have my 
Crane timesheet extension as well in the 
document.  Am I not allowed to sign that?  Could 
this be relaxed stating that one of the UBL 
extensions must be the signature extension?

The declaration restriction for lines 479 are 
arbitrary and not controllable.  From an XML 
processing perspective, there is no difference if 
the namespace is declared there or in the 
document element of the UBL instance.  For 
example, the DOM, SAX and XSLT/XQuery/XPath data 
models for XML are all equivalent, regardless of 
where the declaration exists.  Can you explain 
why you think it is mandatory to be embedded in the document?

BTW, you should change all uses of the word 
"root" if you mean the "document element" of the 
instance if that is what you mean.  And if that 
is not what you mean, then you need to use different words again.

I see a reference to XPath on line 483, and I 
think an improved XPath address would be as follows:

  /*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/odsig:digital-signatures

... because "//" should be avoided and the above 
is unambiguously the only place where the extension content is found.

Line 498:  if there are two signatures, is it 
acceptable that both have the same ID?  The 
typical semantic for an identifier is that it be 
unique.  Unless you have a reason to specify the 
value, can it not just be left up to the 
user?  It is meant to distinguish between 
signatures, not meant to identify the kind of 
signature.  The definition reads "An identifier 
for the Signature" ... thus it is meant to 
distinguish the signature, not the signature method.

Line 504:  again, I believe you cannot fix the ID 
value to any string at all.  I believe it is 
meant in this case to distinguish the party, not 
distinguish a property of the party.  If I had 
two signatories, they cannot (should not) have the same identifier.

I see line 559 indicates the party identification 
is being used as a modifier and not as an identifier.

For example, if there are two signatures by the 
same person, the signature <cbc:ID> values would 
be distinct and the PartyIdentification <cbc:ID> 
values would be the same.  If there are two 
signatures by two different people, the 
PartyIdentification cbc:ID values would be different.

To back up my assertion about these cbc:ID 
values, consider the CCTS definition of the IdentifierType used for cbc:ID in:

http://docs.oasis-open.org/ubl/os-UBL-2.0-update/xsd/common/UnqualifiedDataTypeSchemaModule-2.0.xsd

and you'll see:

   A character string to identify and distinguish uniquely,
   one instance of an object in an identification scheme from
   all other objects in the same scheme together with
   relevant supplementary information.

Thus, I feel you should not be fixing any cbc:ID 
value in the specification and different cbc:ID 
values will be decided on by the user (not the 
specification) when there are multiple signatures.

I hope these comments are considered helpful.  As 
an outsider unfamiliar with digital signatures, 
I'm not confident the document as it stands would 
direct me to properly implement the given 
schemes.  I'm not sure if a diagram or two would 
help or not.  If pre-awareness of the signature 
specifications is a requirement to understand how 
this specification works, that should be made more clear.

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

--
XSLT/XQuery training:         San Carlos, California 2010-04-26/30
Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03
XSLT/XQuery training:                 Ottawa, Canada 2010-05-10/14
XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11
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