[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] UBL-XAdES-Profile 1.0-RC1
At 2010-08-13 08:38 +0200, Andrea Caccia 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]