[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Where to go from here
Il giorno 27/ago/2010, alle ore 16.04, G. Ken Holman ha scritto: > At 2010-08-27 15:43 +0200, Andrea Caccia wrote: >> My last proposal is a vote for (A) trying to fix some of the issues you point out at the end of your email. > > Please advise how you perceive the fixes to be accomplished. I pointed out that (A) does not provide for associations with UBL business objects. I've already explained we cannot use the <ds:Signature Id=""> attribute for referencing UBL business objects. Thanks for remembering this, you're absolutely right. Here are the solutions I propose: 1) add an optional cac:ID to the "zero scaffolding" - not very well following UBL rules but the simplest way: <sig:SignatureInformation> <cbc:ID>…</cbc:ID> (optional) <ds:Signature>...</ds:Signature> … <ds:Signature>...</ds:Signature> </sig:SignatureInformation> The rule is: if no ID is present, the signature refers to the whole document. More than one extension containing signatures with no ID is exactly the same as having a single extension with no ID and all the signatures inside it. In cases like COO where you can find many signatures you have at least an extension for any ID you have to reference end optionally another extension for the document wise signature. No need for cac:Signature if the parts to be referenced have a cbc:ID that can be referenced. 2) same as above but following better UBL rules: <sig:SignatureInformation> <cbc:ID>…</cbc:ID> (optional) <sig:SignatureGroup> <ds:Signature>...</ds:Signature> … <ds:Signature>...</ds:Signature> </sig:SignatureGroup> </sig:SignatureInformation> 3) the full scaffolding approach, s proposed by Ken (in this case I would limit as it is now to have a single extension containing signatures) As the original proposal from Roberto is missing to specify a way for linking document and signatures, I consider 1) and 2) as refinements of his proposal (if others can work, they can be considered too). If we decide to go to PRD1 with more than a single option, we can keep one between 1) and 2) and 3). Another possibility could be to use some mechanism inside each ds:Signature to restrict the signature to a portion of the UBL document, but I do not like this because: - the verification process becomes more complex as controls have to be added to be sure that the signed part is the right one - an user interface used to show the document become more complicated as it has to make aware the user about the signed parts by each signer > >> I agree with you that we can't simply exclude all extensions "a priori", but, in some motivated circumstances, I think this can be acceptable id in agreement with the recipient and acceptable for the rules in force: this is the way i tried to face the issues. > > Fine ... then users can adjust the hash transform accordingly. And that can be easily addressed in the supporting Security SC document on how to work with the extension. No problem there. > > Thank you for your guidance. But I'm still unclear on what it is I deliver to Jon. > > . . . . . . . . . Ken > >> Andrea >> >> >> Il giorno 27/ago/2010, alle ore 14.55, G. Ken Holman ha scritto: >> >> > Fellow Security SC members, >> > >> > With so many concerns expressed regarding my proposal, I have no problems stepping away from it and quickly implementing whatever the SC decides for PRD1. It seems over the days that all of the participants, including myself, have only repeated their initial stances and seem unswayed by the arguments of others. And that is fine ... we all have different perspectives that we are bringing to the table. >> > >> > As I read this morning's messages, we have to decide between two alternatives to what is in the SGTG package today, being between zero scaffolding: >> > >> > (A) Oriol/Roberto/Tim: >> > <sig:SignatureInformation> >> > <ds:Signature>...</ds:Signature> >> > ... >> > <ds:Signature>...</ds:Signature> >> > </sig:SignatureInformation> >> > >> > ... and generic scaffolding (though because of modeling rules we cannot use the proposed plural term and I'm trying to think of another singular term): >> > >> > (B) Andrea: >> > <sig:SignatureInformation> >> > <sig:Signature> >> > <cbc:ID>...</cbc:ID> (optional) >> > <sig:SignatureGroup> >> > <ds:Signature>...</ds:Signature> >> > ... >> > <ds:Signature>...</ds:Signature> >> > </sig:SignatureGroup> >> > </sig:Signature> >> > ... >> > <sig:Signature> >> > <cbc:ID>...</cbc:ID> (optional) >> > <sig:SignatureGroup> >> > <ds:Signature>...</ds:Signature> >> > ... >> > <ds:Signature>...</ds:Signature> >> > </sig:SignatureGroup> >> > </sig:Signature> >> > </sig:SignatureInformation> >> > >> > In my intermediate work I had the above structure but then distilled out the signature group that did not have a <cbc:ID> child so that one would not have *two* <sig:Signatures> with no <cbc:ID> child (when you have two, do both apply to the semantic of not having an ID?). So, in my proposal I had prevented two signature groups from having no identifier, using modeling to prevent the ambiguity: >> > >> > (C) Ken: >> > <sig:SignatureInformation> >> > <sig:SignatureGroup> >> > <ds:Signature>...</ds:Signature> >> > ... >> > <ds:Signature>...</ds:Signature> >> > </sig:SignatureGroup> >> > <sig:IdentifiedSignatureGroup> >> > <cbc:ID>...</cbc:ID> (required) >> > <sig:SignatureGroup> >> > <ds:Signature>...</ds:Signature> >> > ... >> > <ds:Signature>...</ds:Signature> >> > </sig:SignatureGroup> >> > </sig:IdentifiedSignatureGroup> >> > ... >> > <sig:IdentifiedSignatureGroup> >> > <cbc:ID>...</cbc:ID> (required) >> > <sig:SignatureGroup> >> > <ds:Signature>...</ds:Signature> >> > ... >> > <ds:Signature>...</ds:Signature> >> > </sig:SignatureGroup> >> > </sig:IdentifiedSignatureGroup> >> > </sig:SignatureInformation> >> > >> > This is also our committee's first standardized extension and people will be trying to learn from what we do. >> > >> > My assessment is that proposal (A) is inflexible in expressing any associations between the UBL business objects and the signatures (I've already shown in another email we cannot use the <ds:Signature> identifier for such an association). Communities of users might want to infer associations between business objects and signature information. Future UBL documents might require associations between business objects and signature information. >> > >> > My assessment is that proposal (B) is potentially ambiguous and burdens the user community with defining exception handling when interpreting what it means to have two unidentified groups. Or even three or more ... is there a relationship implied by two of the three if they are adjacent? >> > >> > I accept that my proposal (C) is unacceptable to committee members because of perceived complexity as that has been mentioned time and time again. But I believed all along it addresses the flexibility for user communities and future UBL documents, and it is unambiguous in preventing multiple unidentified groups, and it is an example of a detailed extension that others can follow in creating their own extensions. If documenting the complexity is a challenge, I think documenting the exception handling of ambiguity is a bigger challenge. >> > >> > (C) is implemented and I have time this weekend to implement either of the (A) or (B) proposals ... but which is it to be? Someone please decide and direct me. I hereby withdraw from the decision making. >> > >> > Sorry, that sounds like pouting and I'm not pouting at all ... I just need to deliver something to Jon ASAP. Please don't interpret my comments as negative ... I really don't mind abandoning my proposal since not a single member has supported it ... this is a collaborative group and I accept my proposal doesn't fly ... happens all the time and we are all professionals ... but I need to be told what to do in order to give something to Jon, and I need a decision as soon as possible, please. (A) or (B). >> > >> > Oh, regarding the scope of the signature, I feel we are obliged to include non-signature extensions in the signature calculation since other extensions will contain business information for some communities of users. We cannot exclude all extensions from the signature hash. So that would be that we must include all information outside of the ancestral <sig:SignatureInformation> element in both scenarios (A) and (B). >> > >> > Thanks for the debate. Please decide and we'll move on with user testing. We can change it all for PRD2 if you wish. >> > >> > . . . . . . . . . . . Ken > > > -- > XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01 > Vote for your XML training: http://www.CraneSoftwrights.com/o/i/ > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > 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]