Address inconsistencies between RFC5280 and CABF BRs/X.520

[robplee]

I'm not sure what the exact answer is to this situation but I wonder if the configurable lints (#624 / #648 ) work might be able to help us?

A problem we have is where there are inconsistencies between standards. For example RFC5280 states that a subject:postalCode may be at most 16 characters long and we have a lint enforcing this: "e_subject_postal_code_max_length"/lint_subject_postal_code_max_length.go".

However, the CABF BRs say that the max length for a subject:postalCode is that stated by X.520 which is 40 characters. So the issue is that zlint will throw an error about certificates that are considered valid by the CABF BRs. I think this could be an issue for CAs using zlint for pre-issuance linting.

I've had a look at where the BRs specify limits not from RFC5280 and I think it's only lengths of postalCode attributes where we have an issue but I'm happy to be corrected on this if I've missed any attributes where we have inconsistencies between the RFCs/other standards that we lint against.

[zakird]

I hold pretty strongly that ZLint is not the right place to adjudicate discrepancies between standards. We broadly want to create lints that match published standards as exactly as possible. We've gotten into trouble in the past when we do otherwise. If 5280 and the BRs have two contradictory statements, then we should have two contradictory lints that have the attributed source and match the standard. This allows two options: (1) The standards bodies can (and should) figure out what they need to do to resolve the discrepancy, and (2) CAs and researchers can decide which of the sets of lints that they want to use. In the end, it's up to the CA to decide whether they want to ignore what's written in 5280.

[robplee]

Hi @zakird I completely agree that zlint is not the place to decide which standards to enforce or what rule to apply where there are contradictions. My thinking is also that we'd have lints for both the CABF/X.520 length in addition to the existing RFC5280 lint for postalCode length. Then users of zlint could choose if they want to configure the RFC lint to disable it (it would be enabled by default) if they wanted to allow issuance of certificates with a 17 character postal code as is allowed by the BRs.

The issue/PR I linked in my first post was about making lints configurable so I think this is a place where we might be able to use that feature.

[zakird]

Yes! I'm down for also having a CABF/X.520 lint in place. I don't think this is a matter of having a configurable lint though, I think we want two lints — one associated with each standard.

[robplee]

I think I have not explained myself well at all 😆. My thinking is two lints, one for RFC and another for CABF/X.520. Then we want a means for users to avoid running/failing the RFC lint if one wants to follow the CABF/X.520 version of the rule.

My thinking was by making the RFC lint configurable we could achieve it not failing and returning NA/NE instead but I am open to other suggestions. I know there also exists the linting "profile" concept (#595 ) - maybe a profile would be a better solution where it would include all but the RFC5280 postalCode lint.

[zakird]

I think in this situation, the user would be best off simply excluding the RFC5280 lint from the corpus, which I think the APIs already support. I do this the lint is failing and we don't want to have the lint pretend otherwise, we're just ignoring it as a lint in its entirety. I also agree that this could be handled with a Profile, which seems like it's a good fit for this type of configuration.