Email Name Constraints
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 160
- Forks
- 102
- Avg merge
- 28m
- Merged PRs (30d)
- 5
Description
Hello I saw that currently name constraints aren't implemented to handle email sans. Was wondering if there'd be any problems if I were to make a PR for this? It seems the main work is just to specify what a valid email is and whether it follows said naming constraints.
For defining a valid email, implementing parsing for "Mailbox": https://datatracker.ietf.org/doc/html/rfc2821#section-4.1.2
Then the name constraints portion referring to emails: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10
It seems like there's at least one other library implementing email parsing: https://docs.rs/email_address/latest/email_address/index.html, but it seems to encapsulate more than what the x509 RFC specifies, so I imagine it'd be better to just write it from scratch here. Also wasn't sure if there were any rules about introducing dependencies.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with RFC 2821 section 4.1.2 for Mailbox parsing and RFC 5280 section 4.2.1.10 for email name constraints, then compare the existing name-constraints handling in webpki. Review the email_address crate as a reference while deciding whether a dependency is appropriate. Done means email SAN constraints are implemented according to the X.509 specification and validated by relevant tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cryptography, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100