Re: [ubl-security] Questions regarding the XAdES Profile

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

Hello Jon,
I confirm that the draft you mention in point 2 is the latest one produced and that some change is required to adopt the mechanism you mention in point 1.

No full agreement is reached as Oriol reported some concern on the scaffolding structure:
http://lists.oasis-open.org/archives/ubl-security/201008/msg00031.html

I summarize very quickly what is the solution we are discussing:

1) all UBL documents will have a document-wise cac:Signature (optional) element and the general scaffolding structure inside the UBL extension is:
<sig:SignatureInformation>
<sig:SignatureGroup>
  <ds:signature>…</ds:signature> (one or more)
</sig:SignatureGroup>
</sig:SignatureInformation>

2) only for documents where more than a single cac:Signature for different purposes can be present (at present just COO) the scaffolding can include an ID to reference to the relevant UBL document part that the signature refers to:
  <sig:SignatureInformation> 
    <sig:SignatureGroup> (one, if needed)
      <ds:signature>…</ds:signature> (one or more)
    </sig:SignatureGroup>
    <sig:IdentifiedSignatureGroup> (one or more, if needed)
      <cbc:ID></cbc:ID>
      <sig:SignatureGroup>
        <ds:Signature> … </ds:Signature> (one or more)
      </sig:SignatureGroup>
    </sig:IdentifiedSignatureGroup>
  </sig:SignatureInformation>

Every signature apply to the whole UBL document including its extensions and excluding the content of any sig:SignatureGroup present to allow to add and remove signatures (and counter-signatres) at any point in time without breaking other signatures.
The main reason for adding this scaffolding is that electronic signature software does not know anything about UBL syntax and adding a simple external structure, common to all UBL documents, greatly simplify the effort required for the integration. Another key issue is to minimize the effort to prepare a message for signatures (that's the reason to allow to not use the cac:Signature element) and allow to add and remove signatures at any time, to accomodate workflow management.

In case 2) I think we need to agree also on the way cac:ID is used, it has not stated and decided yet.
I propose the <cbc:ID></cbc:ID> can reference to whatever <cbc:ID></cbc:ID> present in the UBL document and the sig:SignatureGroup bound to this cbc:ID is associated with the UBL document section identified by the same cbc:ID. As all signatures applies to the whole document, this is just a logical association, meant to establish the purpose of the signature.
Standard XAdES mechanisms such as the signature policy and/or the signer role can be used for any legal issue to be dealt with. Also in this situation any cac:Signature is optional.

I'm asking to all in this SC to please express his position by this week in order to start editing work next week, if an agreement is reached.

Andrea


Il giorno 23/ago/2010, alle ore 16.39, Jon Bosak ha scritto:

> Hello Security SC,
> 
> To include the proposed XAdES Profile in UBL 2.1 PRD1, I need
> answers to the following questions:
> 
> 1. Is the Subcommittee in agreement with the mechanism advanced by
>   Ken Holman in his message of 20 August?
> 
>   http://lists.oasis-open.org/archives/ubl-security/201008/msg00035.html
> 
> 2. Will adoption of this mechanism require changes to the Profile
>   draft?  The latest version of this document appears to be
>   UBL-XAdES-Profile 1.0-RC2.doc of 26 May 2010:
> 
>   http://lists.oasis-open.org/archives/ubl-security/201005/msg00015.html
> 
> Jon
> 
> ---------------------------------------------------------------------
> 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