I think the other way - overriding certificate through the command
line is a bad idea. Regardless, that's not intended way to use
certificates. You provide list of "trusted" certs and then you
sign data with a certificate that can be verified through trusted certs.
Aleksey
On 2/9/11 12:18 PM, Andrea Ieri wrote:
Apparently, the embedded certificate takes precedence over the one
specified in the command line!
Since I am new to concepts related to xml signing, there may be
something I'm overlooking here, but if my analysis is correct, this is a
serious issue as users would be misled into thinking that
roguemetadata.xml is signed by signer_bundle.pem while it is not.
Read the xml digital signature spec :)
Aleksey
From section 4.4 of the XMLDSIG spec:
"If |KeyInfo| is omitted, the recipient is expected to be able to
identify the key based on application context."
The way I read this agrees with the behavior of xmlsec1: using KeyInfo
first and going after external certificates only if the element is not
present. Regardless of this, I still think that a warning should be
thrown at some point. I don't know how other implementations deal with
multiple certificates, but letting the KeyInfo element override a user
specified cert makes MITM attacks a lot easier.
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
