[xmlsec] Certificate priority in verifying signatures

[Andrea Ieri]

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.
>>