Moberg Dale wrote:
5688_1233768294_4989CF66_5688_325559_1_822DFF5CD1096F4AA656A0F90E903E910246704F@wbe41.phx.us.sopra"
type="cite">
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">
<xsd:complexType>
<xsd:choice >
<xsd:element name="MessagePartIdentifier"
type="bpssignal:non-empty-string"/>
<xsd:element ref="ds:Reference"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
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?
Promote interoperability.
I really don't want this NRR/receipt thing to get too complicated. The
simplicity of the AS2 MDN should be the model IMO. I'm willing to
concede for AS4 that the ds:Reference is optional: (a) contains a hash
means the receipt is a NRR and all the legal/business use that comes
with that, and (b) if empty, resorts back to a ebMSv2-esque delivery
acknowledgment.
For NRR to be NRR, the original sender must validate that the computed
MIC returned in the receipt from the receiver matches the computed MIC
performed by the sender before transport. I think you make this as
simple a process as possible with a strictly specified workflow,
profiling out as many security "compositional" options as possible --
(a) specified order to apply compression, encryption, and signature,
(b) what you compress, (c) what you sign over, and (d) what you encrypt
over.
-- payloads should be compressed prior to handing over to Soap
w/Attachments for attaching
-- next, (detached) signature should be computed over everything in the
message that hubs/gateways won't modify along the way
-- finally, message level encryption should be applied over everything
that can't be obscured in order for successful endpoint delivery
The content of the ds:Reference should be explicit from profile, and
not dependent on options/configuration parameters, in order to promote
interoperability. If the ds:Reference is non-empty, its content should
mean one thing and one thing only IMO. If not, then I'm open to strong
arguments otherwise.
|