Yeah, that works, thanks! Andrea
On 02/10/2011 05:14 PM, Aleksey Sanin wrote: > BTW, just realized.... I think you can get what you want by > using "--enabled-key-data" (and "--list-key-data") command > line options for xmlsec utility. Simply disable reading of > certs from XML file completely and provide the signature key > (not necessarily in a cert) from the command line. > > > Aleksey > > On 2/10/11 7:22 AM, Andrea Ieri wrote: >> 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 > _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
