[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: [spam] Re: [ubl-security] Questions regarding the XAdES Profile
Let me summarize and explain better my position. There is a concern about the scaffolding approach it's too complex to manage/implement and possibly this can create confusion in implementors. I share this concern, maybe not at the same level always expressed by Oriol, but I understand his position and, as he is dealing with the only real implemantation, I think it's important to take advantage of this. I consider also very interesting your approach but I have some concern, I think shared by Ken: - a new extension is needed for every signature, even in case just multiple signatures on the whole document is the only requirement. This can be confusing. - all metadata information about the signatures is not secured by the signatures, this means it can be changed and this cannot be detected by the receiver: a signature meant for one reason can be exchanged to any other one; any metadata can be just taken as an "hint" and need additional controls to be trusted - excluding all extensions we are blindly excluding to sign something that can be defined in future and could require signature protection - not signing the whole content create a requirement for the signature software to be aware of this UBL specific model and create problems especially in countries where qualified signatures are required: not advising correctly the user on what is signed can invalidate the signatures. My proposal is to proceed in a way that I thin is in line with the UBL philosophy of solving the most common problems in the simplest way but leave open ways to deal with specific issues. The approach I'm proposing is: 1) to start from our last draft, that allows one or more signatures on the whole content, excluding just the signatures, but not excluding cac:Signature (if present). I this this is allow to implement all legal requirements (at best of my knowledge and with no guarantee of course…). This was tested by Oriol and agreed to be easy to implement. 2) Remove the limit of having a single extension containing signatures. Does <ext:UBLExtension> allow an cbc:ID element? id yes this can be used to relate the extension signature(s) to a specific portion of the UBL document; if not present the signature(s) are not associated with any specific part or reason or this is implicit. Note that from a cryptographic point of view any signature applies to the whole UBL document, to avoid any logic that is UBL specific and to simplify signature processing. We are just talking about logical association of the signature to some part of the UBL document. 3) Recommend the current XPath but explicitly give, as an alternative to be used when special processing needs are in place, also alternative xpath that allow to cut away Extensions and/or cac:Signature elements I think we keep a good security level and implementation simplicity while leaving the flexibility required to deal with other needs. Andrea Il giorno 27/ago/2010, alle ore 13.44, Roberto Cisternino ha scritto: > I think we do nto have to create limits to current UBL documents > expecially legal documents like CoO and Invoice, instead we should provide > the instrument/methodologies to let implementers build more specific > profiles driven by business rules. > > The way UBL is it is streightforward to support business requirements and > XAdES for legal signature-related things. > > If we remove the problem of applying more signatures (see my previous > mail) why we need scaffolding ? > > The cac:Signature can be used as it is intended for metadata related to > business and to satisfy practices like those in CoO. > > The cac:Signature in the root context can still be the metadata for > document-wide signatures (and now you can insert as many metadata you > want. > > I proposed an alternative way to use existing UBL mechanisms. > > This mode is no more constraining the cac:Signature, the number of > signatures, the time when it is applied. > > Also XAdES has nothing less and can be used fully into UBL Extensions. > > Cheers, > > Roberto > > >> 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. >> >> >> >> --------------------------------------------------------------------- >> 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 >> >> > > > -- > * JAVEST by Roberto Cisternino > * > * Document Engineering Services Ltd. - Alliance Member > * UBL Italian Localization SubCommittee (ITLSC), co-Chair > * UBL Online Community editorial board member (ubl.xml.org) > * Italian UBL Advisor > > Roberto Cisternino > > mobile: +39 328 2148123 begin_of_the_skype_highlighting +39 > 328 2148123 end_of_the_skype_highlighting > skype: roberto.cisternino.ubl-itlsc > > [UBL Technical Committee] > http://www.oasis-open.org/committees/ubl > > [UBL Online Community] > http://ubl.xml.org > > [UBL International Conferences] > http://www.ublconference.org > > [UBL Italian Localization Subcommittee] > http://www.oasis-open.org/committees/ubl-itlsc > > [Iniziativa divulgativa UBL Italia] > http://www.ubl-italia.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]