Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14)

[Samuel Weiler <[e-mail]>]

Thank you for the history.  Going forward, what's the best thing to do 
in the interest of interoperability?

It may be worth asking not only what signers do but also what existing 
validators do.  If we've only seen problems with this in the wild once 
(perhaps?) then there may be an ugly but interoperable answer we can 
document for the future.

-- Sam


On Mon, 16 Jan 2012, W.C.A. Wijngaards wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Sam,
>
> Just to clarify my previous mail: what we implement is RFC3755.  This
> states no downcasing in the rdata of NSEC and RRSIG.
>
> To see how we came to this implementation I searched through mail from
> 2007.  I found that the reason for this is that we first implemented
> RFC4034, but that typecodelist in 4034 contained errors (double HINFO,
> includes NSEC and RRSIG in a copy-paste-rename-mistake from RFC2535 or
> something like that).  This brought to light differences in
> implementations from before RFC4034 and after RFC4034.  Because of
> this we changed to implement RFC3755 and in dnssec-bis-updates-06 it
> is then listed this as something to fix in RFC4034, and it states the
> RFC3755 rules.  This is there until -16 (last week) where it changes.
>
> Downcasing is not necessary in NSEC and RRSIG, downcase before
> signature verify and create is only needed in case
> dname-compression-and-decompression has removed upper-lowercase
> differences.  The domain names in the rdata of NSEC and RRSIG are not
> compressed, and thus case is preserved.  So, a downcase operation is
> not needed (in principle).
>
> So, currently we stay with RFC3755, because we want to implement
> standards RFCs, and not drafts if possible.  RFC3755 is obsoleted by
> RFC4034, but as already discussed on namedroppers, its typecodelist
> was erroneous. And therefore we ignored that list in RFC4034.  Thus
> our implementation matches the dnssec-bis-updates draft versions -06
> to -15 in this respect.  Regardless of the outcome of this
> interoperability problem, we will implement RFCs and thus the RFC that
> comes out of dnssec-bis-updates, whether that downcases both(4034),
> neither(3755) or something else(draft-16).
>
> Best regards,
>   Wouter
>
> On 01/16/2012 10:46 AM, W.C.A. Wijngaards wrote:
>> Hi Mark,
>>
>> On 01/13/2012 11:50 PM, Mark Andrews wrote:
>>>>> I don't recall seeing much discussion of the below. =A0As
>>>>> doc editor, I w=
>>>> ould
>>>>> like to hear an extra voice or three chime in before I fix
>>>>> this.
>>>>>
>>>>> As I understand Ed's message, the (signer) name in an RRSIG
>>>>> does need to =
>>>> be
>>>>> downcased. =A0The next name in a NSEC RR does NOT need to be
>>>>> downcased. =
>>>> =A0Is
>>>>> that right?
>>>> +1. Sometime back there was an email thread (which I can't
>>>> locate now) where the signature verification failed if you
>>>> don't downcase for something in .US zone.
>>
>>> named downcases the RRSIG's Signer's Name named does not
>>> downcase NSEC's Next Domain Name.
>>
>> unbound does not downcase RRSIG signername and does not downcase
>> NSEC nextdomain name for DNSSEC validation.
>>
>> ldns rr canonicalisation does not downcase RRSIG signername and
>> NSEC nextdomain.  So, this is for ldns-signzone and verify.
>>
>> opendnssec produces lowercase signernames in its RRSIGs, and thus
>> it does not matter if they are downcased or not (for the RRSIGs
>> produced by the opendnssec signer).
>>
>> It started with HINFO, where, today, the rdata is not downcased by
>> unbound, ldns.
>>
>> Best regards, Wouter
>> _______________________________________________ dnsext mailing
>> list [e-mail] https://www.ietf.org/mailman/listinfo/dnsext
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPFDWfAAoJEJ9vHC1+BF+NZL4P/Rrs1hl9q02hlU8c83M1BgxT
> v3KPpVQ2369LpY5Vr/0SOUu5W8l8J76pcpkkameKg4PKfW2nzrdUVKD7i/KBmC3h
> 9C9pDzLyamXofG7oxCFAFXOYYJkJ4tXjr31SHfhxsb0YxfvuZE80ZZiOk5+3IhJF
> kWQnUOoIMQMXttCLW6ecHk/i7JhE6gn/7+P8uw3ElunKXqZSleZ42cKIx5WHK+Wg
> 0VNOd3SctuHw41HrtN9O0na7HN/FQr38Gq3tE5+UtFxv1h7hLs+nH2X1Zk2gM9bx
> 5LXpOdMyvuDlHr7jvyPf4v6JSP2XhbRENe3DNonixK41TQ4laDlHbmbWsFQyjZYD
> +CN8vO+w4Mh0TeB6QLEfQAO922l4mR7ts8FwgDYCl0nejoNUU99bb1VVY/6Laa22
> jd8CwcCYqI/pvxcuuTf/kaqOryizyJ5oBFgDSlaKr42AHqmG6vVtXZoamr1Zi248
> UjHDe2bYnY+uf3OpfVvI3Smbs6vFoBY0Xkj4RMAlupPpNvEXeJwtx+k1TQ/E9f7n
> Yh/QMz32Q86TTXR33/9HDIJvF6e7b2WLMGkOUZVTMMzqI3EZiPg2mDbzAhcs1j1G
> tgIweyfpSwYWhykPIIYL0FHCxHsqF2dm59wFn2Bo0B9fdTdoVB0D2iW+9ctnrZbl
> g/mH7UFd4xsNImX2ZNEG
> =n3EK
> -----END PGP SIGNATURE-----
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext