[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg-as4] AS4 NRR draft for Feb 9 discussion
I don’t think we have much of a
restriction on security layering, and we indicate that bilateral agreements are
allowed (if they can be made to work!), so it is ok to remove the qualification
concerning when receipts are needed. Do we want to point to anything in BSP 1.1
or just make a general recommendation to consult BSP 1.1? I tried to adhere to
BSP 1.1 in the wss example, but did not mention it as part of the expectations
for implementations. From: Timothy Bennett [mailto:timothy@drummondgroup.com] Seems like the right thing to
do to make things clear. Should we move these requirements at
higher level (i.e. not just WHEN receipts are needed). >MUST not encrypt any signed content before
signing, and, if using compression in an attachment, MUST sign the data after
compression. - We already have "compress then
sign" in 3.1, whcih could be made more specific about dealing with parts. - "sign then encrypt" is
also required in Core V3 (7.6) So we could just present it as a reminder
here (user should be aware that applies to all messages...). -jacques From: [Continuation of draft on NRR
incorporating features discussed on Monday Feb 9 teleconference.] AS4 reuses ebMS 3 signal messages for nonrepudiation
of receipt, and uses WSS for signing the receipt. The ebMS 3 signal message, used for either signed or
unsigned receipts, is a SOAP version 1.1 or 1.2 header with @mustUnderstand set
to “true”. The NonRepudiationInformation contains a sequence of
MessagePartNRInformation items for each message part for which evidence of non
repudiation of receipt is being provided. In the normal default usage, these
message parts are those that have been signed in the original message. Each
message part is described with information defined by an XML Digital Signature
Reference information item. The following example illustrates the ebMS 3 Signal
Message header. <eb3:Messaging S12:mustUnderstand="true" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id=”ValueOfMessagingHeader”> For a signed receipt, a Web Services Security header
signing over (at least) the signal header is required. An example WS-Security
header is as follows: <wsse:Security s:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" Implementations requesting signed receipts
in AS4 that make use of default conventions MUST identity message parts using
Content-Id values in the MIME headers, MUST sign the SOAP body and all
attachments using the http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Content-Signature-Transform
within the SignedInfo References list, MUST not encrypt any
signed content before signing, and, if using compression in an attachment, MUST
sign the data after compression. Variations from default conventions can be
agreed to bilaterally, but conforming implementations are only required to
provide receipts using the default conventions described in this section. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]