[xmlsec] Certificate priority in verifying signatures

[Aleksey Sanin]

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
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec