[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: [ubl] Re: Making references
It seems we all in the SC are on quite different positions... I answer inline both to Oriol and Ken. Andrea Il giorno 02/dic/2009, alle ore 23.00, Oriol Bausà ha scritto: > I am sorry but my personal opinion on all that issue is that you are getting all that more and more complex, and I cannot understand why this should be that way. > > I cannot understand why you need a wrapper inside a wrapper of another wrapper. I'm not an UBL expert so on some points I'm more trying to understand and explore the solutions we have than sponsor a specific solution. Said that, let see if we can simplify. In the current document we consider only signatures on the whole document. This allows us to make some assumption. We can avoid to mandate a link between cac:Signature and the signature itself. In fact the application can read cac:Signature/cbc:SignatureMethod URI and configure itself to search for any ds:Signature present in each UBL extension. Schema validation of extension content is delegated to the XAdES verifier to whom the entire content of the extension is sent. In case we have multiple signatures, the process is repeated. I think we can have a single cac:Signature for the set of signatures, as: - they in fact apply to the whole document, and - no signature can be added in a second time, as adding it modifies the document and invalidates the previous one. So they can be considered "atomic" in the sense that, after the message is completed, no other signature can be added. This is the simplest form I think is workable bot for the signer and the verifier. On the other hand if we want to have all the co-signatures in the same package then a wrapping structure is needed. But there is also the possibility that XAdES will include co-signatures in future (and this can be also a request from this SC to ETSI/ESI): this way should be the most correct way to go. > > I would recommend to keep this as simple as possible, and maybe the recommendation should be NOT using the cac:Signature component at all. I agree with you on keeping all as simple as possible but it should be simple both to generate and use it so I do not agree not using at all cac:Signature because it is already part of the UBL syntax and can give us some useful information for the receiving application. There are many ways to sign an UBL document and we are defining a profile that recommends 1 or possibly 2 ways (if we decide to support detached signatures) and in future both us and others can define new ones. I think it has to be recommended (and maybe mandated) that cac:Signature is present when the message is signed and that cac:Signature/cbc:SignatureMethod contains an URI that identifies in an unique way how the message is signed. This way an UBL aware parsing application can detect if it is able to verify the signature and make some decision. > > Thanks > Oriol > > > El 02/12/2009, a las 18:26, G. Ken Holman escribió: > >> At 2009-12-02 11:36 +0100, Andrea Caccia wrote: >>> Having thought more, it make sense to consider the enveloped form only with XAdES (or the basic XMLDSIG). >>> Fot detached forms the cac:Signature should be enough, we should consider to update later the document or to prepare a new one if UBL TC ask us to do so. >> >> Is there an opportunity (i.e. enough time) for the one document to guide UBL users in both embedded and detached signatures so that they can make an informed decision regarding which way to go with their own work? I hope this is the case as (1) users unfamiliar with the options (like me!) would learn more of what is available and (2) the review/approval/publication process for committee documents is onerous enough to give weight to doing this once instead of twice. OK but I'd like first to reach an agreement on the enveloped signature, in the meantime it should be better to check with the TC if considering also detached signatures (at this point not only XAdES but also CAdES) is in out scope >> >>> 4) avoid to reuse "Signature" as tag name for the wrapping structure, as it can be confusing; a generic structure can be defined instead >> >> This has been a common question in SGML and XML vocabulary development over the years and the confusion you anticipate may in fact not come to be. Moreover, using generic names may create even more confusion than using similar names as the generic names need then to be documented and can possibly be misinterpreted. The choice of labels is *so* very important. BUT!! A light bulb has just turned on for me and I have some comments below. >> >>> Point 1 alone justify to wrap the signature, so I propose to: >>> a) Have a single cac:Signature with a cac:ID pointing to wrap:Envelope/cbc:ID, contained in an UBL extension, containing one or more signatures that applies to the whole document (excluding the signature itself of course, using already defined XAdES/XMLDSIG rules). >> >> Interesting! I didn't realize there was a one-to-many relationship here. In my naïveté I thought it was always one-to-one. Maybe here we have also to be sure we are not violating the semantic of cac:Signature. I think that a joint signature has to be considered atomically (and this has to be stated in the profile too) >> >>> The content could be: >> >> Looks good! >> >>> b) Have a generic wrapping structure that can be reused in similar cases, be part of UBL 2.1, >> >> I think we still need to have this as a standalone Security SC specification of an extension, and then include the use of that extension in the delivered UBL 2.1 schemas. I don't think it should be part of the UBL 2.1 specification (other than the inclusion in the schemas). I was in fact referring to what you previously wrote. But if it becomes part of the UBL2.1 schemas I think it's better if it is more generic and not completely related to signatures >> >>> and could be something like: >>> <wrap:Envelope> >>> <cbc:ID>”AnySignatureID”</cbc:ID> [mandatory and unique among all extensions in the document] >>> <wrap:Item> [at least one present] >>> <cbc:ID>”AnyItemID”</cbc:ID> [optional; absent for this profile] >>> <wrap:MimeType> mime type of the signatures</wrap:MimeType>[optional, it's the mime type of Value] >>> <wrap:Encoding> encoding of the signatures</wrap:Encoding>[optional, if not present Value contains well formed XML, must be present for binary content and specify the base64 filter] >>> <wrap:Value> >>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; >>> xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";> >>> [...] >>> </ds:Signature> >>> </wrap:Value> >>> </wrap:Item> >>> <wrap:Item> >>> ...same as above... >>> </wrap:Item> >>> </wrap:Envelope> >>> >>> Does it makes sense? >> >> Looks great! I like the <wrap:Value> concept, but didn't realize that this specification was flexible enough to allow different signature expressions to be used. Not "flexible enough from a technical perspective" but "flexible enough from a policy perspective": I thought this guideline was a "what to do" specification, not simply a "how to do" specification. >> >> Is it your intention in the published specification to cite <ds:Signature> as *the* way sign a UBL document or *one* way to sign a UBL document? I think this profile (and future updates) should be way(s) suggested by UBL TC but can't be the only one as it is a recommendation so any user domain can specify its own way. >> >> Note that <wrap:Encoding> won't be needed, as it is not possible in XML to have a portion of the tree using a different character encoding than the rest of the tree. You state "must be present for binary content and specify base64" which while it makes sense from a programming data perspective cannot be expressed using UBL's naming and design rules. >> >> Which leads me to assume that was the only reason for <wrap:MimeType> and therefore that is no longer needed. >> >> Following the NDR for structuring (which doesn't allow for alternation), then, the structure would be using a pseudo notation: >> >> wrap:Envelope >> cbc:ID >> wrap:Item+ >> cbc:ID >> wrap:XMLValue? >> wrap:Base64Value? >> >> ... with the business rule that one or the other of XMLValue and Base64Value must be specified but not both. This is not uncommon in UBL because of the prohibition of alternation in the NDR modeling. Ok, understood. The MimeType may be useful if we think this structure can be reuse elsewhere, in our case it is useless >> >> Now, back to the labels: I was "cheating" when I arbitrarily picked the names <sig:Signatures> and <sig:Signature> out of thin air. Though I still like these names (I do not see them as potentially confusing as I noted above), these names should rather be derived from properly developed ISO/IEC 11179 names. >> >> When the Security SC ends up deciding on the structure to use, we should go through the appropriate naming exercise to determine the names to use for the elements. I don't have the time right now, and I would be worried of wasting the time if the committee does not agree with the proposal you've put forward and my comments above. Ok. As I wrote before I prefer this point is decided among who knows better UBL insights in the SC. >> >> . . . . . . . . . . . Ken >> >> -- >> Vote for your XML training: http://www.CraneSoftwrights.com/o/i/ >> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ >> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video >> Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 >> Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 >> 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 >> > > > --------------------------------------------------------------------- > 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]