Dnssec any valid rrsig - #160

DnssecClient required every RRSIG of an RRset to be valid. Hence an
RRset that additionally carried an RRSIG that can not be verified, for
example, one made with a key that is not (yet or anymore) in the
DNSKEY RRset during a key rollover, was considered bogus, and an RRSIG
made with an unknown key even caused a
DnssecValidationFailedException.

DnssecClient now groups the RRSIGs by the RRset they cover and
considers the RRset as verified if at least one of its RRSIGs is valid
(RFC 4035 § 5.3.3, RFC 6840 § 5.11). Only if none of the RRSIGs is
valid, the reasons are reported, or the exception is thrown.
Furthermore, RRSIGs made with a key from a zone that is not the zone
of the RRset, or one of its parents, are no longer verified, as they
can not verify the RRset.

Since key tags are not unique (RFC 4034 § 5.3.1), DnssecClient now
also tries every DNSKEY with a matching key tag, instead of only the
first one.

When verifying a DNSKEY RRset, DnssecClient checked whether the RRset
carried a valid self-signature and, independently, whether any DNSKEY
of the RRset is a secure entry point (SEP), e.g., referred to by a DS
RR of the parent zone. However, the SEP was not required to be the
key that signed the RRset. Hence a DNSKEY RRset that contained the
SEP, but that was only signed by another key without a chain of
trust, was considered as verified.

DnssecClient now remembers the DNSKEYs that validly sign the DNSKEY
RRset and only considers those as SEP candidates.

When verifying a secure entry point (SEP), DnssecClient only used the
first DS (or DLV) RR whose key tag matched the one of the SEP. Hence
the SEP was not verified if this DS RR used an unsupported digest
type, even if another DS RR for the SEP used a supported one. And if
the DS RR belonged to a different key with the same key tag, then
DnssecClient threw a DigestComparisonFailedException.

DnssecClient now considers the SEP as verified if at least one of the
DS RRs that refer to it verifies it. A DS RR refers to a SEP if its
key tag and its algorithm match the ones of the SEP (RFC 4035 § 5.2),
previously the algorithm was not compared. Furthermore, DS RRs with
the SHA-1 digest type are ignored if there is a DS RR for the SEP with
a supported stronger digest type (RFC 4509 § 3), so that an attacker
is not able to downgrade the digest type to SHA-1.