OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-security] New draft for the UBL XAdES profile


Hi Oriol,
I'd like firstly to thank you for your valuable contribution.
See below inline within your email for specific comments, and hereafter a change proposal to take into account your suggestions.

I think it's agreed that we need to be very flexible in terms of allowing parallel signatures (called also co-signatures) and countersignatures within the context of UBL documents.

Having though more, I found out 2 main points we should work on:
1) I get convinced that the constraints I introduced in my last proposal (for the preparation phase) can become too heavy and difficult to implement in many real situations.
I'm thinking e.g. to workflow management, where the number of signers could depend on the type of message or on some quantity inside the document (e.g. an amount of money that a signer is allowed to authorize that, if exceeded requires that a second signature is put on the document). In these situations it can become very tricky to know in advance all required information to implement correctly the procedure.
2) now there is a 1:1 relationship between the signature reference in the UBL document (cac:Signature) and the "real" digital signature in the UBL extension. This is useful to add some metadata (nside cac:Signature) that can be parsed by the UBL tools. 
But I believe it is not really required in most real world situations, as:
- it is required to verify the signature before trusting the cac:Signature information. But after the verification process it's likely you already have available all the identification information you really need and as certified by the issuer of the certificate.
- if some of the information is part of the "core business" of the management of the document, it's better to find a place for this information in the "core" UBL document

Tacking this into account I propose that:
- only a single cac:Signature is used, independently from the number of digital signatures required, where the only mandatory element is the URI identifying the profile (and <cbc:ID /> optional as specified above). This is more coherent with what is specified for the detached specification profile;
- all the signature are combined within a <dsig:document-signatures> <ds:Signature /><ds:Signature /> . . . </dsig:document-signatures>;
- only a single extension is allowed to contain <dsig:document-signatures /> tag within a single UBL document extension. This way it is always possible for a verification application to find where is located the signature. To ease the location process it could be allowed to set an <cbc:ID /> within the UBL extension and a corresponding and matching <cbc:ID /> inside <cac:Signature />.
- in order to avoid any integrity problem adding (co)signatures and countersignatures, an XPATH like "not(ancestor-or-self::dsig:document-signatures) " being dsig: the namespace urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0 defined in http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-dsig-schema-v1.2-cd1.rng required to have a container of an arbitrary number of <ds:Signature /> defined for Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 3 Packages and referenced in Appendix A.
Please I need someone checking this xpath as I'm not an expert on this.

Best regards
Andrea


Il giorno 15/mar/2010, alle ore 19.37, Oriol Bausą Peris ha scritto:

> Hi Andrea and all, 
> 
> We've been trying to use digital signatures within CODICE project using the guidelines defined in the UBL SSC report, and there are some issues that I think are not covered with the current document:
> 
> Let me explain what are our requirements and some of the issues and proposals for consideration:
> 
> - We need to use sequential signature (countersignature) and parallel signature (cosignature) including all signatories in the same document.
> - We need to use technologies and standards with supporting tools, just to increase the level of adoption of the use of signatures
> 
> Here there are some comments on the document UBL XAdES Profile Version 1.0, (march 2010) 
> 
> 1) cac:signature/cbc:ID, is updated before placing the signature, and ext:UBLExtension/cbc:ID after placing the signature, so the integrity of this relationship is not ensured. It seems that maintaining the element cac:Signature related with the extension is not appropriate. 
The idea is to put both cac:signature/cbc:ID and ext:UBLExtension/cbc:ID in the documents before any signature is inserted, so there should not be the problem you mention. In any case now the proposal is quite different and, moreover hopefully more clear.

> 
> We think that it is interesting to use the cac:Signature as meta information about the signatory party, but it should be totally unlinked to the electronic signature. The point is that the UBL Signature element creates confusion and makes it hard to create and signatures. That's why I would recommend not using the cac:Signature element from the UBL library, using ds:Signature instead.
> 
> 2) There is an idea to create the structures cac:Signature and ext:UBLExtension (as many as signatures required) prior to create the signature.
> 
> It is ok under our point of view (except for point 1 above), but in this case you need to know the number of signatory parties before-hand, and prepare as many ext:UBLExtension components as signatures before creating the signatures, as the "Substract" clause from the filter just excludes the element ds:Signature.
With the new proposal any issue should be solved

> 
> 3) Regarding the use of the transformation XPath Filter, we consider that this is a limitation for the existing technical tools. We should allow for the use of REC_xpath (dsig:XPath). It would be great to avoid this kind of transformations but it seems no possible)
Same as above

> 
> 4) Finally, we think that we could use the same document to sign without using XAdEs, I mean just using XML Dsig.
You mean that we should allow xmldsig when the URI of this SC profile is specified in cac:Signature? Or to add a specific one?
We have also to consider if proposing to TC to change the title of the profile to a less specific one as XAdES is mentioned there.

> 
> 
> Some proposals for consideration:
> 
> 
> 1) Remove any relationship from cac:Signature  to the electronic signature as we cannot guarantee the integrity of the relationship. And avoid promoting the cac:Signature as a placeholder for the signature in UBL documents.
> 
> 2) Allow for XML Dsig, leave the decision on the digital signature profile to the end users.
> 
> 2.1.- In CounterSignature (sequence), add the ds:Object element with the ds:Signature of the SignatureValue for the previous signature.
> 
> 3) For the cosignature (parallel). 
> 
> 3.a.-  When the number of signatory parties is known --> use your recommendation (UBL XAdES Profile Version 1.0; 1 march 2010), adding the possibility to use the transformation based on REC_xpath (dsig:XPath) as it is more extended. 
> 
> 4b.- If signatory parties unknown --> Establish the following exception to the UBL Document when signing: Exclude all UBLExtension and descendants where there is a ds:Signature.   
> 
> 5) We possiblly could get another exception when signing UBL documents, for instance excluding any UBLExtension containing a special element, for instance UnsignedData:
> 
> <element name="UnsignedData" type="UnsignedDataType" /> 
> <complexType name="UnsignedDataType" mixed="false"> 
> <sequence> 
> <any namespace="##any" minOccurs="0" 
> maxOccurs="unbounded" /> 
> </sequence> 
> </complexType> 
> 
> I'm looking forward to hearing from you
> 
> Best regards, 
> Oriol
> 
> 
> El 15/03/2010, a las 05:07, Andrea Caccia escribió:
> 
>> Dear all,
>> please find attached a new draft for the UBL XAdES profile. As agreed during the F2F meeting in Copenhagen there is the opportunity to insert this profile with the release of UBL 2.1.
>> I kindly ask you to review it before the end of this week so, if there isn't any major issue, I can take into account your comments and send it to the TC in time.
>> 
>> Thank you.
>> 
>> Regards,
>> Andrea
>> <UBL-XAdES-Profile 1.0-20100301.doc>---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]