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

[JAVEST by Roberto Cisternino <roberto@javest.com>]

Andrea Caccia ha scritto:

E4B151F4-FCAC-4B40-9C69-220FBB0FCF83@studiocaccia.com" type="cite">

Hi Oriol and Roberto,

Il giorno 05/apr/2010, alle ore 12.46, Oriol Bausà Peris ha scritto:

  

Hi Roberto,

El 05/04/2010, a las 12:33, JAVEST by Roberto Cisternino escribió:

    

Oriol Bausà Peris ha scritto:
      

Hi Andrea,

We have been working with the document in CODICE and there are some issues that I've tried to arise in the release I am currently attaching to this document.

1) When using enveloped signature, it is not mandatory using a cac:Signature element. You can optionally provide for it, but you are not mandated to do so. 
        

This is requested by CODICE in Spain ?
      

It is not a request from CODICE , it is just common sense, we should not use something just because is there, we need to think if it makes sense or we need to rethink about it.
    

I think it makes sense that an UBL application has a standard place to look for to quickly understand if a document is signed and how.
What about:
- recommending cac:Signature for enveloped signatures. If there is a good reason not to use it it can be omitted but, n this case, ext:ExtensionURI MUST be set (see above).
- keeping it mandatory for detached signatures, as there is no other way to mark it as signed

  

This means that you will be able to sign with this profile any kind of UBL document, despite the fact modellers added this structure to the document model. I mean that one thing is the data model of the document, and another thing are the legal provisions that require a signature to be placed there. That's why I recommend to change MUST for MAY when talking about enveloped signataure and cac:Signature element.
  
        

if we follow any local request we will end to be unable to obtain interoperability.
The reason we provide an UBL profile for signatures is to achieve interop.
      

If CODICE do not want to use the UBL profile then it will be not interoperable with other implementers.
      

Yes, we are all trying to build the UBL profile to achieve interoperability, and CODICE wants to use the UBL profile to sign their documents, and that's why there are some concerns arising in this early phase, when trying to implement the points of the recommendation. I think that our considerations should be taken into account to improve the recommendation, and make it easier for implementors to follow and adopt.
    

Any feedback is very welcome, we should be as open as possible avoiding any interoperability issue

  

I told Andrea to use the ext:ExtensionURI to indicate the UBL Profile URI on the extension, so maybe we can say the cac:Signature is not necessary if the ext:ExtensionURI is valorized.
      

That's ok with me.
    

I apologize but there is a mistake, I thought it was done but the text in 4.1 is not updated while the example in the same paragraph is.
The idea is to avoid any constraint on "cbc:ID" inside the UBL extension and set ext:ExtensionURI as shown in the example, i.e. with the URI:

http://docs.oasis-open.org/ubl/securitysc/cd-dsigp-1/enveloped

Do you see any problem to have this as mandatory? 
Another option is to have it just recommended, being mandatory only if cac:Signaure is not present.
  

And yes, this is exactly what I mean, we need a consistent and explicit way to indicate where is/are the signature/s.

E4B151F4-FCAC-4B40-9C69-220FBB0FCF83@studiocaccia.com" type="cite">

ext:ExtensionReasonCode could be also used if necessary to identify the purpose of the signature: payment authorization (for direct Debit) or the signature of the invoice issuer.
      

I also agree with this point.
    

It's a good idea but can we restrict (or suggest) a list of possible codes here?
  

we can propose (recommend) a small codelist to handle main use cases.
code list are then qualified with attributes: agency, version, ... so there is not an interoperability problem.

E4B151F4-FCAC-4B40-9C69-220FBB0FCF83@studiocaccia.com" type="cite">

2) I think there are some mistakes, talking about enveloping instead of enveloped signatures during the document.
        

Thanks for pointing this out
  

3) I haven't added nothing about this yet, but there is a requirement for unsigned data, a placeholder where people can add stuff after having signed the document. I'll come back to you with this issue later on.
        

Can we use unsigned properties inside the signature(s)? This way we can rely on an already defined processing model and we do not have to define anything new.
  

I think Oriol is talking about informations that could be possibly added to a document already issued and even signed.  This information will be located into UBL structures.
If this is the case it seems complex, because the signature process should be always applied to a subset of the UBL document structure.

Into this case the cleanest solution should be the availability of a specific attribute to tag the unsigned information items (ABIEs) but we do not have that.

E4B151F4-FCAC-4B40-9C69-220FBB0FCF83@studiocaccia.com" type="cite">

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com 
Versione: 8.5.437 / Database dei virus: 271.1.1/2791 -  Data di rilascio: 04/04/10 18:32:00

  

--

JAVEST by Roberto Cisternino

* Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor

Roberto Cisternino

mobile: +39 328 2148123
skype: roberto.cisternino.ubl-itlsc
[UBL Technical Committee]	http://www.oasis-open.org/committees/ubl
[UBL Online Community]	http://ubl.xml.org
[UBL International Conferences]	http://www.ublconference.org
[UBL Italian Localization Subcommittee]	http://www.oasis-open.org/committees/ubl-itlsc
[Iniziativa divulgativa UBL Italia]	http://www.ubl-italia.org

PPlease consider the environment before printing this email.