Oriol Bausà Peris ha scritto:
5F568062-E010-4E72-B404-A7C2AC8D656E@invinet.org"
type="cite">Hi Roberto,
El 05/04/2010, a las 12:33, JAVEST by Roberto Cisternino
escribió:
Oriol Bausà Peris ha scritto:
21444F8C-4731-4946-B19E-B7E961138CA8@invinet.org" type="cite">
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 see this Oriol, but we have many cases to accomodate, and the
enveloped signature methodology inside the UBL Extension is just one.
This is why we thought that the cac:Signature can be used to reference
different kind of signatures using the SignatureMethod with a set of
recommended URIs provided by UBL Security.
5F568062-E010-4E72-B404-A7C2AC8D656E@invinet.org"
type="cite">
21444F8C-4731-4946-B19E-B7E961138CA8@invinet.org" type="cite">
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.
I agree, so do you have another way to provide an explicit way of
indicating how a signature has been applied to an UBL document ?
The use of cac:Signature is providing a sufficient answer to this... I
know there are many unused fields...
Also I have a question: Are we sure that cac:Signature is not used at
all around the world... e.g. for simple XMLDSIG signatures ?
5F568062-E010-4E72-B404-A7C2AC8D656E@invinet.org"
type="cite">
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.
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.
Ok, but what about other kind of signatures <> enveloped ?
5F568062-E010-4E72-B404-A7C2AC8D656E@invinet.org"
type="cite">
21444F8C-4731-4946-B19E-B7E961138CA8@invinet.org" type="cite">
2) I think there are some mistakes, talking about enveloping instead of enveloped signatures during the document.
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.
I've made some modifications in the document according to the first two points. I 'd like to get feedback from the other security subgroup members.
Thank you
Oriol
El 26/03/2010, a las 15:16, Andrea Caccia escribió:
The attached draft is my best effort to consider all issues that come up.
The version whose filename ends with "RevCtrl" has been done with Word revision control activated so who already read the old version can find quickly the differences.
I kindly ask all to all to read it carefully as this is hopefully very close to be finalized. If anyone want to comment directly on the document is welcome but on the version without with all the changes already accepted, otherwise it would be very difficult to see the changes.
I need help especially on XML parts, ad I do not have a very detailed knowledge, there could be some issue. I need also the XPath expression for the Enveloped signatures, as I mentioned early XMLDsig has a specific processing rule for it.
I look forward to hear from you.
Andrea
<UBL-XAdES-Profile 1.0-20100321.doc><UBL-XAdES-Profile 1.0-20100321+RevCtrl.doc>
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
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
|