[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-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? > - 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 > - (later in the day) - I jut read line 462 and I see that the element <odsig:document-signatures> is used, which also implies document-wide scope of the signature, which I think supports the decision to distinguish the ID as being a "document kind of ID" see above > - 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? > (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? > (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. > (4) - line 462 makes reference to the namespace prefix "odsig", which is cited as bibliographic entry "ODFP", but that entry starting on line 222 cites the UBL specification on line 224 ... what citation should be here? It should point to ODF document, let see if we keep it at all or has to be fixed > > (5) - line 469 "and their content" -> "and their content and any white-space between or around them" Maybe it's better to cut away from ", i.e. excluding all the <ds:Signature> elements and their content". > > (6) - line 473 "whole UBL document" -> "whole UBL document (as indicated by the empty attribute value)" > - I suggest this change because until I looked at the example, I thought that I had to fill in the attribute with a value ... it was only later that I realized the empty attribute has meaning ... so at this point I felt it important to say that the attribute must, in fact, be empty OK > > (7) - line 474 does not mention the Algorithm= attribute and I think it should (since you've talked about attributes elsewhere in the prose) Let me check this > > (8) - line 498 - I cannot correlate where in the prose the content of this line is specified Let me check this > > (9) - line 502: I still *strongly* disagree with labelling the XPath address you have on lines 504-506 with the XPath Recommendation URI because the "here()" function is *not* part of XPath ... but you've seen my other posts about this ... I will try later today to find another example of a signature application that uses this combination of address and URI ... it just seems so *wrong* to me (but perhaps because I was the founding chairman of the XSLT/XPath Conformance Committee and no-one else is going to care, so it could just be me and I accept that ... I'll just keep looking for justification *not* to use it as you have) > I think it's solved now > (10) - line 502: you are missing an end quote on the attribute specification OK > > (11) - line 511 - I cannot correlate where in the prose the content of this line is specified Let me check this > > (12) - lines 517/518 - these lines should be an informative note and not flowed as if it were normative ... and they aren't correct either ... the content of an extension may, in fact, be validated (which is what I'm trying to do with the extension schema) I'll rephrase it > > (13) - lines 525-528 - are these the lines that define the content of lines 498 and 511? > - if so, how is it that this specification can specify a particular <ds:Reference> element? > - is the <ds:Reference> element mandatory (if so, then I have to put it into the extension schema) for all uses of <ds:Signature>? Let me check this > > (14) - typo on line 475 - should be "RECOMMENDED" OK > > (15) - line 444 - this element in the example has white-space around the URI ... I think this white-space has to be removed because white-space is not part of the URI (see my example above) OK > > Thank you for your help with these questions. Meanwhile, I will write the first draft of the extension schema assuming (if I can in the limits of XSD) lines 485-516, where lines 498 and 511 are wild cards for any content and <ds:Reference> is mandatory (perhaps in XSD I cannot mix mandatory and any, I'll check this out). > > . . . . . . . . . . . . . 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]