Re: [DNSOP] meaning of tag "match" for CAA RDATA

[Mark Andrews <[e-mail]>]

> On 8 Feb 2018, at 3:26 am, 神明達哉 <[e-mail]> 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.
> 
> Although the boundary is not very clear, Section 5.1 generally seems
> to talk about the DNS-level syntax (e.g. what should/should not appear
> in wire as a DNS message or in a zone file), while Section 5.2 and
> later mainly talk about the semantics at the application layer
> (something that validates certificates).  Since the above text is in
> Section 5.1, I first thought "matching of tag values" was a DNS level
> concept.  But then it's not clear to me what it actually means.
> 
> 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.

When you load from disk you can’t know if the signer was CAA aware or
not.

UPDATE has to behave as is the records are opaque as the UPDATE client
has no idea whether the server is CAA aware or not.  You need to send
perfect matches to delete a individual record.

> It may also be related to Section 5.1.1, which states:
> 
>   The canonical presentation format of the CAA record is:
> 
>   CAA <flags> <tag> <value>
> [...]
>   Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
>      case.
> 
> which might read, for example, as 'dig' should present the tag field
> with lower-case letters.  But 'dig' currently doesn't work that way.

Dig presents data such that it can re-entered into a master file.  Others
can transform it if they wish.

> Could someone more familiar with the background of CAA clarify these
> points?

The CA's can deduplicate if they need to after performing DNSSEC
validation.

> Thanks,
> 
> --
> JINMEI, Tatuya
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]