Signature validation filter config

[Brent Putman]

On 4/14/14 10:21 AM, Rod Widdowson wrote:
>>> 1) The default value for 'requireSignedMetadata' in V2 was FALSE.
>> I think you mean requireValidMetadata.
> No  I really do mean "requireSignedMetadata".  It's an attribute inside
> xsi:type="sec: SignatureValidation".  If it is not specified (or defined to
> be false) then the SignatureValidationFilter will not complain if the
> supplied metadata doesn't have a signature.  With it true
> SignatureValidationFilter complains if the signature fails or if there is no
> signature.  My feeling is that having the default be false opens up to an
> attack in which unsigned metadata is provided as a replacement to signed
> metadata.
>  

Yes, I agree.  I don't have any particular recollection as to why that
defaulted to 'false'.  It might just have been an oversight.  I'm
looking at it right now, so I just go ahead and change the actual filter
to default to 'true'.



>> I'm fine with a subset, but I probably would like to see both cert and
>> public key supported, just because it's gratuitous to even require a cert
>> there.
> Good point.   I'll see about adding both.
>

I can think of at least 2 use cases where the user would want or need to
wire in multiple validation certs/keys: 1)  for the dynamic metadata
resolvers(s), where you really do have multiple concurrent trust
material 2) key rollover, i.e. the metadata publisher announces that
they are switching to a new key on a particular data, and the deployers
want to wire in both keys so the change is transparent. If we think that
those 2 cases are uncommon enough to warrant doing away with Chad's
original plan, then I suppose those people would just go to the full
trust engine option.

If we do go with the attributes option, should we consider making those
XML delimited lists of certs/keys?  Maybe that's too complicated...