Email Name Constraints

[jonahromero]

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.

[djc]

What do you need this for?

We're definitely going to be reluctant to introduce new dependencies, especially for niche features.

[jonahromero]

I have a use case for verifying certs with email sans. Not wanting a dependency makes sense, like I mentioned no issue with that, just wanted to double check.

[djc]

I have a use case for verifying certs with email sans.

I inferred as much, and was asking for more context, so we can judge how niche your use case is and if/how it relates specifically to the web PKI.

[briansmith]

mozilla::pkix has (at least it did 10 years ago) a minimal email name constraint implementation with a minimal parser that is web-compatible. The reason its parser is so simple is that it only accepts email addresses (and email address constraints) that contain reasonable email addresses, instead of all the unreasonable possibilities that may technically be valid that a more general email address parser might be tempted to try to support. It also handles the various ways that email addresses can appear in certificates.