OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr-comment message

[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.
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 // + torsten.kirschner@nav.no

 

 

 

 

 

 

 

 

Fra: Kenneth Bengtsson [mailto:kbengtsson@efact.pe]
Sendt: 25. mai 2016 22:40
Til: Kirschner, Torsten; 'bdxr-comment@lists.oasis-open.org'
Kopi: bdxr@lists.oasis-open.org; 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: <bdxr-comment@lists.oasis-open.org> on behalf of Kenneth Bengtsson <kbengtsson@efact.pe>
Date: Thursday, April 21, 2016 at 2:49 PM
To: "Kirschner, Torsten" <Torsten.Kirschner@nav.no>, "'bdxr-comment@lists.oasis-open.org'" <bdxr-comment@lists.oasis-open.org>
Cc: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
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: <bdxr-comment@lists.oasis-open.org> on behalf of "Kirschner, Torsten" <Torsten.Kirschner@nav.no>
Date: Thursday, April 21, 2016 at 10:30 AM
To: "'bdxr-comment@lists.oasis-open.org'" <bdxr-comment@lists.oasis-open.org>
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 // + torsten.kirschner@nav.no

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]