Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sunset subject:organizationalUnitName (Section 7.1.4.2.2.i, CAB-Forum BR) #643

Merged
merged 21 commits into from
Jun 13, 2022

Conversation

mtgag
Copy link
Contributor

@mtgag mtgag commented Oct 21, 2021

This pull request adds a lint for "Sunset subject:organizationalUnitName" - Section 7.1.4.2.2.i of CAB BR (v1.7.9 - https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.9.pdf). In this pull request the time for the CABFBRs_1_8_0_Date in time.go (from 21st of August to 25th) has also been adjusted (see Section 1.2.1, https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf) and you may consider merging only this change to the main project.

v3/util/time.go Outdated
@@ -63,7 +63,8 @@ var (
CABFBRs_1_6_9_Date = time.Date(2020, time.March, 27, 0, 0, 0, 0, time.UTC)
CABFBRs_1_7_1_Date = time.Date(2020, time.August, 20, 0, 0, 0, 0, time.UTC)
AppleReducedLifetimeDate = time.Date(2020, time.September, 1, 0, 0, 0, 0, time.UTC)
CABFBRs_1_8_0_Date = time.Date(2021, time.August, 21, 0, 0, 0, 0, time.UTC)
CABFBRs_1_7_9_Date = time.Date(2021, time.August, 16, 0, 0, 0, 0, time.UTC)
CABFBRs_1_8_0_Date = time.Date(2021, time.August, 25, 0, 0, 0, 0, time.UTC)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I wonder why it was set to the 21st to begin with.


func (l *SubjectContainsOrganizationalUnitName) Execute(cert *x509.Certificate) *lint.LintResult {

if !cert.NotBefore.Before(time.Date(2022, time.September, 1, 0, 0, 0, 0, time.UTC)) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm half tempted to make some BeforeOrOn and OnOrAfter util functions to help make statements like these read more like their source citations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's a great idea.


if !util.TypeInName(&cert.Subject, util.OrganizationNameOID) {
return &lint.LintResult{Status: lint.Error, Details: "subject:organizationalUnitName is prohibited if subject:organizationName is absent"}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question (and I'm not sure I feel too strongly, but I have opinions, and trying to solicit others): Should this be two lints?

One testing that the organization name is present (with the effective date of 1.7.1), and the other testing that the organizationalUnit is absent (with the effective date of 1.7.1, but with a CheckApplies that uses the sunset date on the notBefore)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had exactly the same discussion here internally. We started implementing two distinct lints as you propose (they were actually three, one to cover also the deprecation case) since this felt better suited for the project, but the source code was quite similar so we merged them. I am not sure if code duplication is an issue here. In addition, this lint addresses this one sentence from the BR Document: "Prohibited if the subject:organizationName is absent or the certificate is issued on or after September 1, 2022.", so it feels OK to have one lint for that.
We are good with both options, but after this feedback we have a minor preference for two lints. Which option should we follow?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think the difference in effective dates justifies splitting those out, but happy if @cardonator or @christopher-henderson have different views.

Copy link
Member

@christopher-henderson christopher-henderson Oct 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I think about it more, I also believe that two separate lints would be appropriate here (and I'll make a mental note to myself that an or in a requirement might be a hint in the future).

With regard to code duplication, the project tends to prefer that lints remain proper leaf nodes in the graph of computation and avoid interdependency. So many lints are so similar, that one can easily imagine trying to unify them in some clever way. But this is liable to degenerate into a God-lint of sorts which becomes quite impossible for any contributors to effectively grok. So if avoiding that means sprinkling a bit of code duplication here-or-there then I think that's the lesser of two evils. We do have the catch-all utils package, but that tends to be for answering questions that are both quite common and quite easy to get wrong.

Copy link
Contributor

@sleevi sleevi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Some minor cleanups requested; we don't need to block on @christopher-henderson landing, although it's an easy rebase if he does :)

v3/integration/config.go Outdated Show resolved Hide resolved
@@ -48,18 +49,14 @@ func NewSubjectContainsOrganizationalUnitName() lint.LintInterface {
}

func (l *SubjectContainsOrganizationalUnitName) CheckApplies(cert *x509.Certificate) bool {
return util.TypeInName(&cert.Subject, util.OrganizationalUnitNameOID)
return !cert.NotBefore.Before(time.Date(2022, time.September, 1, 0, 0, 0, 0, time.UTC))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps @christopher-henderson is good with landing #644 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A minor change to align with #644 has been made

Comment on lines +60 to +62
if result.Details != tc.ExpectedDetails {
t.Errorf("expected result details %q was %q", tc.ExpectedDetails, result.Details)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe you delete this (and line 29) - you never fill in an expected details here?

I realize it's largely a copy/paste from other templates, but since this is is self-contained, you should be fine here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the second test case (subjectDnWithOuEntryButWithoutOEntry.pem) the expected details are filled.

@mtgag
Copy link
Contributor Author

mtgag commented Jan 14, 2022

Is this pull request still considered for inclusion? Is there somethig to do on our side?

Please note this change: #643 (comment)

which is interesting for the main project and is independent of this new lint. I could make a new pull request that adresses only this issue.

@@ -0,0 +1,64 @@
package cabf_br

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mtgag I believe that #675 captures this requirement effectively, so perhaps we can simply delete this file and reduce this change to SubjectContainsOrganizationalUnitNameButNoOrganizationName.

@sleevi you were the primary blocker on this PR, were your concerns addressed (looking to move forward on this one and #675)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Should we update/delete/refactor anything for this PR?

Please note that in https://github.com/zmap/zlint/blob/master/v3/util/time.go still the date for 1.8.0 needs to be adjusted. It is set to 21st of August but it should be the 25th. See https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf, page 14.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I think that leaving the date update in this PR is positive since it was a good bugfix to find that the other PR does not capture.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thank you for your patience @mtgag I went ahead and merged #675 so I believe that this particular lint can be removed and we can move forward with the other changes in this PR.

@mtgag
Copy link
Contributor Author

mtgag commented Jun 13, 2022

Comments have been addressed. The duplicate lint to #675 is removed along with the corresponding test data. Only e_subject_contains_organizational_unit_name_and_no_organization_name is still present.

@christopher-henderson christopher-henderson merged commit c7955ed into zmap:master Jun 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants