Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both

[Scott Morizot]

On 2 Aug 2013 at 22:25, Mark Andrews wrote:
> In message <51FB9C18.23133.401EA34 at tmorizot.sd.is.irs.gov>, "Scott Morizot" wri
> tes:
> > Hello all,
> > 
> > I ran into an interesting situation resolving dfas.mil. It appears that 
> > they have attempted to roll their ZSKs to algorithm 8 while leaving their 
> > KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs 
> > for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for 
> > each record set in the zone MUST include at least one RRSIG for each 
> > algorithm. (The distinction between KSK and ZSK is an operational 
> > convenience and not part of the standard, per se.) The relevant excerpt 
> > from Section 2.2 of RFC 4035:
> > 
> >    There MUST be an RRSIG for each RRset using at least one DNSKEY of
> >    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
> >    itself MUST be signed by each algorithm appearing in the DS RRset
> >    located at the delegating parent (if any).

> Because the requirement is *only* on the signer.  You will note
> that the validator is NOT required to check for this as part of the
> list of things it is supposed to check for and that is a deliberate
> design decision.  If the signer follows this and the timing rules
> the zone will not be treated as bogus.  The unbound developers
> didn't realise this initially and added unspecified checks to their
> validator.

I hadn't noticed the differences between 2.2 and 5.3. Interesting. So you 
can have signing errors (at least according to the standard) that don't 
result in validation errors.

Thanks,

Scott