[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [bdxr-comment] SV: [members] 30 day Public Review for Business Document Envelope V1.1 - ends May 20th
Dear colleagues, After Erlend further explained some of the TC’s issues with this, I would like to elaborate on why I think it could still be feasable to
change the cardinality of the ToParty in the BDE from exactly one (1..1) to one or more (1..n). Certainly not all, but many modern encryption methods, support encryption to one or more (1..n) recipients simultaneously.
1.
PGP.
2.
CMS 3.
XML Encryption In summation, using any of a number of widely used and best practice encryption methods used for the PayloadContent, one-to-one confidentiality would indeed
be obtainable. What I now see as problematic is the clean integration with the BDE as it stands now. The BDE Payload class has promoted some security aspects like integrity and specifically encryption key management over some claim-check pattern transport protocol,
albeit optionally. These are interesting choices and it must be difficult to determine when and where to stop promoting aspects of security or transport onto the business layer. Now, one could promote further elements from security into the BDE for one-to-many consistency. Certainly the Payload/*ExternalReference elements, or rather
their ExternalReferenceType could be extended with a reference to the ToParty and made of cardinality (1..n). However, I see a problem in that if the Login and especially Password elements would be carried, necessarily in the clear, visible to all receiving
parties, it would no longer be secure. The only way to mitigate this would be to add XML Encryption to the Password element at least, but that would probably og against the intention of delivering a very light-weight «secure» access method to external payloads/keys/whatever
in the BDE itself. In conclusion, I now recommend two changes to the BDE draft as it stands: 1.
Change the cardinality of the ToParty in the BDE from exactly one (1..1) to one or more (1..n). 2.
In general: Restructure any and all use of other layer aspects, i.e. both security and transport, by either removing them completely, or by adding
dedicated, but optional, flexible and extensible sections to the BDE, clearly separating the concerns. In particular: At this point, I am tempted to recommend you remove PayloadType/InstanceHashValue, InstanceHashAlgorithm, all of the Instance…ExternalReferences and RelevantExternalReference. Best regards Torsten -- Med vennlig hilsen Torsten Kirschner
Elektronisk Samhandling // Forvaltningsseksjonen Fra: Kenneth Bengtsson [mailto:kbengtsson@efact.pe]
Dear Torsten As promised the TC today began working on the comments received during the public review of BDE 1.1. Specifically regarding your comment about changing cardinality
of the ToParty element to one or more (1..n), the question was raised whether such change would invalidate the confidentiality feature of BDE, obtained using payload encryption where the key of the recipient is used for the encryption ensuring that only the
intended recipient is capable of understanding the content. If a BDE envelope was to have more than one recipient (ToParty), such one-to-one confidentiality would not be obtainable. Erlend Klakegg Bergheim of the BDXR TC will contact you directly to better understand your requirement and how we may work out a solution. Best regards, Kenneth Bengtsson From:
<bdxr-comment@lists.oasis-open.org> on behalf of Kenneth Bengtsson <kbengtsson@efact.pe> Dear Torsten Thank you very much for your valuable input. The cardinality of the ToParty was indeed an issue that was discussed by the TC during the work on BDE
1.1. I will put your input in the list of comments received so that the TC may open this issue for further discussion after the public review, after which we will publish a resolution log with all comments and conclusions. I will let you know when the comment
resolution log has been published, as well as of any questions to your requirement that may arise during the work. Best regards, Kenneth From:
<bdxr-comment@lists.oasis-open.org> on behalf of "Kirschner, Torsten" <Torsten.Kirschner@nav.no> Dear BDXR TC, I have the following comment on the BDE v1.1: In the European EESSI project – Electronic Exchange of Social Security Information, run by DG EMPL, we have a need to address multiple recipients of a document
on business level. If you could change the cardinality of the ToParty in the BDE from exactly one (1..1) to one or more (1..n), we could use the BDE in EESSI instead of a profile
of the UN/CEFACT Standard Business Document Header (v1.3). Best regards Torsten -- Med vennlig hilsen Torsten Kirschner
Elektronisk Samhandling // Forvaltningsseksjonen |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]