WebProNews

XML encryption classifies a course of action for encrypting plain text data, generating ciphertext, and decrypting the ciphertext to retrieve the plaintext data.

Both the <EncryptionMethod> and <KeyInfo> are optional i.e. the sender and receiver may agree on the encryption method and key in advance. Several elements use the definitions from the DSIG.

If the recipient does not know the decryption key in advance, then the sender generates and sends it. The key can be protected in transit by encrypting method or key agreement.

If the plaintext data to encrypt is an XML element or content, you encode it using UTF-8 and perform any necessary transforms to it, otherwise, if it is an external resource, you simply consider it as an octet sequence. You then encrypt the data, creating CipherValue, which you place in EncryptedData.

Care must be taken when signing content that may later be encrypted; clearly; the content must be restored to exactly the original plaintext form for the signature to validate properly. To restore the plaintext in the signed content, use the decryption transform method for XML signature defined by the XML encrypt joint W3C and IETF working group.

This transform also allows specifications of XML fragments that were encrypted and then signed with rest of the document and, therefore, are not decrypted to validate the signature. Often, encrypted fragments are removed from the signed information by using the XPATH transform in the reference element, since the meaningful information is the plaintext.

We can sign the plaintext version of an encrypted element by including the appropriate reference element pointing to it. When the signed document is confidential and encrypted after being signed, you should also protect against surreptitious forwarding in which the recipient forwards the signed confidential document to a competitor, encrypted by the competitor public key, trying to make it look as if the sender sent the confidential information. To prevent surreptitious forwarding, the signer should append the recipient identities to the document being signed.

If the recipient does not know the decryption key in advance, then the sender generates and sends it. The key can be protected in transit by encrypting method or key agreement.

If the plaintext data to encrypt is an XML element or content, you encode it using UTF-8 and perform any necessary transforms to it, otherwise, if it is an external resource, you simply consider it as an octet sequence. You then encrypt the data, creating CipherValue, which you place in EncryptedData.

Care must be taken when signing content that may later be encrypted; clearly; the content must be restored to exactly the original plaintext form for the signature to validate properly. To restore the plaintext in the signed content, use the decryption transform method for XML signature defined by the XML encrypt joint W3C and IETF working group.

This transform also allows specifications of XML fragments that were encrypted and then signed with rest of the document and, therefore, are not decrypted to validate the signature. Often, encrypted fragments are removed from the signed information by using the XPATH transform in the reference element, since the meaningful information is the plaintext.

We can sign the plaintext version of an encrypted element by including the appropriate reference element pointing to it. When the signed document is confidential and encrypted after being signed, you should also protect against surreptitious forwarding in which the recipient forwards the signed confidential document to a competitor, encrypted by the competitor public key, trying to make it look as if the sender sent the confidential information. To prevent surreptitious forwarding, the signer should append the recipient identities to the document being signed.

Pawan Bangar, Technical Director, Birbals, #1047,Sector 42-b, Chandigarh. www.ebirbals.com, www.birbals.com