W3C home > Mailing lists > Public > xml-encryption@w3.org > December 2000

Potential Start Point

From: Joseph Ashwood <jashwood@arcot.com>
Date: Tue, 12 Dec 2000 16:46:23 -0800
Message-ID: <0c9501c0649e$21475ff0$2a0210ac@livermore>
To: "Public XML Encryption List" <xml-encryption@w3.org>
I've started thinking on this and here's what I have so far. I know I'm very
new here, and I haven't made it completely through all the archives, but I
wanted to write this down before I forgot. I will warn you that this is very
much a deviation from the earlier assumptions made, the EncryptedNode tag,

I am certainly far from solving all the problems, but I think I've found a
reasonable way to add the keying information securely. I haven't had the
time to format it in the standard way so I'll just present a possible form.
I've put a lot of comments inline I hope what is comment and what is not is
obvious, if it isn't I'm sure I can clarify it.

<assymetric type=RSA-OAEP> //by specifically embedding the type up here
potentially large numbers of targets can be skipped
        <name>Joseph Ashwood</name> //should be optional, it is redundant
        //there needs to be more information here but I'm not sure what
    <X509Certificate>/*snipped to save space*/</X509Certificate>
    //should we include clear public keys?
    <private>/*optional, the private key encrypted with another encryption
algorithm as identified by this block being the target*/</private>
that the target is a symmetric block with the name RijndaelKeyForName

    <user> //optional, identifies the entity that has immediate access
without going through an assymetric phase
        <name>Gregory Ashwood</name>
    <name>RijndaelKeyForName</name> //optional, name for use in targetting,
in this case it is targetted by the assymetric block above
    <cipher>Rijndael</cipher>//the name of the cipher used
    <chainingMode>CBC</chainingMode> //the chaining mode used by the cipher,
not present with a stream cipher
    <terminationMode>cipherteststeal<terminationMode>//chosen instead of
padding mode because it is more generic, not present with MOST stream
    <keylength>128</keylength>//optional, the length of the key being used
    <blocksize>128</blocksize>//optional, the block size being used
    <keyValue>....</keyValue>//optional, the encrypted key value, this will
be either the target of another block or a direct decryption based on
knowing the key
        <IV>/*optional, the IV as needed by the chaining mode*/</IV>
        <symmetric>RijndaelKey2 <symmetric>//optional, identifies that the
target is a seperate symmetric tag with the name RijndaelKey2
        <assymetric>ComputerOwned2</assymetric>//optional, the target is an
assymetric block called ComputerOwned2
        <tag>Name</tag>//optional, for targetting data enclosed between tags
<Name></Name> in the rest of the document
        <file>/dev/null</file>//optional, identifies that this key
specification is used to decrypt the file /dev/null
        //I'm sure there's more types that I'm missing but they shouldn't be
difficult to add
        <direct>SDFJOIYtkluyfYTFLIYu</direct> //the value to be decrypted is
directly housed

<Name>HKGlsdfuasdfna;dsfjhauhkjhashjkHLKGjlhg</Name> //this is the target of

The result of this is that the user Joseph Ashwood can unlock the
<assymetric><value> data which will be the keyValue for RijndaelKeyForName,
that value is encrypted using OAEP for processing. RijndaelKeyForName
identifies in it's block that the key value is 128-bits, the block size is
128-bits, and the targets are a symmetric key block called RijndaelKey2
(where the key will decrypt the keyValue), ComputerOwned2 (where the key
will decrypt the private key), /dev/null (where the key value can be used to
decrypt the file), and the direct value which it is assumed will make some
sense after decryption. There may be more than one target block, where the
IV is kept, this allows a single symmetric block to encrypt multiple
locations with a stream cipher. The user Gregory Ashwood knows the immediate
access key for the keyValue block of RjindaelKeyForName.

All binary data needs to be base-64 encoded, or we could arrive at a
different convention, perhaps explicit, etc. I welcome any comments
criticisms, flames, whatever on my idea. To avoid the a->b b(pretends to be
a)->c problem, the assymetric and symmetric key values need to be signed as
a whole (as opposed to individually). However requiring this is often a very
expensive proposition (public key operations are expensive) so I don't think
it should be required. And we need to specify sign-first then encrypt (PKCS
1 attack) (whether the signature is inside or outside the encryption is a
trivial point, anyone want to pass judgement?), along with the suggestion to
sign the targetting information.
Received on Tuesday, 12 December 2000 19:46:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:59 UTC