OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 84 - Order of encryption and signature - Proposed Changes


The intention is the following:

o order of decryption and signature verification is determined by order of
elements in the security header(s).
o Decryption transform is not used
o Tokens and STRs should be in the order for most convenient use
o Schemes requiring alternate processing, such as forwarding cyphertext
after having inspected the cleartext cannot be implied by the message format
and must be the subject of out of band agreement.

Specific changes to core 13:

---
Lines 813-814

Current: Finally, if a sender wishes to sign a message before encryption,
they should use the Decryption Transformation for XML Signature.

Delete.
---
Lines 825-827

Current: To add a signature to a <wsse:Security> header block, a
<ds:Signature> element conforming to the XML Signature specification SHOULD
be prepended to the existing content of the <wsse:Security> header block.

New: To add a signature to a <wsse:Security> header block, a <ds:Signature>
element conforming to the XML Signature specification MUST be placed so that
a recipient validating the signature can determine the correct order of
processing signature and encryption elements by processing each in the order
they appear in the message. In most cases, this will mean prepending the
<ds:Signature> element to the existing content of the <wsse:Security> header
block.
---
Lines 842-843

Current: For processing efficiency it is RECOMMENDED to have the signature
added and then the security token pre-pended so that a processor can read
and cache the token before it is used.

New: Any Security Token elements or <wsse:SecurityTokenReference> elements
required to validate the signature SHOULD placed in order to allow the most
convenient processing in a single pass. In most cases, this will mean
placing them immediately before the <ds:Signature> element.
---
Lines 953-957

Current: When a sender or an intermediary encrypts portion(s) of a SOAP
message using XML Encryption they MUST prepend a sub-element to the
<wsse:Security> header block. Furthermore, the encrypting party MUST prepend
the sub-element into the <wsse:Security> header block for the targeted
recipient that is expected to decrypt these encrypted portions.

New: When a sender encrypts portion(s) of a SOAP message using XML
Encryption they MUST place a sub-element so that a recipient decrypting the
data can determine the correct order of processing Signature and encryption
elements by processing each in the order they appear in the message. In most
cases, this will mean prepending the sub-element to the existing content of
the <wsse:Security> header block. Furthermore, the encrypting party MUST
insert the sub-element into the <wsse:Security> header block for the
targeted recipient that is expected to decrypt these encrypted portions.
---
Lines 1095-1098

Current: When an element or element content inside a SOAP envelope (e.g. of
the contents of <S:Body>) is to be encrypted, it MUST be replaced by an
<xenc:EncryptedData>, according to XML Encryption and it SHOULD be
referenced from the <xenc:ReferenceList> element created by this encryption
step.

New: When an element or element content inside a SOAP envelope (either in
the <S:header> or <S:Body>) is to be encrypted, it MUST be replaced by an
<xenc:EncryptedData>, according to XML Encryption.

Whenever content inside the SOAP envelope or MIME attachements are
encrypted, they MUST be referenced by an <xenc:ReferenceList>,
<xenc:EncryptedKey> or <xenc:EncryptedData> element created by the
encryption step, in the cases of symmetric key, asymmetric key or encrypted
attachment, respectively. These elements MUST be ordered relative to each
other and to <ds:Signature> elements so that a recipient decrypting the data
can determine the correct order of decryption and signature validation by
processing each in the order they appear in the message. Any Security Token
elements or <wsse:SecurityTokenReference> elements required to decrypt the
data SHOULD placed in order to allow the most convenient processing in a
single pass. In most cases, this will mean placing them immediately before
the <xenc:ReferenceList>, <xenc:EncryptedKey> or <xenc:EncryptedData>
element.
---
Lines 1139-1146

Current: 9.5 Decryption Transformation

The ordering semantics of the <wsse:Security> header are sufficient to
determine if signatures are over encrypted or unencrypted data. However,
when a signature is included in one <wsse:Security> header and the
encryption data is in another <wsse:Security> header, the proper processing
order may not be apparent. If the sender wishes to sign a message that MAY
subsequently be encrypted by an intermediary then the sender MAY use the
Decryption Transform for XML Signature to explicitly specify the order of
decryption.

New: 9.5 Order of Signature Validation and Decryption

Multiple signatures, whether they cover overlapping data or not, may be
processed in any order without impacting signature validation. However when
multiple encryptions or encryptions and signatures cover overlapping data,
the correct order of signature validation and decryption (which is the
reverse of the order of signing and encrypting) must be observed in order to
obtain the intended results. The only method of indicating the order
provided by this specification is by the relative order of the
<xenc:ReferenceList>, <xenc:EncryptedKey>,  <xenc:EncryptedData> and
<ds:Signature> elements. In this context, order means the physical order of
elements within a single <wsse:Security> header block and the actual order
of processing amongst multiple <wsse:Security> header blocks, depending on
their designated Role (Actor). This implies that in some cases a sender
needs to know the order in which the message will be received by different
Roles (Actors).

It is possible for two parties to agree by some other means to some
alternate processing to support usecases not supported by this
specification. For example, consider an intermediary possessing an
asymmetric key used to decrypt a symmetric key under which some data is
encrypted. Supposed it is required that the intermediary decrypt it, inspect
it and forward it along still encrypted under the same symmetric key, to be
decrypted by means of a different asymmetric key. This processing cannot be
infered by any message order and requires a private agreement.
---
Line 1526

Current: The proper usage of nonce guards aginst replay attacts. [SIC]

New: One method to avoid this attack is encrypt the signature. This is
difficult to arrange while complying with this specification. Another
alternative is to ensure that the signed and encrypted data the not exactly
the same. For example, this can be done by signing an element and encrypting
its contents.

However, in this case the difference between the data sets will be known to
a potential attacker. This might still permit some cryptanalytic attacks.
Another approach is to make use of CBC padding to introduce random data to
the cleartext. All of the symmetric ciphers defined for use with XML
Encryption are block ciphers to be used in CBC mode. XML Encryption
specifies a CBC padding scheme that has two important properties: 1)
regardless of the length of the cleartext, there will always be some padding
bytes and 2) the padding data (except for a byte indicating the amount of
padding) can have any value. If the CBC implementation introduces random
bits in the padding (which is allowed, but not required by XML Encryption)
this threat will effectively be countered.
---

Hal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]