Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Fixed
    • Component/s: AS4 Profile
    • Labels:
      None
    • Proposal:
      Hide
      In section 5.2.1, Usage Profiling (a), which introduces the parameter PMode[1].Security.SendReceipt.NonRepudiation add a sentence:

      "If the received message is not signed and does not have PMode[1].Security.X509.Sign set, the PMode[1].Security.SendReceipt.NonRepudiation parameter MUST be set to false."

      In section 5.1.8, profiling rule (c).

      Replace:

      "The eb:Receipt MUST contain the information necessary to provide non-repudiation of receipt of the original message, as described in profiling rule (b)."

      By

      "If Pmode[1].Security.SendReceipt.NonRepudiation is set to true, the The eb:Receipt MUST contain the information necessary to provide non-repudiation of receipt of the original message, as described in profiling rule (b)."

      In Appendix B, line 1109

      Replace

      "The stylesheet supports signed messages for which the Pmode[1].Security.SendReceipt.NonRepudiation is set to true. "

      By

      "The stylesheet supports signed messages for which the Pmode[1].Security.SendReceipt.NonRepudiation is set to true for signed messages and to false for unsigned messages. "


      Show
      In section 5.2.1, Usage Profiling (a), which introduces the parameter PMode[1].Security.SendReceipt.NonRepudiation add a sentence: "If the received message is not signed and does not have PMode[1].Security.X509.Sign set, the PMode[1].Security.SendReceipt.NonRepudiation parameter MUST be set to false." In section 5.1.8, profiling rule (c). Replace: "The eb:Receipt MUST contain the information necessary to provide non-repudiation of receipt of the original message, as described in profiling rule (b)." By "If Pmode[1].Security.SendReceipt.NonRepudiation is set to true, the The eb:Receipt MUST contain the information necessary to provide non-repudiation of receipt of the original message, as described in profiling rule (b)." In Appendix B, line 1109 Replace "The stylesheet supports signed messages for which the Pmode[1].Security.SendReceipt.NonRepudiation is set to true. " By "The stylesheet supports signed messages for which the Pmode[1].Security.SendReceipt.NonRepudiation is set to true for signed messages and to false for unsigned messages. "

      Description

      In AS4, the support for non-repudiation of receipt attempts to leverage the capabilities of WS-Security. If NRR is requested, the receiving MSH can reuse the ds:Reference computed by the sending MSH and validated by the WS-Security module of the receiving MSH. The sending MSH can store the SignedInfo and match the returned receipt to it. Profiling rule (c) in 5.1.8 already requires signing of receipts for signed messages.

      Section 5.2.1 of AS4 defines a Pmode parameter to request NRR. The Core Specification already defined a parameter to specify the application of signatures. The two obvious, practically useful configurations are:
      - Signed messages, NRR receipts.
      - Unsigned messages, NRR receipts

      In theory, having this parameter as an independent parameter means AS4 allows two other combinations:
      - Signed messages, reception awareness receipts.
      - Unsigned messages, NRR receipts.
      The first of these two configures an exchange where NRO is provided and NRR is not. It could have some theoretical value, though I can't see it being of any practical use, but is doesn't complicate implementations much.
      The second is quite problematic as the sending MSH does not provide any ds:Reference so that the receiving MSH would have to compute these itself. However, the NRR receipt would have no value to the sending MSH as it cannot compare the hash values to any values it has computed itself. So to simplify implementations, my proposal would be to disallow this second situation: we restrict NRR receipts to signed messages.

        Activity

        Hide
        Pim van der Eijk added a comment -
        Sorry, this should be:

        Section 5.2.1 of AS4 defines a Pmode parameter to request NRR. The Core Specification already defined a parameter to specify the application of signatures. The two obvious, practically useful configurations are:
        - Signed messages, NRR receipts.
        - Unsigned messages, RECEPTION AWARENESS receipts
                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
        Show
        Pim van der Eijk added a comment - Sorry, this should be: Section 5.2.1 of AS4 defines a Pmode parameter to request NRR. The Core Specification already defined a parameter to specify the application of signatures. The two obvious, practically useful configurations are: - Signed messages, NRR receipts. - Unsigned messages, RECEPTION AWARENESS receipts                                           ^^^^^^^^^^^^^^^^^^^^^^^^^
        Hide
        Pim van der Eijk added a comment -
        Assigned to AS4
        Show
        Pim van der Eijk added a comment - Assigned to AS4
        Hide
        Pim van der Eijk added a comment -
        First update change to "If the received message is not signed, the PMode[1].Security.SendReceipt.NonRepudiation parameter MUST be set to false."

        Show
        Pim van der Eijk added a comment - First update change to "If the received message is not signed, the PMode[1].Security.SendReceipt.NonRepudiation parameter MUST be set to false."
        Hide
        Sander Fieten added a comment -
        I propose to remove from Profiling rule (c) in 5.1.8 the text starting with "The eb:Receipt MUST contain the information necessary ..."

        This will result in a requirement to always sign the Receipt is the original message was signed, but leaves open the option to use only an reception awareness receipt. That is configured with the P-Mode parameter from section 5.2.1. To clearify further the description of the new P-Mode parameter PMode[1].Security.SendReceipt.NonRepudiation can be changes to "value = 'true' (to be used for non-repudiation of receipt as specified in §5.1.8 (b)), value = 'false' (to be used simply for reception awareness as specified in §5.1.8 (a)).


        For the description on the stylesheet I propose: "The stylesheet will generate a NRR Receipt signal for signed messages and a reception awareness Receipt signal for unsigned messages".
        Show
        Sander Fieten added a comment - I propose to remove from Profiling rule (c) in 5.1.8 the text starting with "The eb:Receipt MUST contain the information necessary ..." This will result in a requirement to always sign the Receipt is the original message was signed, but leaves open the option to use only an reception awareness receipt. That is configured with the P-Mode parameter from section 5.2.1. To clearify further the description of the new P-Mode parameter PMode[1].Security.SendReceipt.NonRepudiation can be changes to "value = 'true' (to be used for non-repudiation of receipt as specified in §5.1.8 (b)), value = 'false' (to be used simply for reception awareness as specified in §5.1.8 (a)). For the description on the stylesheet I propose: "The stylesheet will generate a NRR Receipt signal for signed messages and a reception awareness Receipt signal for unsigned messages".
        Hide
        Pim van der Eijk added a comment -
        Proposal to accept wording of Sander in last comment.
        Show
        Pim van der Eijk added a comment - Proposal to accept wording of Sander in last comment.
        Hide
        Pim van der Eijk added a comment -
        Sander's comment accepted, actual errata to be provided before issue gets closed.

        Show
        Pim van der Eijk added a comment - Sander's comment accepted, actual errata to be provided before issue gets closed.
        Hide
        Sander Fieten added a comment -
        This parameter is defined in section 5.2.1 which is not included in the conformance clauses in section 6 and is therefore non-normative. The parameter should be defined in the section 5.1.8.

        My proposal is to insert a profiling rule before the currently defined ones (in 5.1.8) that introduces and defines this parameter.
        Show
        Sander Fieten added a comment - This parameter is defined in section 5.2.1 which is not included in the conformance clauses in section 6 and is therefore non-normative. The parameter should be defined in the section 5.1.8. My proposal is to insert a profiling rule before the currently defined ones (in 5.1.8) that introduces and defines this parameter.

          People

          • Assignee:
            Unassigned
            Reporter:
            Pim van der Eijk
          • Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: