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: [spam] Re: [ubl-security] Questions regarding the XAdES Profile


I think we do nto have to create limits to current UBL documents
expecially legal documents like CoO and Invoice, instead we should provide
the instrument/methodologies to let implementers build more specific
profiles driven by business rules.

The way UBL is it is streightforward to support business requirements and
XAdES for legal signature-related things.

If we remove the problem of applying more signatures (see my previous
mail) why we need scaffolding ?

The cac:Signature can be used as it is intended for metadata related to
business and to satisfy practices like those in CoO.

The cac:Signature in the root context can still be the metadata for
document-wide signatures (and now you can insert as many metadata you
want.

I proposed an alternative way to use existing UBL mechanisms.

This mode is no more constraining the cac:Signature, the number of
signatures, the time when it is applied.

Also XAdES has nothing less and can be used fully into UBL Extensions.

Cheers,

Roberto


> I wad working on this in parallel to last proposal from Roberto.
>
> This is a simplification in line with the "scaffolding approach": I think
> we should firstly make a decision if:
> 1) staying with the old approach with some allowed ways to fit additional
> requirements by loosening some security feature on exceptional basis
> 2) staying with the scaffolding approach, possibly simplifying it (an
> example is hereafter)
> 3) privilege only flexibility but loosing a lot of security features that
> I feel can be unacceptable in some circumstances (that we cannot assess in
> a very short timeframe)
>
> My personal view is to go with 1) and possibly move to 3) (or 2))if we
> find a sound rationale for it, possibly based on the comments we'll
> receive in public review.
>
> Andrea
>
>
> Il giorno 27/ago/2010, alle ore 09.44, Oriol Bausą Peris ha scritto:
>
>>
>> El 26/08/2010, a las 23:06, G. Ken Holman escribió:
>>
>>> At 2010-08-26 16:49 -0400, Jon Bosak wrote:
>>>> Sorry if this is something that should be obvious to me, but I'm
>>>> not understanding the need for multiple signatures on UBL
>>>> CertificateOfOrigin.
>>>
>>> This sample from Roberto illustrates the multiple signatures on the one
>>> form:
>>>
>>> http://www.export911.com/e911/export/docFormA.htm#docFormA
>>
>> I am sorry but I think the sample from Roberto shows that the CoO is
>> signed by two different people. So it is a single group (using your
>> terminology) of two signatures. They are signing the whole document, not
>> parts of it, so there is not need for identifying which part of the
>> document they are signing.
>
> I'd like to clarify a point here: the signed object is always the whole
> document. The ID mechanism is just for having a logical association, a
> sort of pointer between a signature [group] and a part (a section) of the
> document.
> I'd like to add also that I'd like to avoid that this logical association
> is necessairly to a cac:Signature: I think this element should be always
> optional and that it should be possible to logically associate a signature
> to whatever element that has an <cbc:ID>. This way we can be very flexible
> without having to modify the core syntax for any local legal requirement
> that has to be met
>
> Reading the last comments from Roberto it is not clear to me if there is
> always a single document signature associated to the document, and having
> the cac:Signature just a reference, or if the document has multiple
> signature [groups].
>
> I think we can have a simpler structure:
>
> <sig:SignatureInformation>
>  <sig:SignatureGroups> (one or more)
>    <cbc:ID> … </cbc:ID> (an optional pointer to a section of the UBL
> document; if absent it is a generic signature [group] applied to the
> whole document)
>    <sig:SignatureGroup>
>      <ds:Signature> … </ds:Signature> (zero or more signatures associated
> to the same cbc:ID)
>    </sig:SignatureGroup>
>  </sig:SignatureGroups>
> </sig:SignatureInformation>
>
> At the time first signature has to be added, an example of the required
> scaffolding is:
> <sig:SignatureInformation>
>  <sig:SignatureGroups>
>    <sig:SignatureGroup>
>    </sig:SignatureGroup>
>  </sig:SignatureGroups>
>
>  <sig:SignatureGroups>
>    <cbc:ID>CertificateOfOriginApplicationID</cbc:ID>
>    <sig:SignatureGroup>
>    </sig:SignatureGroup>
>  </sig:SignatureGroups>
>
>  <sig:SignatureGroups>
>    <cbc:ID>IssuerEndorsementID</cbc:ID>
>    <sig:SignatureGroup>
>    </sig:SignatureGroup>
>  </sig:SignatureGroups>
>
>  <sig:SignatureGroups>
>    <cbc:ID>EmbassyEndorsementID</cbc:ID>
>    <sig:SignatureGroup>
>    </sig:SignatureGroup>
>  </sig:SignatureGroups>
>
>  <sig:SignatureGroups>
>    <cbc:ID>InsuranceEndorsementID</cbc:ID>
>    <sig:SignatureGroup>
>    </sig:SignatureGroup>
>  </sig:SignatureGroups>
>
> </sig:SignatureInformation>
>
> Any xxxID content of cbc:ID is just used to clarify for the example
> purposes what is meant to be associated to the signature[group] in the COO
> example.
> Not all pointers are needed if it is already known in advance that some
> are not required; in case it is not known in advance if a
> sig:SignatureGroups element could be present even if, at the end, no
> ds:signature is really inserted.
>
>
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123 begin_of_the_skype_highlighting              +39
328 2148123      end_of_the_skype_highlighting
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org




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