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

lint_single_email_if_present.go Checks SANs instead of Subject #795

Open
jdkasten opened this issue Feb 12, 2024 · 2 comments
Open

lint_single_email_if_present.go Checks SANs instead of Subject #795

jdkasten opened this issue Feb 12, 2024 · 2 comments

Comments

@jdkasten
Copy link
Contributor

I believe the lint
Name: "e_single_email_if_present",
Description: "If present, the subject:emailAddress SHALL contain a single Mailbox Address",
Citation: "7.1.4.2.h"

refers to this requirement which is specifically about the subject's relative distingished names rather than subject alternative names.

The lint's code iterates over c.EmailAddresses, which is the the subject alternative name email addresses and not those potentially contained in the subject [documentation]. There should only be one email address in the subject's distinguished name.

I also believe that the citation should be changed to 7.1.4.2.2.h rather than its current 7.1.4.2.h.

@cardonator
Copy link
Contributor

You're right about the reference, it should be 7.1.4.2.2.h.

You're also right that the target of the current check is the SANs and not the subject as specified in the BR. I can work on a patch for that.

Please note that the referenced requirement does not state that only one Subject EmailAddress field is allowed in a compliant certificate, but that each Subject EmailAddress field contains only a single email address. Currently this lint is technically wrong per reference but not practically wrong in implementation: each Subject EmailAddress must appear as a SAN in the certificate, and therefore each SAN EmailAddress should also only contain a single email address.

mtgag added a commit to mtgag/zlint that referenced this issue Feb 29, 2024
mtgag added a commit to mtgag/zlint that referenced this issue Mar 1, 2024
christopher-henderson added a commit that referenced this issue Mar 17, 2024
* lint about the encoding of qcstatements for PSD2

* Revert "lint about the encoding of qcstatements for PSD2"

This reverts commit 6c23670.

* util: gtld_map autopull updates for 2021-10-21T07:25:20 UTC

* always check and perform the operation in the execution

* synchronised with project

* synchronised with project

* synchronised with project

* synchronised with project

* added same lint for subject values instead of SAN values

* resolved conflict issue

* addressed review comments and hint to citation from #795

---------

Co-authored-by: mtg <[email protected]>
Co-authored-by: GitHub <[email protected]>
Co-authored-by: Christopher Henderson <[email protected]>
Co-authored-by: Zakir Durumeric <[email protected]>
christopher-henderson added a commit that referenced this issue Mar 17, 2024
* lint about the encoding of qcstatements for PSD2

* Revert "lint about the encoding of qcstatements for PSD2"

This reverts commit 6c23670.

* util: gtld_map autopull updates for 2021-10-21T07:25:20 UTC

* always check and perform the operation in the execution

* synchronised with project

* synchronised with project

* synchronised with project

* synchronised with project

* added same lint for subject values instead of SAN values

* resolved conflict issue

* addressed review comments and hint to citation from #795

* addressing issue #795 and review comments of PR #802

---------

Co-authored-by: mtg <[email protected]>
Co-authored-by: GitHub <[email protected]>
Co-authored-by: Christopher Henderson <[email protected]>
@mtgag
Copy link
Contributor

mtgag commented Apr 2, 2024

@jdkasten and @cardonator is the discussion in this issue covered by PR #808? If yes, this issue could be closed.

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

No branches or pull requests

3 participants