[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]