Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

>
> I don't think so. Especially for digital signatures, there are (and 
> will come) many legal constraints from signature laws. And they will 
> in no way allow to make transmission of such an important parameter 
> like the signature algorithm optional. You're right that the 
> application context can be fixed for a particular application and that 
> it's completely redundant to always transmit this again. But - for 
> things like long-term-validity, I don't think that making this 
> optional buys us anything. And - XML IS redundant ;-))

But the same applies to EncrytpionMethod! You have no SignatureMethod 
--> you could not
validate signature. You have no EncryptionMethod --> you could not 
decrypt message.
If the application has no SigantureMethod in the context and this 
parameter is not specified
then signature is *invalid*. I am not sure I clear understand legal 
constrains in this case
but I am not a lawyer and may be you are right.

BTW, if the EncryptionMethod is not specified then application may 
"guess" incorrectly and
the result is *more* dangerous! In signature case, the signature simply 
is not validated and
this is normal situation (application must be able to handle it). In the 
encryption case, if the
data decrypted with wrong method (it's possible for stream ciphers, for 
example) then this
"bad" data are sent for further processing and it can damage a bad 
implemented system.
Yes, I know that the good implementation must verify decrypted data 
integrity but I am not
sure that everyone will do it.

I also can imagine situations when application wants to use XML 
Signature and cares about
memory usage and signed document size (embeded or real time systems?). 
If such application
uses only one signature method I do not see why the standard should 
prevent application
from using it from the context instead of writing it in the XML document 
again and again.


Aleksey.

Received on Tuesday, 2 April 2002 02:24:28 UTC