Re: Proposal for XML Encryption Syntax and Processing

I have a small complaint about the proposal. It doesn't strike me as prudent
to state :
While the relationship depicted below is invalid:

   +--------------------+

   | Encrypted          |

   |   Data-A           |

   |   +------------+   |

   |   | Encrypted  |   |

   |   |  Data-B    |   |

   |   +------------+   |

   +--------------------+



Simply because it is unclear. I assume it is meant to mean that the
encryption cannot be recursive without internal redefinition, specifically



key1,key2,data1{key1}(data2{key2})



would be invalid, however



key1,data1{key1}(key2, data2{key2})



would be valid. Otherwise we have strong recursion problems for people that
wish to send XML documents that are encrypted, over an XML encrypted channel
(similar to SSL over IPsec). I think this needs clarification. Also would it
be possible to get this document under 200K, there's a very large amount of
wasted space in the document.



Also there seems to be some critical information lacking from at least the
EncryptionMethod element. To demenstrate take Rijndael, it has 128, 192, and
256-bit keys, and also 128, 192, and 256-bit blocks. If for the sake of
security I choose to use 256/256 there is no way to specify that in
EncryptionMethod. Because of this it is often necessary to have explicit key
size, block size information. For some algorithms it is also important to
have round counts, and s-boxs, examples of this are RC5, variant Rijndael.
So restricting ourselves to simply algorithm, and URI is not reasonable.
More information will often be needed, and I think it's unreasonable to
house all the information on RC5 on different URIs, it can use any 2N bit
sized block, any sized key, and any number of rounds, the expansion rate is
N^3. Where if we embedded that information in the document itself, the
expansion rate is 0. I suggest we add keysize=, blocksize=, rounds=, sbox=
entries as options. The sbox entry would be problematic at first, however ma
king use of "num,num,num,..." for a row and using ",," to designate next row
would be reasonable, performed from 0 to N.



I think I've also found an acceptable way to verify encrypted data that has
later had a signature computed on it. There are 2 ways that I see, a small
signature algorithm, or a MAC. Either of these would be simple to add
programatically, and since they would internally verify the encrypted data,
the outer signature would be useful for determining that the other data was
untampered.  The option of signing the encrypted encryption keys doesn't
work very well since at some point there must be a secret, and if that
secret can be computed by an evil reciever the signed document can be
changed (see PKCS #1 v1 for reference on how this can be done).



This leads me to believe that we need to either combine the
signature/encryption groups (which would be very reasonable to me if it
weren't for the fact that DSIG is basically finished), or we need to create
a small sig standard. No canonicalization would be needed because there
would only be the ciphertext for reference, so we need not concern ourselves
with whether or not the XML is even valid, let alone standard. Since this
will be binary data anyway it is very possible to create a pure binary
standard, such as assigning the internal signer for the entire document (the
one that will sign inside the level 1 ciphertext, as there may be many
levels), that signer creates a signature (or MAC) across the individual soon
to be ciphertexts, and places the signature (always of length k) at the end
of each soon to be ciphertext, certifying them against tampering before
signing. This would eliminate the need for someone to be able to decrypt the
entire document to sign it's authenticity (i.e. it's really not necessray
for a notary public to know the details of your contract, only that you
really are the person who signed it.

                    Joe

Received on Friday, 22 December 2000 17:13:27 UTC