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?)

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?

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.

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

5. NameKey vs. KeyName seems wrong. Why two different tags for the 
same thing? I really don't see these as different.

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

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.

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.

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.

-- 
____________________________________________________________
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 Wednesday, 18 April 2001 12:45:42 UTC