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

Handle BMPString properly in e_subject_dn_not_printable_characters #819

Closed
wants to merge 2 commits into from

Conversation

cardonator
Copy link
Contributor

Looking at #818 , other string types should be allowable as printable in subject fields to conform to RFC 5280.

@cardonator
Copy link
Contributor Author

I need to get/create certs with matching field data types to add additional tests for this update. However, this does pass the cert referenced in #818 as well as the test certs we created for the original lint a few years ago.

@cardonator
Copy link
Contributor Author

I noticed in the Integration Test run that the number of certs in the test corpus that fail this lint has dropped from 541 to 34. That seems concerning to me but I'm not sure if it's something to be concerned about. One noteworthy comment here is that it increases the efficacy of this lint for RFC-compliant use cases, but decreases the efficacy for public PKI.

I'll look for feedback from others before deciding how to proceed.

@zakird
Copy link
Member

zakird commented Mar 28, 2024

Part of me wonders if we should make it a "community best practice" webpki lint? It doesn't seem to have tripped up any CAs in the last five years? I don't have a strong opinion, but it's an option.

@CBonnell
Copy link
Contributor

SC-62 (the "profiles" ballot) added restrictions on the allowed encodings for DirectoryString attribute value types: https://cabforum.org/working-groups/server/baseline-requirements/requirements/#7142-subject-attribute-encoding.

Specifically, the deprecated BMPString, UniversalString, and TeletexString types are no longer allowed. It's likely more expedient to add this prohibition in a separate lint and forego trying to get the lints for these legacy types correct. Lints for BMPString and UniversalString might be not be too bad to implement, but there will be pain with TeletexString.

@zakird
Copy link
Member

zakird commented Mar 29, 2024

@CBonnell's suggestion makes sense to me.

@cardonator
Copy link
Contributor Author

Does that mean we should add the restrictions and linting from the lint in question to the BR lints and remove it from the RFC lints?

@zakird
Copy link
Member

zakird commented Mar 29, 2024

Yes, I think that moving them to a lint that points to the BRs is probably the right move (if one doesn't already exist.)

@mtgag
Copy link
Contributor

mtgag commented Apr 2, 2024

I could contribute on the BR lints about allowed encodings and also provide certificates with the disallowed encodings. If that is fine and you are not already on it, I could start working on it.

@mtgag
Copy link
Contributor

mtgag commented Apr 5, 2024

I could contribute on the BR lints about allowed encodings and also provide certificates with the disallowed encodings. If that is fine and you are not already on it, I could start working on it.

This is the corresponding PR: #824

@cardonator
Copy link
Contributor Author

With #824, I'm thinking we should close this PR, right @christopher-henderson ?

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