At Thu, 8 Feb 2018 08:25:35 +1100,
Mark Andrews <ma...@isc.org> wrote:
> > I happen to have this question while reading RFC6844: what does the
> > "matching" mean in the following description of Section 5.1?
> >
> > Tag: The property identifier, a sequence of US-ASCII characters.
> >
> > Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
> > through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT
> > contain any other characters. Matching of tag values is case
> > insensitive.
[...]
> > Does this mean, for example, we should perform case-insensitive
> > comparison of this field when we compare CAA RDATAs? (If so, at least
> > ISC BIND 9 isn't compliant to the spec; it doesn't care about the case
> > of the tag field when loading or serving or updating or signing a CAA
> > RR).
>
> Why should it care about the case? ABC is different to abc as far as
> DNSSEC and handling of unknown record types is concerned. A signer
> that is CAA aware could remove “duplicates” that differ in the case
> of this field but nothing else can.
I didn't intend to say it (DNS implementation) should care about the
case. My point (or question) was the RFC text can be ambiguous. On
re-reading RFC3597 I now see it would clearly violate Section 6 of
RFC3597:
specifications for new RR types MUST NOT specify
type-specific comparison rules.
if it meant case-insensitive RDATA comparison. But the current text
of RFC6844 made me think whether the RFC erroneously violated it or it
meant something else. It would have been clearer if "Matching of tag
values is case insensitive" were somewhere after Section 5.1, or at
least it explicitly said this is about CAs that use the CAA, not for a
DNS implementation.
I'd also wonder what the "Canonical Presentation Format" means then:
Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower
case.
so, for example, we can't always safely dump a validly loaded zone
containing CAA whose tag has an upper-cased letter into a file in the
"canonical presentation format" and then re-load it, since the dump
can result in false duplicates.
...and now I see there was almost exactly the same discussion about 2
years ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16810.html
Perhaps it's pretty clear that the current text of RFC6844 is very
confusing (if not wrong) and worth some errata again?
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
