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

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

At 2010-08-28 12:23 +0200, Andrea Caccia wrote:
>Trying to summarize the point we are I found a 
>simpler solution that I hope can satisfy all, that is described below.
>I apologize for this late proposal, but I 
>believe it can be the simplest solution for the issues that were raised.

I support the structure in this proposal, but I 
suggest changes to match with the UBL Naming and Design Rules (NDR).

>The idea is to not allow repetition of 
>ds:Signature and just have a single extension 
>with a sequence of signatures, inside a single 
>extension, with each having an optional cbc:ID 
>to associate it to a part of the document, if required.

Sounds good to me!

>Starting from requirements, as Oriol correctly 
>pointed out, these are te ones I tried to 
>satisfy (see also notes at the very end answering to some Ken points):
>- single extension, so no drawbacks of the the 
>"one signature per UBL extension method" 
>(worrisome requirements, no compactness, no white space allowed…)
>- no ambiguity and easy readability on the scope of each signature
>- minimal scaffolding
>- support workflows changes
>- support security/legal requirement of 
>"freezing" everything before the UBL document is transmitted

Also sounds great!

>It can also be a reusable approach for 
>extensions that support an use case that can be 
>named: "how to apply each item of a set of 
>attachments/related data to all or part of an 
>UBL document". But this is out of scope now.

Fine with me.

>The proposed structure, to be inserted in the extension:
>
><sig:UBLSignatures>
>         <sig:SignatureInformation Id="…"> (as 
> many as needed; "Id" is optional to support workflow, see below)
>                 <cbc:ID>…</cbc:ID> (optional)
>                 <ds:Signature> … <ds:Signature> (just one)
>         </sig:SignatureInformation>
></sig:UBLSignatures>
>
>That's all!

Two NDR rules are violated above.  An element 
name cannot be plural, nor can there be 
attributes on the elements (the only attributes 
are unqualified data type supplementary components on BBIEs).

Actually, I take back my first objection ... GNR7 
reads "UBL XML element and type names MUST be in 
singular form unless the concept itself is 
plural.", and in this case indeed the concept 
*is* plural ... noting that below you have a 
different apex element than your example above.

But what to do with the attribute?  I suggest we 
use the following ... note I'm using <cbc:ID> for 
your newly-identified purpose:

<sig:UBLDocumentSignatures>
   <sig:SignatureInformation> (as many as needed)
     <cbc:ID>…</cbc:ID> (optional to support workflow, see below)
     <sig:ReferencedSignatureID>…</sig:ReferencedSignatureID> (optional)
     <ds:Signature> … <ds:Signature> (just one; optional to support locating)
   </sig:SignatureInformation>
</sig:UBLDocumentSignatures>

I chose the name sig:ReferencedSignatureID from 
the existing example cbc:ReferencedConsignmentID in the common library.

Did you consider allowing multiple <ds:Signature> 
elements instead of just one?  I can imagine that 
there would be off-the-shelf signing software 
that would only support a group of signatures as 
sibling <ds:Signature> elements.  But I can 
accept a limit of one if you have already discounted this situation.

>The simplest use case (one document-wide signature) becomes:
>
><sig:UBLDocumentSignatures>
>         <sig:SignatureInformation>
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
></sig:UBLDocumentSignatures>
>It's just one more tag than before…

Agreed.  And no change to my example.

>In case more than a signature is required, the 
>SignatureInformation is just repeated as many times as needed:
><sig:UBLDocumentSignatures>
>         <sig:SignatureInformation Id="firstSig">
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
>         <sig:SignatureInformation Id="secondSig">
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
></sig:UBLDocumentSignatures>

That would become:

<sig:UBLDocumentSignatures>
   <sig:SignatureInformation>
     <cbc:ID>firstSig</cbc:ID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
   <sig:SignatureInformation>
     <cbc:ID>secondSig</cbc:ID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
</sig:UBLDocumentSignatures>

Or without an identifier and only one signature:

<sig:UBLDocumentSignatures>
   <sig:SignatureInformation>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
</sig:UBLDocumentSignatures>

>The Id attribue in SignatureInformation is meant 
>as a hint to instruct signature software to 
>locate quickly where the signature is required.
>It can be deleted if we think it's not useful 
>and it can also be deleted after the document is 
>signed without any problem, or each time the 
>signature software is invoked an Id="SignHere" 
>can be placed where the <ds:Signature> to be 
>inserted or filled-in is placed at that moment.

I think that is a suitable use-case.

>In a complex situation like COO I think readability is preserved:
>
><sig:UBLDocumentSignatures>
>         <sig:SignatureInformation Id="1">
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
>         <sig:SignatureInformation Id="2">
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
>         <sig:SignatureInformation Id="3">
>                 <cbc:ID> CertificateOfOriginApplicationID </cbc:ID>
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
>         <sig:SignatureInformation Id="4">
>                 <cbc:ID> InsuranceEndorsementID </cbc:ID>
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
>         <sig:SignatureInformation Id="5">
>                 <cbc:ID> EmbassyEndorsementID </cbc:ID>
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
>         <sig:SignatureInformation Id="6">
>                 <cbc:ID> EmbassyEndorsementID </cbc:ID>
>                 <ds:Signature> … <ds:Signature>
>         </sig:SignatureInformation>
></sig:UBLDocumentSignatures>

That would become:

<sig:UBLDocumentSignatures>
   <sig:SignatureInformation>
     <cbc:ID>firstSig</cbc:ID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
   <sig:SignatureInformation>
     <cbc:ID>secondSig</cbc:ID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
   <sig:SignatureInformation>
     <cbc:ID>thirdSig</cbc:ID>
     <sig:ReferencedSignatureID>urn:oasis:names:specification:ubl:profile:dsig:signature:CertificateOfOriginApplication</sig:ReferencedSignatureID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
   <sig:SignatureInformation>
     <cbc:ID>fourthSig</cbc:ID>
     <sig:ReferencedSignatureID>urn:oasis:names:specification:ubl:profile:dsig:signature:InsuranceEndorsementID</sig:ReferencedSignatureID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
   <sig:SignatureInformation>
     <cbc:ID>fifthSig</cbc:ID>
     <sig:ReferencedSignatureID>urn:oasis:names:specification:ubl:profile:dsig:signature:EmbassyEndorsementID</sig:ReferencedSignatureID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
   <sig:SignatureInformation>
     <cbc:ID>sixthSig</cbc:ID>
     <sig:ReferencedSignatureID>urn:oasis:names:specification:ubl:profile:dsig:signature:EmbassyEndorsementID</sig:ReferencedSignatureID>
     <ds:Signature> … <ds:Signature>
   </sig:SignatureInformation>
</sig:UBLDocumentSignatures>

>Signatures 1 and 2 are document-wide; signatures 
>3…6 are associated with the part of the UBL 
>document identified by cbc:ID and 5 and 6 are in 
>fact co-signatures as they refers to the same object.
>I believe in most cases we do not need so many 
>signatures, this example is just to show that 
>readability is preserved even in a complex scenario.
>
>Now about xpath: as it was pointed out we need 
>flexibility on the order, number and association 
>of each signature added to the document.
>The proposed xpath is
>
><XPath xmlns:sig="&sig;">
>    count(ancestor-or-self::sig:UBLDocumentSignatures |
>    here()/ancestor::sig:UBLDocumentSignatures[1]) >
>    count(ancestor-or-self::sig:UBLDocumentSignatures)
></Xpath>
>
>so anything in the signature extension can 
>change without any side effect on signature calculation.

Yes, except for the namespace declaration ... it should be:

<XPath xmlns:sig=
     "urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
    count(ancestor-or-self::sig:UBLDocumentSignatures |
    here()/ancestor::sig:UBLDocumentSignatures[1]) >
    count(ancestor-or-self::sig:UBLDocumentSignatures)
</Xpath>

>As an option, it there is the requirement to 
>freeze everything before transmitting the 
>message, ensuring the recipient (and also the 
>sender) that no other signature can be added and 
>no modification to the association between 
>signatures and related business objects can be 
>made, the following xpath can be used by the last signer:
>
><XPath xmlns:dsig="&dsig;">
>    count(ancestor-or-self::dsig:Signature |
>    here()/ancestor::dsig:Signature[1]) >
>    count(ancestor-or-self::dsig:Signature)
></Xpath>

Perfect, except again for the namespace declaration.

>This is a copy&paste from XMLDSIG so it should work.

Well, it won't work in both of your examples 
unless the corresponding general entity is 
declared in the UBL instance and most of our 
users won't be familiar with general parsed 
entities or the use of the internal declaration 
subset.  The following would be more appropriate 
for our users and what should be included in the 
security document (this is an XML rule, not a UBL rule):

<XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#";>
    count(ancestor-or-self::dsig:Signature |
    here()/ancestor::dsig:Signature[1]) >
    count(ancestor-or-self::dsig:Signature)
</Xpath>

Or, equivalently, since elsewhere we use only the 
"ds" prefix, the following because for those who 
do not understand namespaces well we are underscoring it is the same namespace:

<XPath xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
    count(ancestor-or-self::ds:Signature |
    here()/ancestor::ds:Signature[1]) >
    count(ancestor-or-self::ds:Signature)
</Xpath>

>We can eventually recommend to use 
>Id="SealSignature" for this specific signature, 
>but I do not feel its so important.

Agreed ... I think there is an opportunity for 
mismatch if we suggest that, so let's not go there at all.

>That's all: may I ask you for a final opinion on this proposal?

I'm willing to accept the above and I can commit 
to having it changed (if you accept my minor 
tweaks in names) for Jon for Monday morning if 
others can quickly endorse Andrea's suggestion 
with my XML- and UBL-related changes.

Thank you, Andrea, for working on this during the weekend.

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