Re: [ubl-security] Re: [ubl] Re: Making references

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

At 2009-12-03 16:31 +0100, Andrea Caccia wrote:
>It seems we all in the SC are on quite different 
>positions... I answer inline both to Oriol and Ken.

Thank you for your perspective on these issues.

>Il giorno 02/dic/2009, alle ore 23.00, Oriol Bausà ha scritto:
> > I am sorry but my personal opinion on all 
> that issue is that you are getting all that 
> more and more complex, and I cannot understand why this should be that way.

I'm not discounting your perspective, Oriol, and 
I recognize that you have concerns with this, but 
I don't believe it is complex and I believe we've 
been following the information analysis and 
derivation techniques that were used to create 
UBL in the first place.  I hope to lessen your 
concerns and we should be sure to document how to 
do so in order to assure readers of the end 
result.  Your concerns you have now will be very 
valuable in improving the documentation.

> > I cannot understand why you need a wrapper 
> inside a wrapper of another wrapper.
>I'm not an UBL expert so on some points I'm more 
>trying to understand and explore the solutions 
>we have than sponsor a specific solution.

Well said.

>Said that, let see if we can simplify.
>In the current document we consider only 
>signatures on the whole document. This allows us to make some assumption.
>We can avoid to mandate a link between cac:Signature and the signature itself.

Interesting!

>In fact the application can read 
>cac:Signature/cbc:SignatureMethod URI and 
>configure itself to search for any ds:Signature present in each UBL extension.

That I am uncomfortable with ... if I've created 
a Crane extension and I use ds:Signature in my 
Crane extension to sign a fragment of my Crane 
extension, I would not want that signature to be 
construed as a signature on the entire document.

>Schema validation of extension content is 
>delegated to the XAdES verifier to whom the 
>entire content of the extension is sent.

I'd like to see it packaged in UBL 2.1 as I 
mentioned on the TC teleconference ... more about that below.

>In case we have multiple signatures, the process 
>is repeated. I think we can have a single 
>cac:Signature for the set of signatures, as:
>- they in fact apply to the whole document, and
>- no signature can be added in a second time, as 
>adding it modifies the document and invalidates 
>the previous one. So they can be considered 
>"atomic" in the sense that, after the message is 
>completed, no other signature can be added.
>
>This is the simplest form I think is workable 
>bot for the signer and the verifier.
>
>On the other hand if we want to have all the 
>co-signatures in the same package then a 
>wrapping structure is needed. But there is also 
>the possibility that XAdES will include 
>co-signatures in future (and this can be also a 
>request from this SC to ETSI/ESI): this way 
>should be the most correct way to go.

I'm glad it meets a need.

> > I would recommend to keep this as simple as 
> possible, and maybe the recommendation should 
> be NOT using the cac:Signature component at all.
>
>I agree with you on keeping all as simple as 
>possible but it should be simple both to 
>generate and use it so I do not agree not using 
>at all cac:Signature because it is already part 
>of the UBL syntax and can give us some useful 
>information for the receiving application.

Absolutely ... plus, if the Security SC publishes 
a number of methods in its report:

   (1) - external implied signature(s)
   (2) - external specified signatures via SignatureMethod
   (3) - embedded specified signatures via SignatureMethod and extension

... using ds:Signature solely for illustration, 
then a UBL user community can profile the 
Security SC document choosing one of the methods 
by having been educated on the possible ones 
available and thus weigh the benefits and drawbacks.

Coming back to my very first comment in my first 
post, this would meet my need of a document:

At 2009-11-30 06:11 +0530, I wrote:
>First let me say that I do not have a background 
>in digital signatures, and I've approached this 
>document as an implementer wanting to learn how 
>digital signatures are to be used with UBL.

At 2009-12-03 16:31 +0100, Andrea Caccia wrote:
>There are many ways to sign an UBL document and 
>we are defining a profile that recommends 1 or 
>possibly 2 ways (if we decide to support 
>detached signatures) and in future both us and others can define new ones.

Sounds good to me!

>I think it has to be recommended (and maybe 
>mandated) that cac:Signature is present when the 
>message is signed and that 
>cac:Signature/cbc:SignatureMethod contains an 
>URI that identifies in an unique way how the 
>message is signed. This way an UBL aware parsing 
>application can detect if it is able to verify 
>the signature and make some decision.

Sounds a bit too harsh for me ... a community of 
users may wish to simply assume that every 
document shall be externally signed.  Not only 
would I not want to burden all members of the 
community with having to indicate the assumed 
signature method but it might make it difficult 
to import UBL documents from other user 
communities that didn't follow that rule yet could still be externally signed.

> > El 02/12/2009, a las 18:26, G. Ken Holman escribió:
> >> Is there an opportunity (i.e. enough time) for the one document to guide
> >> UBL users in both embedded and detached signatures so that they can make
> >> an informed decision regarding which way to go with their own work?...
>OK but I'd like first to reach an agreement on 
>the enveloped signature, in the meantime it 
>should be better to check with the TC if 
>considering also detached signatures (at this 
>point not only XAdES but also CAdES) is in out scope

Well, remember the TC is looking to the SC for 
direction.  I think the SC should present a 
document with all options and then the TC can 
decide if the UBL community is best served with 
all or a subset of options.  I believe the spirit 
of UBL is to present *all* options.

Any user community (Europe, Spain, Crane, etc.) 
can then choose to say which way UBL documents 
will be signed in their respective worlds using 
one of the recommended methods documented by the TC (written by the SC).

> >> Interesting!  I didn't realize there was a one-to-many relationship here.
> >> In my naïveté I thought it was always one-to-one.
>Maybe here we have also to be sure we are not 
>violating the semantic of cac:Signature. I think 
>that a joint signature has to be considered 
>atomically (and this has to be stated in the profile too)

Agreed.

But perhaps my point was lost ... I wasn't 
introducing sig:Signatures to imply a *joint* 
signature, but merely a single home for all 
sig:Signature constructs so that a processing 
application will find all sig:Signature 
constructs under a single extension point.

Perhaps sig:Signatures/cbc:ID is the identifier 
of a joint signature while sig:Signature/cbc:ID 
is the identifier of a singleton signature.

In the legal world of security does a joint 
signature have a different semantic than a 
combination of individual signatures?  If not, 
then we don't need sig:Signatures/cbc:ID:

    wrap:Envelope
      wrap:Item+
        cbc:ID
        wrap:XMLValue?
        wrap:Base64Value?

(where wrap:Envelope is what I would call 
sig:Signatures and wrap:Item is what I would call 
sig:Signature, but we'll worry about names later).

Another question:  if the envelope can have an ID 
does that make the IDs of the items optional and 
omitted when the envelope has one?

In any proposal we take seriously, we will need 
to create some number of test scenarios to 
exercise the combinations of the required and 
optional elements and ensure the document model 
proposed meets all needs.  Then we include all of 
these in the documentation so that users understand typical scenarios.

> >> I think we still need to have this as a 
> standalone Security SC specification of an 
> extension, and then include the use of that 
> extension in the delivered UBL 2.1 schemas.  I 
> don't think it should be part of the UBL 2.1 
> specification (other than the inclusion in the schemas).
>I was in fact referring to what you previously 
>wrote. But if it becomes part of the UBL2.1 
>schemas I think it's better if it is more 
>generic and not completely related to signatures

Please forgive me for confusing you when I use so 
many words (I know I do this too often).  Let me 
summarize my opinion regarding publishing our results:

   (1) - we develop the first standardized extension vocabulary and
         extension schema fragment: one for security
   (2) - we don't include the extension in the common library of business
         objects for UBL 2.1
   (3) - we do include the extension in the schema suite for UBL 2.1 and
         explicitly engage it from the published UBL 2.1 extension fragment
         (which can be picked up and dropped into a UBL 2.0 environment
          replacing the UBL 2.0 extension fragment without change; if that
          weren't the case, then we haven't developed a true UBL extension)

> >> Is it your intention in the published specification to cite <ds:Signature>
> >>  as *the* way sign a UBL document or *one* way to sign a UBL document?
>I think this profile (and future updates) should 
>be way(s) suggested by UBL TC but can't be the 
>only one as it is a recommendation so any user domain can specify its own way.

Excellent ... I totally agree ... thus we should 
have a number of options available.

>Ok, understood. The MimeType may be useful if we 
>think this structure can be reuse elsewhere, in our case it is useless

Indeed.

> >> When the Security SC ends up deciding on the structure to use, we should
> >> go through the appropriate naming exercise to determine the names to use
> >> for the elements...
>Ok. As I wrote before I prefer this point is 
>decided among who knows better UBL insights in the SC.

But remember the Security SC members are the 
subject matter experts, not TC members such as 
myself.  When I try and facilitate model 
development I leave the naming of constructs to 
the subject matter experts, expressing my 
opinions when I perceive (as an outsider) 
possible ambiguities or challenges with the names 
proposed.  The specification should be 
idiot-proof and from how often people tell me I must be a good one!

Thanks, all!  I'm finding this very fruitful and 
I'm learning a *lot* about XML document 
security.  I'm confident the specification you 
produce will be invaluable to the UBL community.

. . . . . . . . . . Ken

--
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
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