Signature validation filter config

[Cantor, Scott]

On 4/14/14, 6:09 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>1) The default value for 'requireSignedMetadata' in V2 was FALSE.

I think you mean requireValidMetadata.

>As I recall this was because of the order in which it was added (later
>than the
>filter).

What filter are we talking about?

>I feel reasonably strongly (but am prepared to be out-argued) that
>we should take advantage of the version revision and flip this to be TRUE
>by
>default. It stops an obvious attack when combined with the default
>implementation.

I think there's some confusion here perhaps, but if we're talking about
the validity thing, we can freely change the default because the flag was
on by default in the old Spring parser. So changing the default in the
class should be fine (and we should make sure all defaults in the classes
match the defaults in the parsers whereever we can).

>"The signature validation filter will have options that allow the
>specification of public keys, certs, and CRLs instead of requiring a
>separate trust engine to be defined (though that will still be supported)"
>
>I missed the meeting in which this was discussed.  It is very easy to add
>this, but I also feel that greater ease of use would be by *not* allowing
>that, but a sub set - the certificate file

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.

>The remaining 2% can configure their metadata as they want.  Adding
>'certificateFile' makes for more complication in the parser but not much.
>It will give (IMO)  a much better end user experience - particularly if we
>use property replacement on that file.

Yes, I certainly agree. I just think it would be nice to be able to omit
the certificate.

-- Scott