bdxr — archive

Re: SV: [bdxr-comment] SV: [members] 30 day Public Review for Business Document Envelope V1.1 - ends May 20th

From: Kenneth Bengtsson
To: [email protected]
Date: Thu, 23 Jun 2016 16:00:00 -0000

Dear Torsten Thank you very much for your explication and detailed analysis. We discussed your comments and our TC meeting yesterday, and concluded that we believe it feasible to accommodate the requested change to the cardinality of the ToParty. We have to make a few implementation decisions and would like your input on semantical requirements. I will write you on email off list. Best regards, Kenneth From: "Kirschner, Torsten" <[email protected]> Date: Wednesday, June 22, 2016 at 6:09 AM To: Kenneth Bengtsson <[email protected]>, "'[email protected]'" <[email protected]> Cc: "'[email protected]'" <[email protected]>, "'Bergheim, Erlend Klakegg'" <[email protected]> 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. Cf. RFC4480 section 11.3 ESK :- Public-Key Encrypted Session Key Packet Symmetric-Key Encrypted Session Key Packet. ESK Sequence :- ESK ESK Sequence, ESK. or cf. PGP FAQ section 2.6, «How does PGP handle multiple addresses?» 2. CMS Cf. RFC5652 section 6.1. and 6.2. e.g. EncelopedData ::= SEQUENCE { ..., recipientInfos RecipientInfos, …} RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 3. XML Encryption Cf. http://www.w4.org/TR/xmlenc-core section 3.5.1 «The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s)…» Personally, I found this section of XML Encryption spec to be difficult to comprehend, especially since some XML tricks are used which tools do not easily illustrate, but there are some stackoverflow articles on the subject. 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). There is a business need for this, and there are a number of best pratice security standards supporting this in order to maintain end-to-end confidentiality. 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. For each such sections, reuse existing standards and specifications as much as possible, instead of creating new syntax. Very often it is possible to describe a profile of an existing standard instead. In particular: - what added value, presumably security-wise, do Payload/InstanceHashValue and InstanceHashAlgorithm contribute, which could not or maybe should be achieved by the already existing ds:Signature element? - the InstanceDecryption(Information Key)ExternalReference should be demoted into an optional Security or Key Exchange Protocol Type, or removed completely. - the Login and Password of the ExternalReferenceType should be made into an optional Credentials Type, supporting username/password, but also other tokens like X.509 certificates etc. - the Availabilty(Start End)DateTime on the ExternalReferenceType should either be promoted to the business level, i.e. EnvelopeType, by specifying timing constraints/quality of service on that level, or otherwise how would one align state? At this point, I am tempted to recommend you remove PayloadType/InstanceHashValue, InstanceHashAlgorithm, all of the Instance…ExternalReferences and RelevantExternalReference. I do support the concept of an external payload reference, but it should not be modelled as your ExternalReferenceType. Up to that point however, i.e. the initial part covering business issues, the BDE is excellent. Best regards Torsten -- Med vennlig hilsen Torsten Kirschner områdearkitekt Elektronisk Samhandling // Forvaltningsseksjonen Prosjekt- og forvaltningsavdelingen // NAV IT ( : 928 27 731 // + [email protected] Fra: Kenneth Bengtsson [mailto:[email protected]] Sendt: 25. mai 2016 22:40 Til: Kirschner, Torsten; '[email protected]' Kopi: [email protected]; Bergheim, Erlend Klakegg Emne: Re: [bdxr-comment] SV: [members] 30 day Public Review for Business Document Envelope V1.1 - ends May 20th 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: < [email protected] > on behalf of Kenneth Bengtsson < [email protected] > Date: Thursday, April 21, 2016 at 2:49 PM To: "Kirschner, Torsten" < [email protected] >, "'[email protected]'" < [email protected] > Cc: " [email protected] " < [email protected] > Subject: Re: [bdxr-comment] SV: [members] 30 day Public Review for Business Document Envelope V1.1 - ends May 20th 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: < [email protected] > on behalf of "Kirschner, Torsten" < [email protected] > Date: Thursday, April 21, 2016 at 10:30 AM To: " '[email protected] '" < [email protected] > Subject: [bdxr-comment] SV: [members] 30 day Public Review for Business Document Envelope V1.1 - ends May 20th 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 områdearkitekt Elektronisk Samhandling // Forvaltningsseksjonen Prosjekt- og forvaltningsavdelingen // NAV IT ( : 928 27 731 // + [email protected]