W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2001

Re: Minutes of 011119-tele

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 28 Nov 2001 17:10:57 -0500
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: xenc <xml-encryption@w3.org>, merlin <merlin@baltimore.ie>, "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>
Message-Id: <20011128221058.6A721B3@policy.w3.org>
On Wednesday 28 November 2001 02:39, Takeshi Imamura wrote:
> You added the CarriedKeyName element to the end in a schema in Section
> 3.4.1, while you added it to the head in an example in Section 2.2.2.
> Which is correct?

Oops, the example indicated my intent; the schema represents schema 
extension constraints. I meant to go back and make sure they both agreed 
but forgot -- end of the day <smile/>. I've moved the CarriedKey to [t19] 
and added the correct text below.

> >The Nonce attributes is actually part of the CipherData structure which
> > is shared by EncryptedData and EncryptedKey. So it's not as easy as
> > simply removing the attribute from EncryptedKey. I'm getting a little
> > rusty on Schema but I don't think there's an easy way to restrict the
> > presence of EncryptedKey's CipherData to be 0. Takeshi, what did you
> > have in mind, a new schema structure, or some text?
>
> I agree with you that it is not so easy to remove the Nonce attribute
> from the CipherData element.  So how about containing the attribute not
> in the element but in the EncryptedData element, though it may be a
> little weird...

that is awkward. thinking ...

1. We could make it an element in EncryptedType and restrict it away in 
EncryptedKey.
2. We could remove it from EncryptedType and extend it onto EncryptedData 
exclusively; but I'm not sure how to extend a "deep" structure, my 
extensions to date have only been at one level. I suppose one would make 
the CipherDataType abstract, and then EncryptedData and CipherData would 
each have their own derivation (and EncryptedData has a nonce...)
3. Extending deep structure makes me think "redefine" might be approriate, 
but that's so heavy and requires on to break the schema up!

We should think about this, and I'll send an email to xmlschema-dev .


> >(Honestly, I still don't understand the problem enough to do the right
> >thing, so specific direction/text would be welcome. For example, with
> >respect to what Blair said on the teleconference, processing step
> > 4.2.3.3 should solve the problem, right? Say I have a key "12345". I
> > want to encrypt it and tend to stick nonces on all my encrypted data
> > for consistency's sake. So now, prior to encryption, I prepend the
> > nonce "89", encrypt the value, and that is now the content of
> >EncryptedKey/CipherData/CipherValue. When I do the reverse, I of course
> >remove the nonce "89" from "8912345" before handing "12345" off to any
> >cryptographic process. I'm not sure what the problem is, or what is
> > "being ignored" in Takeshi's processing...)
>
> What algorithm do you use?  If you use RSA, there may be no problem, but
> if a key is of Triple DES and you use Triple DES Key Wrap, how do you
> encrypt the key?  According to the steps in the spec, encryption may
> succeed, but decryption will fail because the length check in Step 1 will
> fail.

Aha! Thank you, I understand.

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Wednesday, 28 November 2001 17:12:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT