[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg-as4] follow-up on Receipts
|
>should it reuse the ds:references from the
incoming ebMS message and recompute hashes
>for them? If the latter, the WSS
module and the Receipt generation can't be decoupled
>as much as is described
below
As far as profiling
the details of Receipt goes, I am also NOT
in favor of the above, which requires the
Receipt generation function to :
(a) access the SignedInfo element from the security
header,
(b) parse this element in order to
(c) recompute a set of digests similar to these
for insertion in the Receipt.
But it is more (b) and (c) that bother me, not so much
(a) as accessing different parts of the Security header requires same kind of
coupling (I guess we were already talking about before, for getting
authorization credentials.
However: I'd like to submit the following option to the
TC :
Given that the message to be acknowledged has been
signed, would it be acceptable for NRR to:
(1) extract the ds:SignatureValue from the Security header of the received message along with the
ds:SignedInfo
element,
(2) insert these in the Receipt
body,
(3) sign the Receipt (body) before sending
back.
It seems to me that the NRR function is still supported
that way: the signature validation on the Receiver side (i.e. sender of Receipt)
will be doing the job of matching the digest(s) that are in the Security header,
with the message parts. So the Receiver can be sure, out of its WSS module, that
these already-computed digests by the Sender side match the payloads he
got (no tampering possible from the Sender). So here we
get all our needed digests.
Sending these back to Sender in a signed Receipt, will
then provide the Sender with a proof that the Receiver has received this same
message from which these digests were computed on his (Sender) side, when
creating the first signature...
In other words, all the Receiver does is sign the
Sender's signature (after validation) and send it
back...
I am not an NRR expert, so I may miss something here...
But the interest of this approach, is that - for large
payloads - it is not necessary for the Receiver to recompute digests
(problematic when using streaming for message delivery) before sending a Receipt
.
In case that is not a stupid idea, I would still only
promote it as an *option* available in case of large
payloads...
-Jacques
From: Moberg Dale [mailto:dmoberg@axway.com] Sent: Wednesday, February 04, 2009 9:25 AM To: Pim van der Eijk; timothy@drummondgroup.com; Durand, Jacques R. Cc: ebxml-msg-as4@lists.oasis-open.org Subject: RE: [ebxml-msg-as4] follow-up on Receipts Pim
writes The ds:Reference is not
required in the ebbp:NonRepudationInformation schema, it is also possible to
only include a message part identifier. <xsd:element
name="MessagePartNRInformation"> Comment: It is true
that the ds:Reference is not required by the schema but whichever choice is
taken, the EDIINT requirement is that a receipt have a message digest value(s)
that allow the cryptographic binding of receipt to original message for which it
is a receipt. The ds:Reference option will have that capability, and it
will/should have a URI (using the cid: scheme) that identifies the message part.
So should we profile this to promote interoperability or leave it
open? This profile could constrain
the value of the MessagePartIdentifier to MIME part IDs and XML IDs.
Comment: Or not make use of
it… More generally, when
generating the Receipt, can the ebMS handler determine itself which elements in
the message it generates ds:Reference elements for, or should it reuse the
ds:references from the incoming ebMS message and recompute hashes for
them? If the latter, the WSS module and the Receipt generation can't be
decoupled as much as is described below. Comment: We should probably
say something about this. From EDIINT requirements, I would think that all the
parts need to be identified, especially because in AS4 we are using a signing
approach that allows signature to be assembled in bits and pieces unlike the
CMS/pkcs7 approach. On the other hand, there are
multiple reasons why the receipt could involve digest for diffent and/or
different structures: 1) If the Receipt is
generated by the ebMS module, would the Receipt contain a digest of the
decompressed payload? The WSS module operates on the compressed
payload. Comment: Needs to be specified. Ric will be needed for
review on this point. 2) If AS4 is to be
compatible with a future Bundling profile, I guess the receipt
should sign the eb:UserMessage and generate separate receipts for each
user message. AS4 now requires the WSS module to sign the full
eb:Messaging structure, which (when using bundling) could include multiple user
messages. Comment: as long as bundling
keeps track of who gets what, I think a receipt using cid: URI identifiers could
pick out the parts that a given user “receives” But it will get complicated to
track. From: Timothy
Bennett [mailto: My comments inline... Ric,
Dale, others... please share your thots... Summary of discussion about Receipts
today: 1. In case of large payloads, there
is a performance problem for generating digests to be included in Receipt for
NRR: such payloads would have to be first saved on disk. Indeed, streaming is
not sufficient, as it is a read-only-once procedure, and here we'd need two
readings: one for creating the digest, the other for
delivery. One of the important aspects of the discussion on
performance with regard to digest computation relates to the architecture of the
ebMSv3 specification that supports the different processing modules as being
swappable black boxes. That is, the inbound stream passing through the
security module, then the reliability module, then the ebMS module, etc.
In this context, the code that eventually generates the NRR receipt is not
guaranteed to have access to the digest computed by the Security Module and if
strict separation of modules was enforced, then the code that generates the NRR
receipt would have to compute the digest of the original inbound message
again. That's the context of the performance question for large
payloads. 2. There seems to be a consensus to
make the inclusion fo digest(s) optional in the Receipt, e.g. based on agreement
(PMode). Rationale: the Receipt serves several purposes (including simple Ack)
and in some cases NRR is not the primary
concern. 3. "small" documents are expected to
be the most common case, when NRR is required. In such cases it is not a problem
to compute a hash for each attached payload. 4. In case NRR may still be required
for large payloads, some alternative solution could be considered for support in
AS4: e.g. the original message must be signed. By validating the signature , the
receiving MSH (i.e. its Security module) effectively computes a digest. In
tightly integrated implementations, could this digest by accessible by the ebms
processor? Or, would it be sufficient for NRR to send back in the Receipt the
signature of the original message (itself signed over by the Receipt signature),
so that the Receiver cannot deny having received the original (signed) message
from which this signature was generated? Jacques ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]