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
