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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: [OASIS Issue Tracker] Updated: (EBXMLMSG-30) PMode[1].Security.SendReceipt.NonRepudiation

     [ http://tools.oasis-open.org/issues/browse/EBXMLMSG-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pim van der Eijk updated EBXMLMSG-30:

Proposal to accept wording of Sander in last comment.

> PMode[1].Security.SendReceipt.NonRepudiation
> --------------------------------------------
>                 Key: EBXMLMSG-30
>                 URL: http://tools.oasis-open.org/issues/browse/EBXMLMSG-30
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: AS4 Profile
>            Reporter: Pim van der Eijk
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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