Re: [ubl-security] Where to go from here - Final proposal?

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

At 2010-08-30 12:46 +0200, Andrea Caccia wrote:
>Hi Oriol,
>your concerns helped to improve the work of this SC as keeping 
>things simple is a very difficult task.

Indeed, Oriol ... your persistence has helped to make it all better.

Thank you for endorsing in principle the simplified design and the 
use of the NDR rules in naming and structuring.  Any feedback on the 
text of chapter 5 would be very much appreciated.

>About your concern, this come from a requirement that is almost new 
>to me but, to some extent, is covered.
>In fact current implementation:
>- mainly address the case where each signer signs all the document 
>but a mechanism is given, trough the referencing ID, to logically 
>associate the signature to a portion of the UBL document. This is a 
>logical association, whose meaning can be addressed by some legal 
>support (out of our scope) e.g. defining that the signature engages 
>the signer only for the referenced part and granting only origin and 
>integrity for the whole content. An example for this kind of legal 
>support is i.e. for electronic invoicing and qualified signature: 
>even id a qualified signature implies normally non repudiation of 
>the content, the VAT directive defines, by law, that the signature 
>is only granting origin and integrity.
>- on the other hand, I don't want to have mandatory xpath 
>expressions but only recommend them. This can allow the support of 
>any use case, including signing just a pert of the UBL document.

True.  Consider that (I believe) a user could use the following to 
digitally sign a single line item whose ID is '12345', thus allowing 
any of the remainder of the document to change but this signature to 
remain valid:

    <Transform
      Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
     <XPath xmlns:cac="..." xmlns:cbc="...">
       ancestor-or-self::cac:InvoiceLine[cbc:ID='12345']
     </XPath>
    </Transform>

Andrea, have I interpreted the XML digital signature specification correctly?

Should we include this example in Chapter 5?

I don't think adding this example or allowing any other expression is 
prohibited by our use of "should" in the text of section 1.4 in chapter 5.

And in doing so, this has no impact on the current proposal.  There 
just happens not to be a signature business object involved.  The 
signature business object is, in fact, just a business object and not 
a security object.  Perhaps should this fact be underscored in the 
Chapter 5 text?

>I believe there is space to improve our approach to support the case 
>where you have to logically attach signed documents (e.g. 
>certifications) to an UBL document. Those certifications could be 
>part of the UBL document or not (I guess) and we have to fully 
>understand what constraints we can have on the workflows to 
>understand clearly what kind of signature is the most suitable 
>(maybe a detached signature approach is better).

Interesting ... yes, I like this.  If I sign a document that has 
attachments, I would want an assurance the attachments are also unchanged.

Actually, I think we may already be covered here.  Looking at the UBL 
2.1 business objects I note the following.  Look at <cac:Attachment> 
... if the attachment is embedded, it is in scope of the document's 
signature.  If the attachment has the child <cac:ExternalReference>, 
that object has both <cbc:DocumentHash> and 
<cbc:HashAlgorithmMethod>.  Therefore, the hash is in the scope of 
the document's signature.  If the external document changes at all, 
the hash will be invalid and so the external document is not 
signed.  If the (suitably strong) hash calculation found inside of a 
UBL signed document matches the calculation of the hash of the 
externally referenced document, I think one can assume that the 
digital signature has effectively covered the external document.

And one could scope the signing of *only* the attachment and nothing 
else through this XML signature hash transformation expression:

  <Transform
    Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
   <XPath xmlns:cac="..." xmlns:cbc="...">
     ancestor-or-self::cac:ExternalReference[cbc:FileName='Invoice1234OCR.gif']
   </XPath>
  </Transform>

... provided, of course, that aggregate has the hash and algorithm filled in.

This could be a fourth example to include in Chapter 5.

>As there are many options, further discussion is required to find, 
>again, the simplest way to cover the most important requirements and 
>leave open the door for adaptations to the model that can cover 
>possibly all of them.
>
>As no more time is available for PRD1 but, on one hand I think we 
>reached a point that covers our initial requirements and is enough 
>stable and suitable for implementation, on the other hand we found 
>additional requirements worth to be addressed that con complement, 
>not replace, current approach, for which we need more time to find 
>good solutions. I think there is time to work again on the document 
>and improve our approach for PRD2 as, I'm very convinced, will not 
>be a big change on what we already did.
>
>Let me know if this answers, at least in perspective, your concern 
>and if you agree to proceed this way.

I look forward to hear if you have any more concerns, Oriol, 
regarding going to PRD1.  If not, I will create for Jon another SGTG 
release with the updated schemas in time for this evening's Pacific call.

Thank you again for your feedback.

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