[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]