OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-security] Re: [ubl] Re: Making references


Well done, Andrea.  I'm looking forward to seeing the end result as 
it looks like it will be very comprehensive and a good guideline for 
people like me who do not have a background in applying signature 
specifications.  I think we will be a big audience for your document.

My only comment has to do with the identifiers for extensions.  I 
strongly feel we cannot impose any constraints on extension 
identifiers.  Their interpretation is solely for the management of 
extensions amongst other extensions.  I firmly believe 
ext:UBLExtension/cbc:ID values should not have any reflection on 
business objects of any kind, including signature objects.  It is 
scaffolding information, it is not business information.

Please let me know if I can help you with the schema fragments.

I hope everyone has a safe and happy holiday!

. . . . . . . . . . . Ken

At 2009-12-23 05:14 +0100, Andrea Caccia wrote:
>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


--
UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]