Re: [spam] Re: [ubl-security] A Simpler Solution [was: Questions regarding the XAdES Profile]

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2010-08-27 17:42 +0200, Roberto Cisternino wrote:
> > f) - Do not introduce ambiguity in the solution.
>
>this can be solved easely, I just described how we can use existing
>cac:Signatures to solve main issues.
>I skipped other specific things here that have been already described before.

And I believe those specific things that were described before were 
shown to fall short of what is required for a solution.  You and I 
had email exchanges on some of these months ago.

Forgive me, Roberto, but my request to this list today was for 
*specific* direction on how the Security SC wants me to change the 
already proposed extension schemas to deliver to Jon in the shortest 
possible time.

> >>>Solution steps:
> >>>
> >>>1) Change the xpath filter to be used for signing an UBL document this
> >>> way:
> >>>  - Remove from the signed data any cac:Signature metadata
> >>>  - Remove from the signed data all ext:UBLExtensions
> >>>
> >>>This filter should solve a) c)
> >
> > Other UBL extensions are first-class parts of the UBL document and
> > should, I believe, never be excluded from the signature.  When I sign
> > a document, the signature area is excluded, but anything that isn't
> > signature related (which includes all extensions) I believe must be
> > signed and protected.  If I have line item extensions under another
> > extension point, I would not want them excluded from the signature.
>
>I agree, but this can be solved in two ways:
>
>a) Sign just extensions containing signatures

I think not, because we have to sign business objects, not 
signatures.  Because of the "here()" function in the W3C 
specification, and the hunt for a common ancestor, we cannot have 
separate extensions each containing signature information.

>b) add a separate ext:UBLSignatureExtension to solve ambiguities

I would need to see your details to understand this, as I don't know 
where you are going with it.

> >>>2) Continue using the cac:Signature as metadata where required
> >>>
> >>>    This solves b) e)
> >
> > I'm unclear on your point here.
>
>cac:Signature is about metadata for the signature, also it is used in
>different document contexts not just the root (see CoO) so I think could
>be still valuable its usage in UBL.
>I proposed to remove any cac:Signature from the signed content (through an
>xpath filter) to allow people using cac:Signature extensively at any time
>in the document life-cycle.

This direction is not consistent with how I've seen signature hash 
functions in ODF and OCF.  Implementers may find such a transform 
expression a challenge.  How would you write the necessary hash 
transformation expression?

>This is possible because cac:Signature will not invalidate anymore any
>previous signature.
>So we can avoid inserting too much rules to limit its usage or deprecate
>it in some way.
>My opinion is UBL is correct with cac:Signature from the business point of
>view, so we should just find the way to play signature in an easy way for
>software developers.

My interpretation of the cac:Signature children (metadata) is that 
they would only apply if you were *not* using XAdES.  It duplicates 
the information found in the W3C Digital Signature 
specification.  And, as soon as a single signature is applied to the 
document, this metadata cannot change for other signatures or it 
invalidates the first signature.

Somewhere back in this thread it was observed that cac:Signature is 
structured the way it is to accommodate many kinds of signatures, and 
only the identifier is useful (and stable) when using XAdES and W3C 
Digital Signatures.

When you propose to remove cac:Signature from the signed content, 
which descendants of cac:Signature do you expect to be using or 
modifying in the life cycle of applying multiple signatures?  Here is the list:

  ID An identifier for the Signature.
  Note Free form text about the signature or the circumstances where 
the signature has been used.
  ValidationDate Specifies the date when the signature was approved.
  ValidationTime Specifies the time when the signature was approved.
  ValidatorID Identifies the organization, person, service or server 
that has validated the signature.
  CanonicalizationMethod The mathematical logic method used by the Signature.
  SignatureMethod The method of signature.
  SignatoryParty An association to the signing Party.
  DigitalSignatureAttachment Refers to the actual encoded signature 
(e.g., in XMLDSIG format).
  OriginalDocumentReference

>Sorry Ken if I just provided a macro solution but I know I am not the only
>one so I am sure you and others can help to refine my idea if well
>accepted.

The time for macro solutions was a year ago when these specifications 
were being conceived, or even a month ago when we saw the need for 
packaging coming up, not after PRD1 packaging has already begun.

I will soon be late supplying to Jon the W3C Schema fragment 
supporting the decisions of the Security SC.

I need explicit direction as soon as possible regarding what exactly 
is to replace the current proposed mechanisms and 
expressions.  Please tell me what I change for Jon ... he is waiting 
for me to deliver the schemas.

A number of the issues brought up in the last 48 hours are issues 
that were brought up months ago and already answered or addressed.  I 
think the time for macro solutions is long passed.  We need something 
that can be tested by our users.

. . . . . . . . . . . . . . Ken


--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/m/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/m/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal