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

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

At 2010-05-25 03:45 +0200, in 
http://lists.oasis-open.org/archives/ubl-security/201005/msg00013.html 
Andrea Caccia wrote:
>Dear All,
>please find attached the Draft 06 of our profile now titled "UBL 
>Electronic Signature Profile Version 1.0".
>The most important changes are:
>- use of XMLDSig is also supported with specific SRIs
>- reordering of normative/not normative references. Now XPath is not 
>normative so <ds:XPath> is more clearly referred to the specific 
>implementation of XPath found in XMLDSig
>
>Please let me know asap if there is any comment, using the "clean" 
>version as starting point.

Thank you again, Andrea and other SC members for your work on 
this.  Today I'm trying to implement the specification in a set of 
related extension schemas for the PRD1 distribution.

I have the following questions for clarification:

(1) - Lines 430 and 435 - when using this methodology, I gather that 
multiple signatures are instantiated in the extension and that I need 
only a single <cac:Signature> element in the instance itself to 
indicate that *all* XAdES signatures are in that extension ... so, if 
I need two signatures, I still only have one <cac:Signature> element 
and I put the two signatures in the extension
- if this is correct, then I can understand <cbc:ID>UBLDSIG</cbc:ID> 
being a fixed value and that value being a child of the document element
- but in Certificate of Origin there are four <cac:Signature> elements:

   <cac:CertificateOfOrigin>
     <cac:CertificateOfOriginApplication>
       <cac:Signature>  <!--for the document-->
     ...
     <cac:IssuerEndorsement>
       <cac:Signature>  <!--for the endorsement-->
     ...
     <cac:EmbassyEndorsement>
       <cac:Signature>  <!--for the endorsement-->
     ...
     <cac:InsuranceEndorsement>
       <cac:Signature>  <!--for the endorsement-->

- and in the common library, an item can have a signature, and there 
are 21 places where items are used:

   <cac:Item>
     <cac:Certificate>
       <cac:Signature>

... so signatures can be used all over the UBL document.
- does line 430 imply that this Security methodology does *not* apply 
to the endorsements but only to the signatures that apply to the 
entire document?
- shall we explicitly exclude the endorsements (and future 
signatures) so that there isn't a conflict?
- if someone wants to use XAdES for an endorsement and in the future 
writes a methodology for that, is our current choice of "UBLDSIG" too 
ambiguous?  Should it perhaps be "UBLDOCDSIG" or some other value to 
imply this is the signature ID for that block of signatures for the 
entire document?
- (later in the day) - I jut read line 462 and I see that the element 
<odsig:document-signatures> is used, which also implies document-wide 
scope of the signature, which I think supports the decision to 
distinguish the ID as being a "document kind of ID"
- in fact I now believe (after working on this document) that we 
should not use a simple string that is too easily ambiguous with what 
users might inadvertently use (yes, I know "UBL" is not common, but 
why use an ad hoc identification scheme when there is one we can use) 
and select two URNs for the values on lines 430 and 435, and the 
values along the lines of:

  <cac:Signature>
    <cbc:ID>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature</cbc:ID>
    [...]
    <cbc:SignatureMethod>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/xades-enveloped</cbc:SignatureMethod>
    <cac:SignatoryParty>
      <cac:PartyIdentification>
        <cbc:ID>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature-defined</cbc:ID>
      </cac:PartyIdentification>
    </cac:SignatoryParty>
    [...]
  </cac:Signature>

(2) - do you believe the definition on UBL 2.1 Common Library row 225 
incorrect?  it states it is a signature applied to the document 
instance, but its placement implies it is a signature applied only to 
the certificate
- if you agree it is wrong, then Jon this goes onto the list of 
definitions to be repaired

(3) - I note that only 54 documents allow <cac:Signature> as a child 
of the document element, and Certificate Of Origin has the 
document-wide signature in a grandchild of the document element ... 
do we need to add for PRD2 a <cac:Signature> child of the document 
element to the other 5 documents that do not have this today?
- my thought is "yes, every UBL document must have a <cac:Signature> 
*somewhere* to apply to the entire document scope, and from now on it 
must be a child of the document element (so that CoO is the one and 
only UBL document that doesn't have it as a child)"
- the five documents with a missing cac:Signature as a child of the 
document element are:
   CallForTenders
   CatalogueRequest
   ContractAwardNotice
   ContractNotice
   PriorInformationNotice

(4) - line 462 makes reference to the namespace prefix "odsig", which 
is cited as bibliographic entry "ODFP", but that entry starting on 
line 222 cites the UBL specification on line 224 ... what citation 
should be here?

(5) - line 469 "and their content" -> "and their content and any 
white-space between or around them"

(6) - line 473 "whole UBL document" -> "whole UBL document (as 
indicated by the empty attribute value)"
- I suggest this change because until I looked at the example, I 
thought that I had to fill in the attribute with a value ... it was 
only later that I realized the empty attribute has meaning ... so at 
this point I felt it important to say that the attribute must, in 
fact, be empty

(7) - line 474 does not mention the Algorithm= attribute and I think 
it should (since you've talked about attributes elsewhere in the prose)

(8) - line 498 - I cannot correlate where in the prose the content of 
this line is specified

(9) - line 502:  I still *strongly* disagree with labelling the XPath 
address you have on lines 504-506 with the XPath Recommendation URI 
because the "here()" function is *not* part of XPath ... but you've 
seen my other posts about this ... I will try later today to find 
another example of a signature application that uses this combination 
of address and URI ... it just seems so *wrong* to me (but perhaps 
because I was the founding chairman of the XSLT/XPath Conformance 
Committee and no-one else is going to care, so it could just be me 
and I accept that ... I'll just keep looking for justification *not* 
to use it as you have)

(10) - line 502: you are missing an end quote on the attribute specification

(11) - line 511 - I cannot correlate where in the prose the content 
of this line is specified

(12) - lines 517/518 - these lines should be an informative note and 
not flowed as if it were normative ... and they aren't correct either 
... the content of an extension may, in fact, be validated (which is 
what I'm trying to do with the extension schema)

(13) - lines 525-528 - are these the lines that define the content of 
lines 498 and 511?
- if so, how is it that this specification can specify a particular 
<ds:Reference> element?
- is the <ds:Reference> element mandatory (if so, then I have to put 
it into the extension schema) for all uses of <ds:Signature>?

(14) - typo on line 475 - should be "RECOMMENDED"

(15) - line 444 - this element in the example has white-space around 
the URI ... I think this white-space has to be removed because 
white-space is not part of the URI (see my example above)

Thank you for your help with these questions.  Meanwhile, I will 
write the first draft of the extension schema assuming (if I can in 
the limits of XSD) lines 485-516, where lines 498 and 511 are wild 
cards for any content and <ds:Reference> is mandatory (perhaps in XSD 
I cannot mix mandatory and any, I'll check this out).

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