OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Having thought more, it make sense to consider the enveloped form only with XAdES (or the basic XMLDSIG).
Fot detached forms the cac:Signature should be enough, we should consider to update later the document or to prepare a new one if UBL TC ask us to do so.
Of course it was clear right from the beginning that one of the goal is to avoid any change in UBL.

About the issue under discussion this is my position:
1) it makes sense to consider multiple signatures. In case of countersignatures (i.e. signatures on signatures) they are already covered by XAdES. In case of more than one signature applied to the document, it makes sense to have a single cac:Signature and all the signatures packaged in a single extension under the same identifier. Note that for the sake of simplicity this version of the profile covers  only the case where the full document is signed but, if there is a need for so, partial signatures can be covered in future. In this case I think the best approach is to group the signatures that relates to the same to-be-digned data in the same extension (pointed by the same cac:Signature) but use different extensions for signatures related to different data (each pointed by a different cac:Signature).
2) about the question if mandating the presence of ext:UBLExtension/cbc:ID for the specific extension containing the signature in implementations conforming to our profile, I think it does not. We are simply using the option to have this ID in this specific context and any schema check have to validate this against current UBL schemas. But, if the need is to avoid to put any constraint on the extension ID because the implementor has to be free to assign its value without any constraint, and the same for Signature ID, then the wrapping structure becomes mandatory: in this way both the signature and the extension IDs can be assigned following completely different rules (and also omit the extension ID of course).
3) It makes sense to use cac:Signature. It is part of standard UBL and is the starting point for an implementation to understand if the document is signed (presence of the TAG) and how (this and any future profile must mandate the presence of an cbc:SignatureMethod specifying an URI that identifies a specific method. For the eventual support of detached signatures cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI can point to the detached signature.
4) avoid to reuse "Signature" as tag name for the wrapping structure, as it can be confusing; a generic structure can be defined instead
 

Point 1 alone justify to wrap the signature, so I propose to:
a) Have a single cac:Signature with a cac:ID pointing to wrap:Envelope/cbc:ID, contained in an UBL extension, containing one or more signatures that applies to the whole document (excluding the signature itself of course, using already defined XAdES/XMLDSIG rules). The content could be:
<cac:Signature>
 <cbc:ID>”AnySignatureID”</cbc:ID>
 [...]
 <cbc:SignatureMethod>http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1</cbc:SignatureMethod>
 <cac:SignatoryParty>
  <cac:PartyIdentification>
   <cbc:ID>
   "For parties already specified into the document provide the cac:Party/cac:PartyIdentification/cbc:ID, otherwise the party can be compiled more deeply."
   </cbc:ID>
  </cac:PartyIdentification>
 </cac:SignatoryParty>
[...]
</cac:Signature>

b) Have a generic wrapping structure that can be reused in similar cases, be part of UBL 2.1, and could be something like:
<wrap:Envelope>
 <cbc:ID>”AnySignatureID”</cbc:ID> [mandatory and unique among all extensions in the document]
 <wrap:Item> [at least one present]
  <cbc:ID>”AnyItemID”</cbc:ID> [optional; absent for this profile]
  <wrap:MimeType> mime type of the signatures</wrap:MimeType>[optional, it's the mime type of Value]
  <wrap:Encoding> encoding of the signatures</wrap:Encoding>[optional, if not present Value contains well formed XML, must be present for binary content and specify the base64 filter]
  <wrap:Value>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
                     xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";>
         [...]
   </ds:Signature>
  </wrap:Value>
 </wrap:Item>
 <wrap:Item>
...same as above...
 </wrap:Item>
</wrap:Envelope>

Does it makes sense?

Andrea




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]