I'm not too sure I agree on overriding certificates via command line being a bad idea, but it's definitely true that if the federation were not using self-signed certificates there would have been no issue in the first place. Thanks for the comments!
Andrea On 02/09/2011 09:33 PM, Aleksey Sanin wrote: > 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
