[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [spam] Re: [ubl-security] UBL-XAdES-Profile 1.0-RC1
Hello,
the case of the Certificate Of Origin is that UBL TC originally provided
the context of each signature by adding a cac:Signature to a set of BIEs.
Todays the context of a signature is provided as part of the signature
itself and driven by another standard (e.g. XAdES)
So the real issue is should choose now what is best for providing context
to signatures:
1) UBL BIEs
2) Other eSignature related standard
By the business point of view I would see UBL as the preferred place to
hold contextual information.
It's happen that XAdES has a specific support for the signature context
(Andrea and others could confirm this please)
So we must choose or provide a preference or a precedence.
Please note that other alternative, additional standards for e-Signatures
could be not supporting the context.
XAdES is an European standard with a good adoption in Japan and Brazil,
but UBL is an Open Standard and we must be prepared to other possible
signatures.
Hope this helps,
Roberto
> At 2010-08-13 08:38 +0200, Andrea Caccia
begin_of_the_skype_highlighting end_of_the_skype_highlighting wrote:
>>At 2010-08-11 23.14 GET, G. Ken Holman wrote:
>> > (1) - Lines 430 and 435 - when using this
>> methodology, I gather that multiple signatures
>> are instantiated in the extension and that I
>> need only a single <cac:Signature> element in
>> the instance itself to indicate that *all*
>> XAdES signatures are in that extension ... so,
>> if I need two signatures, I still only have one
>> <cac:Signature> element and I put the two signatures in the extension
>> > - if this is correct, then I can understand
>> <cbc:ID>UBLDSIG</cbc:ID> being a fixed value
>> and that value being a child of the document element
>>Yes it is correct
>>
>> > - but in Certificate of Origin there are four <cac:Signature>
>> elements:
>> >
>> > <cac:CertificateOfOrigin>
>> > <cac:CertificateOfOriginApplication>
>> > <cac:Signature> <!--for the document-->
>> > ...
>> > <cac:IssuerEndorsement>
>> > <cac:Signature> <!--for the endorsement-->
>> > ...
>> > <cac:EmbassyEndorsement>
>> > <cac:Signature> <!--for the endorsement-->
>> > ...
>> > <cac:InsuranceEndorsement>
>> > <cac:Signature> <!--for the endorsement-->
>> >
>> > - and in the common library, an item can have
>> a signature, and there are 21 places where items are used:
>> >
>> > <cac:Item>
>> > <cac:Certificate>
>> > <cac:Signature>
>> >
>> > ... so signatures can be used all over the UBL document.
>>It seems I started from a wrong assumption.
>>Is endorsements applied to the whole document or just a fragment?
>
> As this is a business question, I cannot answer
> because I do not know. The CertificateOfOrigin
> is not the responsibility of either the PSC nor
> the TSC. I have copied Tim with your question
> and this issue in case he can answer for us.
>
> The issue continues...
>
>> > - does line 430 imply that this Security
>> methodology does *not* apply to the
>> endorsements but only to the signatures that apply to the entire
>> document?
>>If we can't find an arrangement to deal with
>>this situation we have to be explicit IMO
>>
>> > - shall we explicitly exclude the
>> endorsements (and future signatures) so that there isn't a conflict?
>> > - if someone wants to use XAdES for an
>> endorsement and in the future writes a
>> methodology for that, is our current choice of
>> "UBLDSIG" too ambiguous? Should it perhaps be
>> "UBLDOCDSIG" or some other value to imply this
>> is the signature ID for that block of signatures for the entire
>> document?
>>
>>We can try to change current assumption that
>>there is only a single cac:Signature and I propose the following:
>>- there is a 1:1 mapping between cac:Signature
>>elements and UBLextension elements containing signatures
>>- we add a <cbc:ID> optional element inside
>><ublsig:document-signatures
>>xmlns:ublsig="urn:X-figure-this-out-later"> (as
>>you proposed in another mail in place of
>><odsig:document-signatures>). This new element
>>MAY be present if there is a cac:Signature and,
>>if present, MUST be set equal to the cbc:ID in
>>the corresponding cac:Signature. I see here a
>>good reason to have a new schema defined. I have
>>indeed a little preference for
>><ublsig:signatures> as it is the most used signature container wrapper.
>>- if there is more than one cac:Signature in the
>>UBL document, each MUST have a <cbc:ID> that
>>maps to <cbc:ID> element inside
>><ublsig:document-signatures> that MUST be
>>present too. So, in case a single signature is
>>present as in most cases, the cac:Signature is
>>optional and everything is as it is now.
>>- for detached signatures I propose to have them
>>applicable only to the whole document as it is now
>>- for <cbc:ID> value it MUST be unique (this is
>>implicit I guess) and we can just suggest its
>>something starting with "UBLDSIG…" or "UBLDOCDSIG…" as you suggested
>>...
>> > - in fact I now believe (after working on
>> this document) that we should not use a simple
>> string that is too easily ambiguous with what
>> users might inadvertently use (yes, I know
>> "UBL" is not common, but why use an ad hoc
>> identification scheme when there is one we can
>> use) and select two URNs for the values on
>> lines 430 and 435, and the values along the lines of:
>> >
>> > <cac:Signature>
>> >
>> <cbc:ID>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature</cbc:ID>
>> > [...]
>> >
>> <cbc:SignatureMethod>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/xades-enveloped</cbc:SignatureMethod>
>> > <cac:SignatoryParty>
>> > <cac:PartyIdentification>
>> >
>> <cbc:ID>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/signature-defined</cbc:ID>
>> > </cac:PartyIdentification>
>> > </cac:SignatoryParty>
>> > [...]
>> > </cac:Signature>
>> >
>>it seems to me a good idea. So we can have also
>>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/ubldsig/N
>>(where N=1, 2, … ) instead of UBLDSIG or
>>UBLDOCDSIG to identify the document signatures?
>>But are we following the UBL common practices here?
>
> Yes, good point. I missed the fact that we have
> to point to an ordinal signature.
>
> With that in mind, I'm going to now propose a URN
> instead of a URI, and I will follow up this
> discussion in a reply to Roberto's recent post as
> it will address that issue as well.
>
>> > (2) - do you believe the definition on UBL
>> 2.1 Common Library row 225 incorrect? it
>> states it is a signature applied to the
>> document instance, but its placement implies it
>> is a signature applied only to the certificate
>> > - if you agree it is wrong, then Jon this
>> goes onto the list of definitions to be repaired
>> >
>>I feel you're right. Can you point me to the right document?
>
> It is the spreadsheet for the common library an you can see the latest at:
>
> http://www.oasis-open.org/committees/document.php?document_id=38804
>
> ... but there will be another one posted this
> morning by me, so look on that page under
> "Document Revisions" to find the latest.
>
>> > (3) - I note that only 54 documents allow
>> <cac:Signature> as a child of the document
>> element, and Certificate Of Origin has the
>> document-wide signature in a grandchild of the
>> document element ... do we need to add for PRD2
>> a <cac:Signature> child of the document element
>> to the other 5 documents that do not have this today?
>> > - my thought is "yes, every UBL document must
>> have a <cac:Signature> *somewhere* to apply to
>> the entire document scope, and from now on it
>> must be a child of the document element (so
>> that CoO is the one and only UBL document that doesn't have it as a
>> child)"
>> > - the five documents with a missing
>> cac:Signature as a child of the document element are:
>> > CallForTenders
>> > CatalogueRequest
>> > ContractAwardNotice
>> > ContractNotice
>> > PriorInformationNotice
>> >
>>At least to authenticate it I think that there
>>could be situations where the signature could be
>>a requirement. The approach of making it
>>optional for every document at document-wide levelis fine with me.
>
> Good ... this has been added to the list of changes after PRD1.
>
> I will continue now in reply to Roberto.....
>
> . . . . . . . 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
>
>
--
* 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]