[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Where to go from here - Final proposal?
Hi Oriol, your concerns helped to improve the work of this SC as keeping things simple is a very difficult task. About your concern, this come from a requirement that is almost new to me but, to some extent, is covered. In fact current implementation: - mainly address the case where each signer signs all the document but a mechanism is given, trough the referencing ID, to logically associate the signature to a portion of the UBL document. This is a logical association, whose meaning can be addressed by some legal support (out of our scope) e.g. defining that the signature engages the signer only for the referenced part and granting only origin and integrity for the whole content. An example for this kind of legal support is i.e. for electronic invoicing and qualified signature: even id a qualified signature implies normally non repudiation of the content, the VAT directive defines, by law, that the signature is only granting origin and integrity. - on the other hand, I don't want to have mandatory xpath expressions but only recommend them. This can allow the support of any use case, including signing just a pert of the UBL document. I believe there is space to improve our approach to support the case where you have to logically attach signed documents (e.g. certifications) to an UBL document. Those certifications could be part of the UBL document or not (I guess) and we have to fully understand what constraints we can have on the workflows to understand clearly what kind of signature is the most suitable (maybe a detached signature approach is better). As there are many options, further discussion is required to find, again, the simplest way to cover the most important requirements and leave open the door for adaptations to the model that can cover possibly all of them. As no more time is available for PRD1 but, on one hand I think we reached a point that covers our initial requirements and is enough stable and suitable for implementation, on the other hand we found additional requirements worth to be addressed that con complement, not replace, current approach, for which we need more time to find good solutions. I think there is time to work again on the document and improve our approach for PRD2 as, I'm very convinced, will not be a big change on what we already did. Let me know if this answers, at least in perspective, your concern and if you agree to proceed this way. Andrea Il giorno 30/ago/2010, alle ore 09.59, Oriol Bausà Peris ha scritto: > Hi Andrea, > > I like your approach as it minimizes the complexity, and also Ken's proposals for NDR adaptation seems quite good to me. > > Forgive me again for being annoying and insisting on this topic, but let me raise one of my concerns: I think that we are mixing two different types of signatures here. One signature is for the whole UBL document. This means that we can have signature tools creating and validating these signatures using a single XPATH expression (we have been talking about this XPATH expression so far) without any problems using signature applications with less effort. > > The second signature type we are talking about is not a signature for the whole document, but a signature for an object embedded into the UBL document, either an Item, a Referenced Document, etc. And we are trying to apply the same mechanism of encapsulating them to both types. Even if you identify these second type signature with an ID, a ReferenceSignatureID or anything else, the processes to create this type of signature, to place the signature into the Extension and to validate the signature when received are very different from the ones for first type. I think that in this second case, you cannot just apply the XPATH to exclude the SignatureInformation, you will need to extract what was originally signed, and you do not exactly know as a receiver.... In case of an Item, it was the Item element from the <Item> tag, it was it contents? if we are talking about the signature of a document reference, is the document reference class being signed? is the signature of the document itself in Base 64? or the signature is for the original file prior to its conversion to Base64? It seems to me that creating tools to support that is more difficult and needs extra information. > > Under my point of view this means that there are two types of signatures packaged within a UBL document very similarly but which process is to be very different: > > 1) Signatures for the whole document can be created, placed and validated from within the UBL document itself as they are "enveloped signatures" > > 2) Signatures for parts of the document are "detached signatures" packaged within extensions, so its creation, placement and validation differs from the former, They have to be created extracting pieces of information out of the UBL document, calculating the signature, and placing everything into the UBL wrapped, they have to be validated extracting information and even transforming information (depending on how have you applied to original signature) and verifying it (the XPATH expression for the type 1) signature does not apply in this case). > > So what I mean is that the second type of signature is different from the first one, and that only and ID is not enough to ensure the capacity of validation in the receivers end. Maybe I am wrong with all this, and my concerns have no foundation, so in this case I like the type of structure Andrea has defined. > > Best regards, > Oriol > > > El 28/08/2010, a las 12:23, Andrea Caccia escribió: > >> 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 >> --------------------------------------------------------------------- >> 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]