Enable XML Security (2)

xml| Safety | safety

<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>

It may also be necessary to encrypt all the information in the document, as shown in Listing 4.

Listing 4. Encrypted document with all content hidden
<?xml version= ' 1.0 '?>
<encrypteddata xmlns= ' http://www.w3.org/2001/04/xmlenc# '
Type= ' Http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml ' >
<CipherData><CipherValue>A23B45C56</CipherValue></CipherData>
</EncryptedData>




CipherData can be encapsulated or can refer to raw encrypted data. In the first case, the contents of the CipherValue element display the original data, whereas in the second case, the CipherReference element is used, which includes a URI that points to the location of the encrypted data.

Specification of XML
The slightest change to a message that has a cryptographic hash algorithm applied can also produce a different value. This provides trust in message integrity and is appropriate for common usage, but also introduces further complexity-two XML documents, although logically equivalent, may differ in the exact text comparison. Things like line delimiters, empty tags, hexadecimal instead of names in properties, and comments or annotation variants in a particular case can be examples of how the logical structure of a document is not affected and actually differs from one another. The canonical XML specification describes a method of generating a physical representation of a document (also a paradigm) that interprets the allowed variants so that if two documents have the same paradigm, the two documents are considered logically equal in the context of a given application.

This is especially important for encryption, especially for digital signatures, because it is clear that logically identical text variants should not indicate that the integrity of the document and the authentication of its sender are questionable. This can also happen with different tools (for example, parsers) that generate different text (and thus generate different message digests). Therefore, during the generation of signatures and validation calculations, a message digest should be made on the paradigm. If the summary matches, this will determine that even though the text may be different, the paradigm on which they are calculated matches.

XML Signature Example
XML signatures can be applied to arbitrary data content. Signatures that are applied to data in the same XML document are called encapsulated or encapsulated signatures, and those whose data is outside the signature element are called separate signatures. Listing 5 is taken from the signature candidate recommendation document, which is an instance of a simple detached signature.

Listing 5. Example of a simple detach signature
[S01] <signature id= "Myfirstsignature"
xmlns= "http://www.w3.org/2000/09/xmldsig#" >
[S02] <SignedInfo>
[S03] <canonicalizationmethod algorithm= "http://www.w3.org/TR/2001/
rec-xml-c14n-20010315 "/>
[S04] <signaturemethod algorithm= "http://www.w3.org/2000/09/
Xmldsig#dsa-sha1 "/>
[S05] <reference uri= "http://www.w3.org/TR/2000/REC-xhtml1-20000126/" >
[S06] <Transforms>
[S07] <transform algorithm= "http://www.w3.org/tr/2001/rec-xml-c14n-
20010315 "/>
[S08] </Transforms>
[S09] <digestmethod algorithm= "http://www.w3.org/2000/09/
Xmldsig#sha1 "/>
[S10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[S11] </Reference>
[S12] </SignedInfo>
[S13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[S14] <KeyInfo>
[S15A] <KeyValue>
[s15b] <DSAKeyValue>
[S15C] <p>...</p><Q>...</Q><G>...</G><Y>...</Y>
[S15d] </DSAKeyValue>
[S15E] </KeyValue>
[S16] </KeyInfo>
[S17] </Signature>




The actual signature information is located between the S02 row and the S12 line, that is, the signedinfo element. The part of the signature contains a reference to the algorithm used to compute the signaturevalue element, and that element itself is outside the signature part (on the S13 line). The SignatureMethod on the S04 line refers to the algorithm used to convert the signedinfo of the specification to SignatureValue. It is a combination of key-related algorithms and digest algorithms (Here are DSA and SHA-1) and may also have operations like padding. The KeyInfo element (which is optional between the S14 row and the S16 row) indicates the key used to validate the signature.

Transformation
As mentioned earlier, there are a number of possibilities for the order in which encryption, signing, modification, and possibly more signatures occur. Users may need to enter more data into form fields that have been partially encrypted or partially signed, and need to be able to do so without prejudice to subsequent validation and decryption. To address this situation, the consortium recently released a draft work on decrypting the XML signature. (See Resources.) ）

The following example is excerpted from that document, which demonstrates how to suggest that the recipient of the document use the correct decryption and signature verification order. The first code snippet shows the portion of the-order element to be signed, where the Cardinfo element of line 7th through 11th is for personal and financial details, it is plain text, but there are some encrypted data (row 12th).

Listing 6. An order element in an XML document
[<order] id= "Order" >
[<item>]
[<title>xml] and java</title>
[<price>100.0</price>]
[A] <quantity>1</quantity>
[</item>]
[Modified] <cardinfo>
[<name>your] Name</name>
[A] <expiration>04/2002</expiration>
[Ten] <number>5283 8304 6232 0010</number>
[One] </cardinfo>
[of] <encrypteddata id= "enc1" xmlns= "http://www.w3.org/
2001/04/xmlenc# ">...</EncryptedData>
[</order>]




Listing 7. An order document that is signed and further encrypted and now displays the conversion information
[<signature] xmlns= "http://www.w3.org/2000/09/xmldsig#" >
[<SignedInfo>]
[03].
[<reference uri= "#order" >
[A] <Transforms>
[A] <transform algorithm= "http://www.w3.org/2001/04/
Xmlenc#decryption ">
[Modified] <datareference uri= "#enc1"