Question regarding cabf_br/lint_subject_contains_malformed_arpa_ip

[cardonator]

We got a hit on this lint for a cert that has a SAN in the format of:

*.0.0.1.f.5.4.3.ip6.arpa

Looking at this lint, it is producing a warning and I just want to make sure this lint is being helpful in this case.

The extended warning I'm getting is

name \"*.0.0.1.f.5.4.3.ip6.arpa\" has too few leading labels (9 vs 32) to be a reverse DNS entry in the \".ip6.arpa\" zone.

The rule this references is BR 7.1.4.2.1 which doesn't really seem to reference anything other than reserved IP address blocks. I don't think this is problematic according to the BRs because it doesn't say anything I can see about treating IPv6 addresses in the ARPA domain as something other than normal domain names unless I'm missing something.

Can anyone provide any clarity on this lint, purpose, reasoning behind resulting in WARN vs. NOTICE? Is this a community a lint possibly from cablint that is misclassified?

[cpu]

👋 @cardonator Thanks for the question.

I wrote this lint myself before I had much experience with ZLint and when the guidance on what status to return for different cases was a little bit less established. I suspect I might have been too strict here but I'll have to rebuild the context. I have a memory of an RFC that indicated reverse IPv6 addrs should always be fully expanded. I'll get back to you later today and update the lint if required.

[cpu]

I have a memory of an RFC that indicated reverse IPv6 addrs should always be fully expanded.

I was thinking of RFC 3596, specifically §2.5 "IP6.ARPA Domain". That section seems to me to be fairly explicit that each nibble of the IPv6 address is represented by a hex digit, like shown in the example address conversion:

For example, the reverse lookup domain name corresponding to the address

4321:0:1:2:3:4:567:89ab

would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA.

That's how I arrived at the value of 32 expected labels for each IPv6.ARPA domain used by the lint:

zlint/lints/cabf_br/lint_subject_contains_reserved_arpa_ip.go

Lines 43 to 47 in 9bba7b7

	// rndsIPv6Labels is the expected number of labels for an IPv6 reverse DNS
	// name (not counting the rdnsIPv6Suffix labels). IPv6 addresses are 16 bytes.
	// RFC 3596 Sec 2.5 uses one *nibble* per label meaning there are 16*2
	// expected labels under the rdnsIPv6Suffix.
	rdnsIPv6Labels = 32

In my mind based on RFC 3596 *.0.0.1.f.5.4.3.ip6.arpa is not a well formed IPv6 reverse address. That said, I don't think the BRs consider it a violation. Because of that I think the lint_subject_contains_malformed_arpa_ip lint should probably be moved from the cabf_br category to the community category and demoted to a warning result.

I think the related lint_subject_contains_reserved_arpa_ip.go deserves to remain in the cabf_br category with an error level finding (I think we agree that a reverse DNS entry for a reserved IP address is no good).

@cardonator @zakird @sleevi Does my evaluation match up with what you folks think? Is there a qualification of the BRs I'm missing that would merit keeping this lint as-is?

[sleevi]

@cpu

While I'm fine with moving it community, I suspect this is something the CA/B Forum should take up, because I would suggest the intent is to forbid it via 3.2.2.6 of the BRs and through 3.2.2.4's prohibitions on wildcards-for-IPs, and because for the reasons you cite, it's unclear to me how a CA could fulfill the obligations of the BRs for such a name.

The 3.2.2.6 argument is that ipv6.arpa is registry controlled (c.f. RFC 3172, aka BCP52), and while subdomains of ipv6.arpa are covered in Section 4, the direction given in BCP49 still delegates those subdomains to the RIRs.

So *.0.0.1.f.5.4.3.ip6.arpa is something registry controlled, although the BRs leave that definition for registry controlled as fluid, and the PSL (intentionally) doesn't represent the .arpa space within its file.

So if it's fine, it's on a technicality and oversight, and while I'd be curious how @cardonator validated it, I entirely suspect that's a conversation for the CABF to see about making more explicit.

[cpu]

Because of that I think the lint_subject_contains_malformed_arpa_ip lint should probably be moved from the cabf_br category to the community category and demoted to a warning result.

One correction: I had more coffee and realized the existing lint already treats this case as a warning and not an error. The only change would be to move it to community. Edit: I also think warn (vs info) is the correct response in this case since the deviation from RFC seems fairly clear

zlint/lints/cabf_br/lint_subject_contains_malformed_arpa_ip.go

Lines 73 to 76 in 9bba7b7

	return &lint.LintResult{
	Status: lint.Warn,
	Details: err.Error(),
	}

While I'm fine with moving it community, I suspect this is something the CA/B Forum should take up, because I would suggest the intent is to forbid it via 3.2.2.6 of the BRs and through 3.2.2.4's prohibitions on wildcards-for-IPs, and because for the reasons you cite, it's unclear to me how a CA could fulfill the obligations of the BRs for such a name.

@sleevi Thanks for weighing in. That makes sense to me. I agree with you that this feels like a technicality that should be clarified in the BRs and raises questions about the validation.

Ultimately moving the lint to the community/ category won't change the user experience until we have implemented a way to choose a subset of lint categories to use when linting a certificate. For that reason after giving this some more thought I'm slightly biased towards leaving this lint as-is while the CABF discussion unfolds and spending the time implementing the required API change to select lint categories (#344). Afterwards based on the state of the discussion we can update this lint.

[zakird]

This doesn't strike me as something worth moving offhand, at least until this is resolved in CA/B Forum. The error case seems to match the CABF BRs, and a warn doesn't seem inappropriate since it would be against community expectations to issue a wildcard like that.

[cardonator]

Thanks for the feedback all.

@sleevi The common root of 0.0.1.f.5.4.3.ip6.arpa was validated using a DNS TXT Random Value. The Random Value was generated and set by the customer correctly according to the BRs. DNS tools are able to correctly pull DNS records at this level. (For clarity, I did modify the provided SAN to be a format vs. the actual customer submitted domain) However, I can see room for a question about if a validation for 0.0.1.f.5.4.3.ip6.arpa should be able to show control for every possible label under that address.

I agree that arpa SANs are left vague in the current BRs and it's not entirely clear how arpa reverse names should be treated in general. I do think BCP49 makes a good case that they should be treated as if they are IP addresses.

Would you suggest spinning up a conversation on this topic in SCWG or MDSP?

@cpu given the lack of clarity around this, I would agree that leaving it where it is makes the most sense. RFC 3596 does seem to suggest this should be considered a malformed SAN. I do think it might be helpful to add referenced to RFC 3596 and BCP49 in the lint itself somewhere, even if just in the description.

[timfromdigicert]

I'll put it on next week's Validation WG agenda.

[cpu]

RFC 3596 does seem to suggest this should be considered a malformed SAN. I do think it might be helpful to add referenced to RFC 3596 and BCP49 in the lint itself somewhere, even if just in the description.

@cardonator This is good feedback, thanks! I made a clumsy attempt at improving the situation with
#345 It isn't perfect but I think is a step in the right direction while the larger discussion is in progress.

[zakird]

We're coming up on a year since this issue was created. @sleevi @timfromdigicert was this resolved in CABF?

[timfromdigicert]

It has not been resolved, but only because we've been discussing other things.

I can put it on next Thursday's agenda again if there's interest in discussing it.