[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-msg] Re: Signed Errors
Here is some feedback from another developer: In our opinion Option number three, to provide
signing as an optional feature makes the most sense. The
reason for not always signing is the determination of the
certificate which should be used to sign. If I have my system
configured to use multiple certificates for communicating with
different partners (as many of our customers do) and the cause
for the error is that I cannot determine the partner who sent
the message – for example because of an erroneous PartyID
configuration or because of database problems – which
certificate should I use for signing the error message? When defining that error messages which relate to
signed user messages should be signed when possible but also
have to be processed when not signed, we would not run into
severe problems when being unable to recognize the partner. Another point which may not be overseen is that
error messages can become a security issue. If a system
provides too much information in its error messages (I have
seen many stack traces in the tests we have done by now), an
attacker is able to determine vulnerabilities by sending
erroneous messages to an MSH, see many SQLInjection-Attacks
which rely on error messages passed through to the GUI. Most emerging profiles I am aware of require WS-Security, so a receiver MSH can simply reject (and ignore) any unsigned message. There could be a problem with users of profiles that support unsigned ebMS messages, there the decision whether or not to send errors is an ebMS3 level decision, rather than a WS-Security decision. For the same reason that WS-Security allows to ignore faulty requests instead of sending faults, ebMS could perhaps allow such a policy at ebMS level. Pim On 05/08/2014 06:50 AM, K N, Krishna
wrote:
Hi, Here are your answers (From SoftwareAG team). o - Do not sign errors caused by signed messages, ie. leave as is: Yes/No NO o - Always sign errors if the originating message causing an error condition was signed: Yes/No YES(We discussed in our team and thought this might be the right approach) o - Optionally sign errors for signed messages that caused an error condition: Yes/No NO Thanks Krishna -----Original Message----- From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Theo Kramer Sent: Tuesday, April 29, 2014 12:27 AM To: Pim van der Eijk Cc: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Re: Signed Errors Hi Pim Apologies for the delay - am on holiday with the family. Hope the following will suffice. I have copied this to the list should there be any further comment or input Re: ebMS3/AS4 Signed and/or Encrypted Error Handling Dear AS4 Developer/Administrator/Vendor It has come to our attention that there is no explicit method to ensure that ebMS3 error messages should be signed or encrypted either in the ebMSV3 core specification or in the AS4 Profile. It would be useful, particularly in cases where it is not possible to provide other means such as access control lists (ACLs) to ensure authorised connectivity, to authenticate and validate that the MSH that is posting an error with the MSH to which the original message in error was sent and not from some other source. This, in particular, for asynchronous errors, and also inline with the required behaviour for signed receipts as per the AS4 Profile. It is, however, our understanding that for current implementations neither synchronous or asynchronous error messages are signed and/or encrypted and requiring this as for signed receipts may cause interoperability implications for existing systems. With that, and prior to making a change to either the ebMSV3 core spec or to the AS4 profile we would like to obtain your opinion on the above matter. Please respond to this by answering the following questions and also feel free to provide any further input on this that you may feel appropriate o - Do not sign errors caused by signed messages, ie. leave as is: Yes/No o - Always sign errors if the originating message causing an error condition was signed: Yes/No o - Optionally sign errors for signed messages that caused an error condition: Yes/No Sincerely OASIS EBXML Messaging Technical Committee Related Documents OASIS ebXML Messaging Services Version 3.0 Part 1: Core Features. 01 October 2007. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html. AS4 Profile of ebMS 3.0 Version 1.0. 23 January 2013. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.html. On 28 Apr 2014, at 09:01 , Pim van der Eijk <pvde@sonnenglanz.net> wrote:OK, feel free to update the text. As you may see at http://ebxml.xml.org/, the number of vendors implementing AS4 is increasing rapidly .. Pim On 04/27/2014 12:39 PM, Theo Kramer wrote:I've been thinking of adding some options eg. Leave as is, always sign, or make it optional to be agreed by parties before sending. Regards Theo Sent from typo enabled phoneOn 27 Apr 2014, at 11:45, Pim van der Eijk <pvde@sonnenglanz.net> wrote: Hi Theo, Did you want to discuss this on the TC, or shall I forward this as is? Kind regards, PimOn 04/19/2014 08:23 AM, Pim van der Eijk wrote: Hi Theo, This looks fine to me, and I can forward this to some of the vendors that are not in OASIS/on the TC. We could indeed add a PMode parameter to the core spec and profile AS4 to have behaviour like we do with receipts. I agree we (practically) only need signing and not encryption. Good Easter, PimOn 04/19/2014 08:08 AM, Theo Kramer wrote: Hi Pim Following on from our discussion on Signing Errors I thought we could send out the following to some of the current AS4 Implementation vendors, developers and system administrators. ------------------------------------------ Re: ebMS3/AS4 Signed and/or Encrypted Error Handling Dear AS4 Developer/Administrator/Vendor It has come to our attention that there is no explicit method to ensure that ebMS3 error messages should be signed or encrypted either in the ebMSV3 core specification or in the AS4 Profile. It would be useful, particularly in cases where it is not possible to provide other means such as access control lists (ACLs) to ensure authorised connectivity, to authenticate and validate that the MSH that is posting an error with the MSH to which the original message in error was sent and not from some other source. This in particular for asynchronous errors, and also inline with the required behaviour for signed receipts as per the AS4 Profile. It is, however, our understanding that for current implementations neither synchronous or asynchronous error messages are signed and/or encrypted and requiring this as for signed receipts may cause interoperability implications for existing systems. With that, and prior to making a change to either the ebMSV3 core spec or to the AS4 profile we would like to obtain your opinion on the above matter. Sincerely OASIS EBXML Messaging Technical Committee Related Documents OASIS ebXML Messaging Services Version 3.0 Part 1: Core Features. 01 October 2007. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html. AS4 Profile of ebMS 3.0 Version 1.0. 23 January 2013. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.html. ---------------------------------------- ... and now as I write this why not just make this an option with a p-mode such as PMode[1].ErrorHandling.Report.SignErrors: support not required and only valid for errors generated from signed messages (true/false) ? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]