Re: [ubl-security] Re: [spam] Re: [ubl-security] Questions regarding the XAdES Profile

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

I wad working on this in parallel to last proposal from Roberto.

This is a simplification in line with the "scaffolding approach": I think we should firstly make a decision if:
1) staying with the old approach with some allowed ways to fit additional requirements by loosening some security feature on exceptional basis
2) staying with the scaffolding approach, possibly simplifying it (an example is hereafter)
3) privilege only flexibility but loosing a lot of security features that I feel can be unacceptable in some circumstances (that we cannot assess in a very short timeframe)

My personal view is to go with 1) and possibly move to 3) (or 2))if we find a sound rationale for it, possibly based on the comments we'll receive in public review.

Andrea


Il giorno 27/ago/2010, alle ore 09.44, Oriol Bausà Peris ha scritto:

> 
> El 26/08/2010, a las 23:06, G. Ken Holman escribió:
> 
>> At 2010-08-26 16:49 -0400, Jon Bosak wrote:
>>> Sorry if this is something that should be obvious to me, but I'm
>>> not understanding the need for multiple signatures on UBL
>>> CertificateOfOrigin.
>> 
>> This sample from Roberto illustrates the multiple signatures on the one form:
>> 
>> http://www.export911.com/e911/export/docFormA.htm#docFormA
> 
> I am sorry but I think the sample from Roberto shows that the CoO is signed by two different people. So it is a single group (using your terminology) of two signatures. They are signing the whole document, not parts of it, so there is not need for identifying which part of the document they are signing.

I'd like to clarify a point here: the signed object is always the whole document. The ID mechanism is just for having a logical association, a sort of pointer between a signature [group] and a part (a section) of the document.
I'd like to add also that I'd like to avoid that this logical association is necessairly to a cac:Signature: I think this element should be always optional and that it should be possible to logically associate a signature to whatever element that has an <cbc:ID>. This way we can be very flexible without having to modify the core syntax for any local legal requirement that has to be met  

Reading the last comments from Roberto it is not clear to me if there is always a single document signature associated to the document, and having the cac:Signature just a reference, or if the document has multiple signature [groups].

I think we can have a simpler structure:

<sig:SignatureInformation> 
 <sig:SignatureGroups> (one or more)
   <cbc:ID> … </cbc:ID> (an optional pointer to a section of the UBL document; if absent it is a generic signature [group] applied to the whole document)
   <sig:SignatureGroup>
     <ds:Signature> … </ds:Signature> (zero or more signatures associated to the same cbc:ID)
   </sig:SignatureGroup>
 </sig:SignatureGroups>
</sig:SignatureInformation> 

At the time first signature has to be added, an example of the required scaffolding is:
<sig:SignatureInformation> 
 <sig:SignatureGroups>
   <sig:SignatureGroup>
   </sig:SignatureGroup>
 </sig:SignatureGroups>

 <sig:SignatureGroups>
   <cbc:ID>CertificateOfOriginApplicationID</cbc:ID>
   <sig:SignatureGroup>
   </sig:SignatureGroup>
 </sig:SignatureGroups>

 <sig:SignatureGroups>
   <cbc:ID>IssuerEndorsementID</cbc:ID>
   <sig:SignatureGroup>
   </sig:SignatureGroup>
 </sig:SignatureGroups>

 <sig:SignatureGroups>
   <cbc:ID>EmbassyEndorsementID</cbc:ID>
   <sig:SignatureGroup>
   </sig:SignatureGroup>
 </sig:SignatureGroups>

 <sig:SignatureGroups>
   <cbc:ID>InsuranceEndorsementID</cbc:ID>
   <sig:SignatureGroup>
   </sig:SignatureGroup>
 </sig:SignatureGroups>

</sig:SignatureInformation> 

Any xxxID content of cbc:ID is just used to clarify for the example purposes what is meant to be associated to the signature[group] in the COO example.
Not all pointers are needed if it is already known in advance that some are not required; in case it is not known in advance if a sig:SignatureGroups element could be present even if, at the end, no ds:signature is really inserted.