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

[Andrea Caccia <andrea.caccia@studiocaccia.com>]

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.

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.

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

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.

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! 

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… 

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>

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.

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>

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.

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>

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

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

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

Andrea


Il giorno 28/ago/2010, alle ore 03.01, G. Ken Holman ha scritto:
> Tim, my supposition above for the repetition of the <ds:Signature> is that UBL modelling rules require the containing <sig:SignatureGroup> so that that repeating group is not a sibling of the singleton <cbc:ID>.  However, since <ds:Signature> itself is a structure and not a leaf, is it acceptable in all the examples above to remove <sig:SignatureGroup> and make <ds:Signature> a sibling of <cbc:ID>?  I thought it important to make the <ds:Signature> siblings "pure" without other siblings, but removing the <sig:SignatureGroup> would make things a bit simpler.
> 
Now, having a single ds:Signature in each block there is no issue at all

>> This is the most flexible solution and, at the end, it is even less complex than the other approaches that we considered.
> 
> Sorry, Andrea, I've lost track in your message about which one you are referring to above when you say "this".
Please forgive me for this but the need to clear up things often lead to simpler solutions

> 
> I think the example above shows the "scaffolding method" in the current schemas is more compact and less error/trouble prone than the "one signature per UBL extension method" that is being proposed.
> 

Agreed, and I think now also the complexity is minimal