[xmlsec] Certificate priority in verifying signatures

[Andrea Ieri]

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