-
Notifications
You must be signed in to change notification settings - Fork 109
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
Conversation
This reverts commit 6c23670.
util: gtld_map autopull updates for 2021-10-21T07:25:20 UTC
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) |
There was a problem hiding this comment.
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)) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
v3/lints/cabf_br/lint_subject_contains_organizational_unit_name.go
Outdated
Show resolved
Hide resolved
|
||
if !util.TypeInName(&cert.Subject, util.OrganizationNameOID) { | ||
return &lint.LintResult{Status: lint.Error, Details: "subject:organizationalUnitName is prohibited if subject:organizationName is absent"} | ||
} |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…e.go Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com>
There was a problem hiding this 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 :)
@@ -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)) |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
if result.Details != tc.ExpectedDetails { | ||
t.Errorf("expected result details %q was %q", tc.ExpectedDetails, result.Details) | ||
} |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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.