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.
 
> > 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" 

> > 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.

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

Received on Tuesday, 24 April 2001 13:13:46 UTC