Re: [ubl-security] New draft (UBL-XAdES-Profile 1.0-20100321)

[Andrea Caccia <andrea.caccia@studiocaccia.com>]

Thank you Ken.
Here follows my comments.

Andrea

Il giorno 07/apr/2010, alle ore 04.50, G. Ken Holman ha scritto:

> Hi folks.
> 
> Please forgive my tardy response over the holiday week and weekend and my earlier overseas travel.
> 
> At 2010-04-06 00:35 +0200, Andrea Caccia wrote:
>> I try to summarize, so I am able to update the draft:
>> - for enveloper signatures, there are will be 2 RECOMMENDED places for the URI defined by this SC:
>> - in cac:Signature/cbc:SignatureMethod , and
>> - in ext:UBLExtensions/ext:UBLExtension/ExtensionURI
> 
> Sounds fine so far I suppose.  The definition for ExtensionURI is simply "A URI for the extension", which doesn't say a lot.  I can accept that the purpose of the extension is identified uniquely by a URI.  The ExtensionVersionID would then help in the interpretation of the extension defined by the URI.  If there are different implementations of the same kind of URI then the version would be used to distinguish them.
I prefer that the concept of version is included in the URI, this way even if he have the URI only into the cac:Signature we do not miss any information

> 
> Would this mean you should have ExtensionVersionID equal to, say "1.0" or, if absent, be assumed to be "1.0"?
> 
>> at least one MUST be present. If both are present and not equal the verification fails.
> 
> But what if there is another UBLExtension with a different ExtensionURI for a different purpose?  Would the above rule trigger?  How would you avoid triggering the above rule?
I do not want to prevent additional extension to be present provided that there is only one extension as document signature. If cac:Signature is present, then there MUST be one (and only one) extension containing <document-signatures> tag, possibly with ExtensionURI. The rules are:
- start form cac:Signature if present with UBL Security SC URI, search for an extension with identical ExtensionURI or without ExtensionURI but with <document-signatures> tag as root of the extension content
- if no cac:Signature is present search for an extension with ExtensionURI with UBL Security SC URI

> 
> Say I have an extension for Crane's timesheets, and an extension for a signature with an absent ExtensionURI.
> 
> Should the rule perhaps be:  the ExtensionURI is omissible if there are no other extensions in the instance, but if there are other extensions it is mandatory.
Only one extension containing <document-signatures> as root of the content is allowed, other extensions can be present with whatever content

> 
>> - for detached signatures cac:Signature/cbc:SignatureMethod MUST be present
>> - for enveloped signatures ext:UBLExtensions/ext:UBLExtension/ext:ExtensionReasonCode MAY contain an identifier for the purpose of the signature. A code list qualified with attributes: agency, version… --> I ask Roberto to provide some text here
> 
> Good.  We will include that in the special-purpose directory.
Purposes under discussion:
- Payment Authorization
- Document Issuing
- Document Approval
- Document origin and integrity only

> 
>> I'm expecting also some comments from Ken
> 
> The last version I have is labeled "XAdES-Profile 1.0-20100321-ob.doc".
> 
>> and the correct xpath from Juan Carlos,
> 
> I see a reference to XPath on line 441, but I'm not sure what it is supposed to be pointing to.  I think there is an assumption to something the reader must know in advance to reading this specification.  The wording is "applying a single transformation" and I don't know what that means in this context.
It is assumed some knowledge on XMLDSig, I try to be more clear and explicit

> 
> Line 447 should read <ext:ExtensionURI> and not <ExtensionURI>
ok
> 
> Line 420: Why is ext:UBLExtension/cbc:ID mandatory?  It has no semantic other than uniquely identifying one extension from another.  It has no persistence nor outside referential integrity.
my mistake, I updated the example but not the text. my intention was to introduce ExtensionURI instead.
> 
> Line 435 makes reference to "the root of the UBL document instance".  This should be reworded.  Do you mean that cac:Signature must be a child of the doucment element (the "document element" is the top-most element that wraps all content)?  I see that is true for 29 of the 31 document types (not for CatalogueRequest nor CertificateOfOrigin).  I also see there are signatures allowed in <cac:Endorsement> and <cac:CertificateOfOriginApplication> ... does the methodology exclude using those?
rewording is required. As cac:Signature is now not mandatory, no document is excluded at all.
> 
> Line 474 states there can only be a single UBL extension in the document ... what if I have my Crane timesheet extension as well in the document.  Am I not allowed to sign that?  Could this be relaxed stating that one of the UBL extensions must be the signature extension?
a single extension with UBL Security URI (in it or referenced trough cac:Signature). I'll check and change wording to make it more clear
> 
> The declaration restriction for lines 479 are arbitrary and not controllable.  From an XML processing perspective, there is no difference if the namespace is declared there or in the document element of the UBL instance.  For example, the DOM, SAX and XSLT/XQuery/XPath data models for XML are all equivalent, regardless of where the declaration exists.  Can you explain why you think it is mandatory to be embedded in the document?
Let me check this with Roberto.
> 
> BTW, you should change all uses of the word "root" if you mean the "document element" of the instance if that is what you mean.  And if that is not what you mean, then you need to use different words again.
> 
ok
> I see a reference to XPath on line 483, and I think an improved XPath address would be as follows:
> 
> /*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/odsig:digital-signatures
> 
> ... because "//" should be avoided and the above is unambiguously the only place where the extension content is found.
> 
I'll check this with Roberto

> Line 498:  if there are two signatures, is it acceptable that both have the same ID?  The typical semantic for an identifier is that it be unique.  Unless you have a reason to specify the value, can it not just be left up to the user?  It is meant to distinguish between signatures, not meant to identify the kind of signature.  The definition reads "An identifier for the Signature" ... thus it is meant to distinguish the signature, not the signature method.
multiple signature fall under the same extension, Id of signatures are arbitrarily set by the  signer
> 
> Line 504:  again, I believe you cannot fix the ID value to any string at all.  I believe it is meant in this case to distinguish the party, not distinguish a property of the party.  If I had two signatories, they cannot (should not) have the same identifier.
I'll check wording
> 
> I see line 559 indicates the party identification is being used as a modifier and not as an identifier.
> 
> For example, if there are two signatures by the same person, the signature <cbc:ID> values would be distinct and the PartyIdentification <cbc:ID> values would be the same.  If there are two signatures by two different people, the PartyIdentification cbc:ID values would be different.
> 
a single cac:Signature is used for wathever number od signatures are applied to the document. This solves the problem of knowing in advance how many signatures will be present in the document, in fact you can't any more change the document after the first signature is applied.

> To back up my assertion about these cbc:ID values, consider the CCTS definition of the IdentifierType used for cbc:ID in:
> 
> http://docs.oasis-open.org/ubl/os-UBL-2.0-update/xsd/common/UnqualifiedDataTypeSchemaModule-2.0.xsd
> 
> and you'll see:
> 
>  A character string to identify and distinguish uniquely,
>  one instance of an object in an identification scheme from
>  all other objects in the same scheme together with
>  relevant supplementary information.
> 
> Thus, I feel you should not be fixing any cbc:ID value in the specification and different cbc:ID values will be decided on by the user (not the specification) when there are multiple signatures.
the puspose is to identify the unique cac:Signature, but I have no objection to leave to the implementor the choice.
> 
> I hope these comments are considered helpful.  As an outsider unfamiliar with digital signatures, I'm not confident the document as it stands would direct me to properly implement the given schemes.  I'm not sure if a diagram or two would help or not.  If pre-awareness of the signature specifications is a requirement to understand how this specification works, that should be made more clear.
> 
> . . . . . . . . . . . . Ken
> 
> --
> XSLT/XQuery training:         San Carlos, California 2010-04-26/30
> Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03
> XSLT/XQuery training:                 Ottawa, Canada 2010-05-10/14
> XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11
> 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
>