Identify the protected part of the message
XML Encryption provides an XML representation for encrypted data. It can protect an entire element, an element’s content or other data. This is useful when an integration must expose selected routing information while keeping a sensitive part confidential beyond an intermediate system.
Start with a real message map: identify what the sender produces, what each intermediary can read, which component decrypts, and which application acts on the result. Use a harmless sample. Transport TLS protects a connection; message encryption can preserve protection across additional processing boundaries when the complete protocol supports it.
The W3C XML Encryption 1.1 specification defines the format and security considerations. Use it alongside the applicable application profile and the current documentation of the maintained library that actually processes the message.
Read the structure before choosing settings
| Element or setting | Meaning | Review question |
|---|---|---|
| EncryptedData | The encrypted object and its representation. | Which original element or content was replaced? |
| EncryptionMethod | The algorithm identifier and relevant parameters. | Is it allowed by the application’s current policy and supported by both peers? |
| CipherData / CipherValue | The encoded encrypted value. | Does the library authenticate and process it under the intended key? |
| EncryptedKey | An encrypted or wrapped key, when the protocol uses one. | Which recipient and key-protection method apply? |
| KeyInfo | Information used to identify or obtain a key. | How is that information constrained to trusted keys? |
On a narrow screen, scroll the table sideways. Keyboard users can focus the table and use the arrow keys.
A name in KeyInfo helps locate a key; the name itself does not grant trust. Inspect how the application resolves it and whether untrusted input can redirect resolution.
Bind verified content to the action
Encryption, signature verification and application authorization need to agree on the same message. A signature may cover selected XML nodes; the program must act on the intended verified nodes, with the required identifiers and structural constraints.
For the invoice example, decide how the routing code, invoice identifier and protected customer content are bound together by the application’s authenticated message design. Otherwise, a readable routing field might be altered independently of the protected content.
Document the required processing order. Signing before encryption and signing encrypted material create different objects to verify. Use the profile’s defined order and transform rules, and check exactly what the library returns to application code.
Apache Santuario’s Java FAQ describes secure validation and restrictions affecting signature processing and resource resolution. Confirm the defaults and supported settings for the installed version instead of borrowing an old configuration snippet.
Review the integration in a controlled environment
- Record sender and receiver library versions, application profile, algorithm identifiers, key locations and certificate trust configuration.
- Inspect parser settings and resource resolution. Constrain external entities, external references, transforms and input sizes according to the library’s supported secure configuration.
- Send a harmless valid example and confirm the expected recipient obtains the exact intended fields. Verify the expected signature or authenticated-encryption result before acting on content.
- Within your authorized test environment, try an altered ciphertext, an untrusted key, a changed signed field and an unexpected message structure. Each must fail according to the protocol before a business action occurs.
- Check logs and error responses for exposed plaintext, keys and unnecessarily detailed decryption errors. Retain enough diagnostic information for authorized operators without returning sensitive detail to the sender.
- Test a planned certificate/key change and document access to old messages that still need to be retained.
W3C’s security considerations discuss chosen-ciphertext risks, including CBC and RSA PKCS#1 v1.5 processing. Historical mandatory-to-implement lists are not a contemporary deployment policy. Follow current profile and library guidance, including authenticated protection and algorithm restrictions.
Make the result reviewable
Record what was protected, which components had decryption access, what was authenticated, and the outcome of each rejection test. Include the exact software versions so another engineer can reproduce the review.
If a partner cannot support the required protection, agree on an upgrade or an approved alternate exchange. Silently weakening algorithm or verification settings changes the security properties of the integration and can conceal the real interoperability issue.
Revisit the record when a library advisory, profile revision, key change or partner upgrade affects message processing. Keep production keys and live sensitive payloads out of examples, tickets and shared debugging tools.
Keep a usable review record
Download the xml integration review record (plain text). Save a copy, fill it out in a text editor, and keep it with your approved project records.