R: [ubl-security] R: [ubl-security] Security SC schedule

Julián,

the specific format you use deals more with the semantic of the document (an order is different from an invoice) and local regulations (Spain and Italy requires qualified signatures, other EUMS not) rather than UBL by itself.

If we suggest to use EPES, I’m sorry but this specification becomes practically inapplicable in Italy, as new rules explicitly exclude it from interoperability requirement.

About signature policy, there was endless discussions in ETSI, this because we can NEVER force with a technicality any technical regulation.

If you look at CEN best practices they require the eInvoice recipient has to verify the signature, you can’t change this with a signature policy (technically you can, legally not).

If we take into account eInvoicing, if I receive an einvoice from your company I know you must insert a security policy because of your regulations and I must accept it, on the opposite if you receive an einvoice from my company you have to accept it without a signature policy.

For an order, it’s up to the parties to have an agreement that specify what to do.

Even PEPPOL, that support the concept of signature policy, does not prescribe to insert it into signatures:

http://www.peppol.eu/deliverables/wp-1/d1-1-part-3-signature-policies

In future they will rely on Service Directive Expert Group prescriptions and, if nothing changed, they ask support for BES in creation and C in verification. Consider also that EU is adopting TSL and this will for sure change something in the ways we verify signatures. In Italy CRLs will keep revoked certificates also after expiration, this way the verifier has no reason to keep CRLs for every signature it verifies, ETSI rules will change to take this into account.

Also for signature verification and document archiving it’s better to avoid any prescription. There are a lot of good ways to deal with this problem and many specific ways to do it and local rules.

I think we have to profile:

- to use enveloped signature (for the reason I already explained)

- how to reference the signature from cac:signature to bind the signature to the document (in case there is more than one, you must know what is the real one)

- to state that, depending on business requirements, the profile support parallel signatures, countersignatures, timestamping and all formats

I read Faccil case study and I fount it very interesting, but you really can’t impose a model, even if it’s a good one, because it can’t be applied to any context. I hae a lot of experience in standard bodies and it simply does not work.

Regards,

Andrea Caccia

--------
This message is sent to one or more specific recipient. If you are not the intended recipient, please notify the sender and delete this message.

--------
Questo messaggio è inviato a specifici destinatari. Se non siete i destinatari, siete pregati di informare il mittente e cancellare questo Messaggio.

Da: Julián Inza [mailto:julian.inza@albalia.com]
Inviato: mercoledì 10 giugno 2009 2.43
A: Andrea Caccia
Cc: 'Jon Bosak'; ubl-security@lists.oasis-open.org
Oggetto: Re: [ubl-security] R: [ubl-security] Security SC schedule

Yes Andrea, you are right.

BES is the minimum but a EPES signature gives the option to define a policy. As in Italy, it is the case in Spain for facturae format which should evolve to UBL soon.

The EPES policy should stablish something like "certificate revocation is checked before signing the UBL document" This does not provide electronic evidence for the validity of the signature but it is simple and mandates some requirements to the signing party which simplifies relying party side if not whishing to check CRL or OCSP in buyer side.

We have checked Oriol approach and have verified that it is compatible with both UBL and TS 101 903, so enveloped signature can be part of an UBL document.

The second selection of XAdES-X-L (also an option in Spanish invoice regulation), means that both timestamping and revocation check is included in the signature of UBL document (invoice, order,...) . If this kind of signature is done in the signer side, we have a "complete" signature with full electronic evidence, so relaying party is freed of knowing all possible signer CAs details. This is important since it is usually easy for a signer to access to his/her CA OCSP and TSA services, but can be a complex task for a receiving party to check certificate validity in an environment in which you can have upto 20 CAs per country (as in Spain), each with different language, roots URLs, Policies, CPS, CRl URL or OCSL URL,...

Both EPES and X-L policies can be defined in a way that makes interoperability "easy", and we can provide tools for developers to test their implementations (we have done so in our Faccil eInvoice implementationn, which includes a SaaS validator)

If everybody agrees with these approach, maybe these principles should be included in the presentation you prepared.

Best regads

Julian Inza Aldaz
Presidente
Albalia Interactiva, S.L.

: www.albalia.com : blog.inza.com
: julian.inza@albalia.com
: +34 91 388 0789 : +34 902 365 612

Please update your address book. Our new postal address is: C/ Mentrida, 6 - 28043 - Madrid (Spain).

Este mensaje de correo electrónico puede contener INFORMACIÓN CONFIDENCIAL propiedad de Albalia Interactiva. Si lo ha recibido por error, por favor haga caso omiso, elimínelo y notifíquelo al remitente. La información personal puede ser añadida a un fichero de relaciones (que puede incluir información de marketing) en Albalia Interactiva, donde usted puede ejercer sus derechos de acceso, rectificación y cancelación de sus datos al amparo de la Ley Orgánica 15/1999. Usted está autorizado a utilizar los datos personales del firmante de este mensaje siempre que haya una manera de ejercer los mencionados derechos por el remitente.

This e-mail message could contain CONFIDENTIAL INFORMATION property of Albalia Interactiva. If received by mistake, please ignore it, delete it and notify the sender. Your personal information can be added to a relationships file (that can include marketing information) at Albalia Interactiva where you can exercise your rights to access, rectify or cancel your data according spanish 15/1999 Organic Law. You are authorised to use personal data of the signer of this message as long as there is a way to exercise the mentioned rights by the sender.

Andrea Caccia escribió:

I was working on the same subject but I’m afraid I didn’t have enough time until now.

In previous emails we exchanged some point where we reached some consensus:

- to recommend enveloped signature, respecting UBL syntax and XAdES syntax, so that an UBL tool can validate a signed UBL, and a XAdES tool can verify an UBL document

- to avoid to prescribe any specific envelope. XAdES-BES is the minimum, but we should avoid to give too much detalil because they depend on the kind of document, national regulations, other standard body activities (i.e. CEN eInvoicing2). Maybe we can raccomand to use XAdES-BES for signature generation whenever possible to achieve the widest possible interoperability and suggest TS 102 904 as general best practice for implementations.

About signature policies, do you think we need them? New Italian rules (due for publication very soon) explicitly XAdES-EPES...

Regards,

Andrea

--------
This message is sent to one or more specific recipient. If you are not the intended recipient, please notify the sender and delete this message.

--------
Questo messaggio è inviato a specifici destinatari. Se non siete i destinatari, siete pregati di informare il mittente e cancellare questo Messaggio.

Da: Julián Inza [mailto:julian.inza@albalia.com]
Inviato: martedì 9 giugno 2009 12.24
A: Jon Bosak
Cc: ubl-security@lists.oasis-open.org
Oggetto: Re: [ubl-security] Security SC schedule

Hello Jon,

Yes, I think we are behind schedule. So it would be wise to delay some milestones.

I have been talking to Oriol to define the scope of the document and I have some ideas to share with the group.

I hope I will have a pre-draft document by the end of this week, to circulate for comments.

The idea is based on this Oriol post: http://www.invinet.org/index.php?option=com_content&task=view&id=14&Itemid=10

(sorry it is in spanish) and defining two levels of signature: XAdES BES and XAdES X-L (this with full evidence of certificate validity at signature time), acording standard TS 101 903.

We will need a stable OASIS URL for signature policy.

Best regards,

Jon Bosak escribió:

Hello UBL Security Subcommittee,

Are we still on schedule to begin public review of the UBL XAdES
profile? If delivery has slipped, please advise so that I can
update the time line.

Best regards,

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

ubl-security message