[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: [ubl] Re: Making references
Since there are no further comments, I'like to modify the current draft taking into account our recent discussions. These are the changes I'd like to introduce: - use of cac:Signature with the original UBL semantic. Its main purpose is twofold: to identify the signature profile and to point to the "real" digital signature (being it detached or enveloped within the UBL document). This SC will define a set of reserved URIs (with a common base) and any user group can do the same or even not use cac:Signature at all and define different rules, provided they do not use the reserved URIs. - support for multiple signatures. As both CAdES and XAdES can support multiple signatures directly, I think it's better to use the mechanisms allowed by the standards and just profile their use. - about the additional wrapping structure to be used in the extension, I'll describe both the solutions (with and without it) then we'll try to reach an agreement on what to keep. I'm not in favor to keep both and, if no agreement is reached, I propose to leave the decision to the TC. I'd like to specify that, without the wrapping element, no constraint is imposed on the ID inside the extension and thai the ID inside the signature has the constraint to be equal to the ID chosen for the extension. If the TC consider this as a violation of the UBL semantic then the wrapping solution can be taken. - support for detached signatures, both XAdES and CAdES: there are the following additional reasons to take this into account, even if the work can probably only drafted at this stage: * as was originally mentioned before activating this SC UN/CEFACT TBG6 is also dealing with security. After the UBL F2F and CEFACT forum in Rome I started to participate to their work. The first format considered was the enveloping one, that we excluded as one of our requirements as it does not preserve the syntax of the signed message. The detached format will be supported in the next release of the Recommendation we're working on as the signature could be published and available or carried as a soap attachment and this means a common format can be defined. * in ETSI we're working on a the "attached signatures", a way to package the detached signature and the signed object in a standard structure. We are also considering OASIS Open Document format (part 3). Attached signatures could be a solution for archiving needs, as the document and its signature are collected in a single file. Please let me know if it could work, I'm going to start next week. Andrea Il giorno 04/dic/2009, alle ore 04.09, G. Ken Holman ha scritto: > At 2009-12-03 16:31 +0100, Andrea Caccia wrote: >> It seems we all in the SC are on quite different positions... I answer inline both to Oriol and Ken. > > Thank you for your perspective on these issues. > >> 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'm not discounting your perspective, Oriol, and I recognize that you have concerns with this, but I don't believe it is complex and I believe we've been following the information analysis and derivation techniques that were used to create UBL in the first place. I hope to lessen your concerns and we should be sure to document how to do so in order to assure readers of the end result. Your concerns you have now will be very valuable in improving the documentation. > >> > 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. > > Well said. > >> 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. > > Interesting! > >> 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. > > That I am uncomfortable with ... if I've created a Crane extension and I use ds:Signature in my Crane extension to sign a fragment of my Crane extension, I would not want that signature to be construed as a signature on the entire document. > >> Schema validation of extension content is delegated to the XAdES verifier to whom the entire content of the extension is sent. > > I'd like to see it packaged in UBL 2.1 as I mentioned on the TC teleconference ... more about that below. > >> 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'm glad it meets a need. > >> > 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. > > Absolutely ... plus, if the Security SC publishes a number of methods in its report: > > (1) - external implied signature(s) > (2) - external specified signatures via SignatureMethod > (3) - embedded specified signatures via SignatureMethod and extension > > ... using ds:Signature solely for illustration, then a UBL user community can profile the Security SC document choosing one of the methods by having been educated on the possible ones available and thus weigh the benefits and drawbacks. > > Coming back to my very first comment in my first post, this would meet my need of a document: > > At 2009-11-30 06:11 +0530, I wrote: >> First let me say that I do not have a background in digital signatures, and I've approached this document as an implementer wanting to learn how digital signatures are to be used with UBL. > > At 2009-12-03 16:31 +0100, Andrea Caccia wrote: >> 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. > > Sounds good to me! > >> 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. > > Sounds a bit too harsh for me ... a community of users may wish to simply assume that every document shall be externally signed. Not only would I not want to burden all members of the community with having to indicate the assumed signature method but it might make it difficult to import UBL documents from other user communities that didn't follow that rule yet could still be externally signed. > >> > El 02/12/2009, a las 18:26, G. Ken Holman escribió: >> >> 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?... >> 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 > > Well, remember the TC is looking to the SC for direction. I think the SC should present a document with all options and then the TC can decide if the UBL community is best served with all or a subset of options. I believe the spirit of UBL is to present *all* options. > > Any user community (Europe, Spain, Crane, etc.) can then choose to say which way UBL documents will be signed in their respective worlds using one of the recommended methods documented by the TC (written by the SC). > >> >> 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) > > Agreed. > > But perhaps my point was lost ... I wasn't introducing sig:Signatures to imply a *joint* signature, but merely a single home for all sig:Signature constructs so that a processing application will find all sig:Signature constructs under a single extension point. > > Perhaps sig:Signatures/cbc:ID is the identifier of a joint signature while sig:Signature/cbc:ID is the identifier of a singleton signature. > > In the legal world of security does a joint signature have a different semantic than a combination of individual signatures? If not, then we don't need sig:Signatures/cbc:ID: > > wrap:Envelope > wrap:Item+ > cbc:ID > wrap:XMLValue? > wrap:Base64Value? > > (where wrap:Envelope is what I would call sig:Signatures and wrap:Item is what I would call sig:Signature, but we'll worry about names later). > > Another question: if the envelope can have an ID does that make the IDs of the items optional and omitted when the envelope has one? > > In any proposal we take seriously, we will need to create some number of test scenarios to exercise the combinations of the required and optional elements and ensure the document model proposed meets all needs. Then we include all of these in the documentation so that users understand typical scenarios. > >> >> 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 > > Please forgive me for confusing you when I use so many words (I know I do this too often). Let me summarize my opinion regarding publishing our results: > > (1) - we develop the first standardized extension vocabulary and > extension schema fragment: one for security > (2) - we don't include the extension in the common library of business > objects for UBL 2.1 > (3) - we do include the extension in the schema suite for UBL 2.1 and > explicitly engage it from the published UBL 2.1 extension fragment > (which can be picked up and dropped into a UBL 2.0 environment > replacing the UBL 2.0 extension fragment without change; if that > weren't the case, then we haven't developed a true UBL extension) > >> >> 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. > > Excellent ... I totally agree ... thus we should have a number of options available. > >> Ok, understood. The MimeType may be useful if we think this structure can be reuse elsewhere, in our case it is useless > > Indeed. > >> >> 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... >> Ok. As I wrote before I prefer this point is decided among who knows better UBL insights in the SC. > > But remember the Security SC members are the subject matter experts, not TC members such as myself. When I try and facilitate model development I leave the naming of constructs to the subject matter experts, expressing my opinions when I perceive (as an outsider) possible ambiguities or challenges with the names proposed. The specification should be idiot-proof and from how often people tell me I must be a good one! > > Thanks, all! I'm finding this very fruitful and I'm learning a *lot* about XML document security. I'm confident the specification you produce will be invaluable to the UBL community. > > . . . . . . . . . . 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]