RE: Latest Rough Draft

Stephen,

> -----Original Message-----
> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Stephen Farrell
> Sent: Wednesday, April 18, 2001 9:45 AM
> To: Joseph M. Reagle Jr.
> Cc: XML Encryption WG
> Subject: Re: Latest Rough Draft
>
>
>
> Hi,
>
> Just had a read through the latest and here are my comments.
>
> Regards,
> Stephen.
>
> 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.  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.

>
> 2. Super-encryption: if an implementation reacts to ciphertext by
> attempting decryption where possible, what should it do if it sees
> super-encryption? Keep going 'till there's no EncryptedData it knows
> how to decrypt?

This depends on the application.  Some applications will attempt to decrypt
everything up front, in which case recursion is what happens.  Some
applications will decrypt on demand.  Application behavior is not defined by
this spec.

>
> 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.  It could be a base-64 encoded document that the URL
points to, in that case the transform would remove the base-64 encoding.  It
may be a mime message that is pointed to, in that case the appropriate
transform could get the binary content to be decrypted.  This is just a hole
to allow for the encrypted octet stream to be removed from external (and
internal) documents.

>
> 4. KeyInfo in 2.2.2 has a namespace, but doesn't in 2.2.1.
> Should these
> be the same?

We are stilling working on getting the schema for KeyInfo correct.  We have
run across some semantic problems dealing with extending the DS version or
creating our own.  The examples reflect this open issue.

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

>
> 6. Using ds:DigestMethodType for EncryptionMethod seems
> weird, even if
> they're syntactially the same. Suggest changing this or including a
> comment explaining the weirdness (i.e. the reason to do this).

See above about schema issues.

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

>
> 8. I suspect that there are some rules about cipherData which must be
> satisfied if the KeyInfo is missing. If so, be nice to limit things so
> that we know what's what.

There are no rules that I know of.  What type are you looking for?  The
assumtion is that the key would be well known to the decrypting party.

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

>
> --
> ____________________________________________________________
> 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 Monday, 23 April 2001 01:26:13 UTC