RE: Latest Rough Draft

Stephen,

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Tuesday, April 24, 2001 10:13 AM
> To: jimsch@exmsft.com
> Cc: 'Joseph M. Reagle Jr.'; 'XML Encryption WG'
> Subject: Re: Latest Rough Draft
>
>
>
>
> Jim,
>
> > > 1. Is whitespace in KeyName significant?
> > >
> > > <ds:KeyName xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
> > >                       John Smith
> > >                     </ds:KeyName>
> > >
> > > Problem if not defined is how to match KeyName value to a locally
> > > stored key. This might be more important than for dsig since
> > > I'd guess KeyName is more likely to be processed programmatically
> > > for encryption. I'd assume we're ripping leading and trailing
> > > whitespace? (Is there a generic string comparison in schema?)
> >
> > Welcome to the world of XML.
>
> Thanks;-)
>
> > My take on this has always been that the
> > interpretation of the value for KeyName is left to either the local
> > environment or the application space.  In general I would
> expect that the
> > whitespace compression routine is applied to the name
> before matches occur,
> > however if the name was something like
> "smtp:jimsch@exmsft.com" then that
> > might convey additional information to the application.
>
> I'd argue that not doing witespace compression doesn't make senses for
> KeyName (assuming you could put something like %20 in if you
> really need
> it). Justification is that KeyName is an artifact of this
> (and dsig) and
> no else should really be messing with it.
>
> > > 3. Why are transforms really needed when cipherData is a URI? I'd
> > > think you could just mandate that the real cipherData MUST have an
> > > ID attribute. If some simple encoding stuff has to be handled then
> > > just add such an attribute there too.
> >
> > This construct was created to be able to hold the data
> externally to the
> > current XML document.
>
> Fine. But transform allows lots of silly cases which I don't
> believe are
> needed here. Why overcomplicate it? Still sounds to me like an ID
> and encoding attribute (inside cipherData) would be ok,
> unless there's an
> expectation that someone's going to de/re-encode the
> ciphertext which is
> normally a pretty useless thing to do.

Yes I agree that it allows for lots of silly cases, but I am not willing to
say that all of the other cases that it allows for that ID does not allow
for are silly.

>
> > > 5. NameKey vs. KeyName seems wrong. Why two different tags for the
> > > same thing? I really don't see these as different.
> >
> > In example 2.2.2 NameKey is incorrectly used.  The
> difference between them
> > is that NameKey is an attribute on EncryptedKey to name a
> key, while KeyName
> > is a reference to a key by name.
>
> I'm a native English speaker (the Irish-English variety:-)
> and the above
> isn't at all meaningful to me. Maybe try explain by saying
> how the code
> dealing with them differs?
>
> Oh! Maybe I've got it now - is NameKey supposed to be
> "InternalKeyName"

According to my mother, I am not a native English speaker of any variety.
:-) I don't like using "InternalKeyName" because the key named could be
referenced by that name across multiple documents.  Consider a protocal
where a set of keys are exchange and "named" by a server/client (session key
negotiation).  The session keys would then be used by name in future
documents.  Possibly better for you would be
"IdentifyTheKeyByThisNameInTheFuture".

>
> > > 7. Regardless of the outcome of how to re-use ds:KeyInfo,
> defining an
> > > enc:KeyInfo is confusing and error prone. If we don't just
> > > use ds:KeyInfo
> > > (or an extended flavor of that) then call it something
> different, e.g.
> > > enc:ExtendedKeyInfo or whatever.
> >
> > See above -- My take on changing the name is that this is
> not reasonable.
> > You need to be looking at schemas all of the time since
> "short" names are
> > going to be consumed by a large number of schemas.
>
> We disagree then. I've always found things like ds:KeyInfo
> and enc:KeyInfo
> with overlapping syntaxes just cause bugs.
>
> > > 9. There's an ambiguity in the use of KeyInfo in
> > > EncryptedData and EncryptedKey:
> > > does the KeyInfo relate to the key used to encipher or
> decipher? The
> > > description of EncryptedType says the former, which is fine,
> > > and probably
> > > correct, but 3.4 refers to the key for decrypting. Hopefully,
> > > just a matter
> > > of text, but possibly confusing later if we're not careful.
> >
> > KeyInfo always refers to the key used for decipher.  See
> the note on NameKey
> > above.
>
> Isn't that wrong? An X.509 cert (and other ds:KeyInfo cases) contains
> the enciphering key in this context.

I was refering to the case of keyInfo being used in EncryptedData and
EncryptedKey.  If you want to look at KeyInfo in a general case, it contains
a key (or instructions on how to get a key).  Nothing is said about the use
or type of the key contained therein.  It could be Signing, Decryption,
Authentication, a second key for key agreement algorithms.  KeyInfo just
holds something that can be turned into a key

>
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>

jim

Received on Tuesday, 24 April 2001 14:22:59 UTC