Next in thread →
Next in month →
Re: [ebxml-msg] AS4 spec clarification on receipts
Turns out that X509 signatures are optional for 4 of the 5 usage
profiles in the SuperStream draft spec, so perhaps the definition of
NRR in that context takes on meaning not dependent on signed
messages.
On 11/28/2012 1:53 PM, Jacques Durand
wrote:
Right
for Section
5.1.8,
although the statement in the feature table 2.1.1:
“…Use
of the ebbpsig:NonRepudiationInformation element (as
defined in [ebBP-SIG]) is REQUIRED as
content
for the eb:Receipt message,”
Is
misleading and can be interpreted as NonRepudiationInformation
being
always present in any Receipt, even for reception awareness.
(in fact this statement was not necessary at this place and
could be removed w/o altering the spec.)
-jacques
From:
[mailto:] On Behalf Of
Pim van der Eijk
Sent: Wednesday, November 28, 2012 1:35 AM
To: Jacques Durand; ;
Subject: RE: [ebxml-msg] AS4 spec clarification
on receipts
Hello,
Section
5.1.8 describes two formats for receipts:
-
Receipts for reception awareness: those use the UserMessage
of the received message (rather than an empty
NonRepudiationInformation structure as below in (2)).
-
Receipts for nonrepudiation of receipt: those use the ebBP
Non-Repudiation element with ds:Reference elements.
If
the NRR is for a signed message, these ds:Reference elements
can be reused from the wsse:Signature in the message being
acknowledged. This has the advantage that the AS4/ebMS3
parts of an MSH need to know nothing about creating message
digests, only about XML processing (see the XSLT in the
appendix). All the security processing is done in the
WS-Security module.
Perhaps
in theory (I would need to check) the spec allows
a situation where NRR is requested for an unsigned message,
in that case the AS4 module would have to create those
ds:References itself including Digests (which the XSLT does
not do), but that would be an unusual case.
Pim
From:
[mailto:]
On Behalf Of Jacques Durand
Sent: 27 November 2012 23:31
To: ;
Subject: RE: [ebxml-msg] AS4 spec clarification on
receipts
Tim:
1. Is setting
PMode.Security.SendReceipt.NonRepudiation = false a
non-conformant configuration with respect to the ebHandler
conformance profile? In other words, does the ebHandler
profile effectively require the sending of signed user
messages and the return of a signed receipt containing a
populated ebBP-SIG infoset, or does the ebHandler profile just
mean that ebBP-SIG infoset is required in the receipt even if
it is empty (either because the user message was unsigned or
because the PMode non-repudiation parameter = false)?
In
my view, the latter is true: the profile does not impose a
particular value for the
PMode.Security.SendReceipt.NonRepudiation parameter, so its
value remains a configuration choice at usage time. (in
fact, I notice that the PMode section 2.1.3.6 does not even
mention this parameter – it should). The only requirement
here is how the Receipt must be formed, not its usage.
2. What would the XML of
the receipt look like for a Pmode non-repudiation parameter =
false look like?
This
parameter =false means that Receipts are only to be used for
“reception awareness” if any (but if the other parameter PMode[1].Security.SendReceipt
is not set or set to false, then no reception awareness is
intended and then no Receipt at all needs be sent). I’d say
it should look like this and even <ebbp:NonRepudiationInformation/>
should
not have to be there, but I leave it to a schema check to
decide of this:
3. <eb3:Messaging
S12:mustUnderstand="true" id="ValueOfMessagingHeader">
4. <eb3:SignalMessage>
5. <eb3:MessageInfo>
6. <eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp>
7. <eb3:MessageId></eb3:MessageId>
8. <eb3:RefToMessageId></eb3:RefToMessageId>
9. </eb3:MessageInfo>
10. <eb3:Receipt>
11. <ebbp:NonRepudiationInformation/>
12. </eb3:Receipt>
13. </eb3:SignalMessage>
14. </eb3:Messaging>
15.
-jacques
From:
[mailto:]
On Behalf Of Timothy Bennett
Sent: Tuesday, November 27, 2012 11:57 AM
To:
Subject: [ebxml-msg] AS4 spec clarification on
receipts
Hey folks,
Would like everyone's thoughts on the following clarification
needed from the AS4 profile:
From Section 2.1 on the ebHandler Conformance Profile:
“Use
of the ebbpsig:NonRepudiationInformation element (as defined
in [ebBP-SIG]) is REQUIRED as content for the
eb:Receipt message, i.e. when conforming to this profile a
Receiving MSH must be able to create a Receipt with such a
content, and a Sending MSH must be able to process it.”
Further,
in Section 5.2.1, the spec suggests a usage:
“For
non-repudiation, the eb:Receipt
element must contain a well-formed
ebbpsig:NonRepudiationInformation element. This
is indicated by the new P-Mode
parameter:· PMode[1].Security.SendReceipt.NonRepudiation
: value = ‘true'
(to be used for non-repudiation of receipt), value = 'false'
(to be used simply for reception awareness).”
So,
here's my couple of questions:
16. Is setting
PMode.Security.SendReceipt.NonRepudiation = false a
non-conformant configuration with respect to the ebHandler
conformance profile? In other words, does the ebHandler
profile effectively require the sending of signed user
messages and the return of a signed receipt containing a
populated ebBP-SIG infoset, or does the ebHandler profile just
mean that ebBP-SIG infoset is required in the receipt even if
it is empty (either because the user message was unsigned or
because the PMode non-repudiation parameter = false)?
17. What would the XML of the
receipt look like for a Pmode non-repudiation parameter =
false look like?
Would it be just an empty eb3:Receipt infoset (like below),
or would it also contain an empty
ebbpsig:Non-RepudiationInformation infoset?
<eb3:Messaging
S12:mustUnderstand="true" id="ValueOfMessagingHeader">
<eb3:SignalMessage>
<eb3:MessageInfo>
<eb3:Timestamp>2009-11-06T08:00:09Z</eb3:Timestamp>
<eb3:MessageId></eb3:MessageId>
<eb3:RefToMessageId></eb3:RefToMessageId>
</eb3:MessageInfo>
<eb3:Receipt>
</eb3:Receipt>
</eb3:SignalMessage>
</eb3:Messaging>
Next in thread →
Next in month →