Tighten up string type representations to prevent illegal values

[cpu]

In several places Rcgen defines representations of ASN.1 string types, but in a way that doesn't enforce the values meet the restrictions imposed by the type in use.

For example, consider the DnValue enum with TeletexString, PrintableString, UniversalString, Utf8String and BmpString variants. Those variants express their values as either String or Vec<u8>, but in many cases the ASN.1 definitions for these string types introduce further restrictions. As one example, a PrintableString can only contain A-Z, a-z, 0-9, '()+,-./:=? and <SPACE> where as a Rust String can contain any valid UTF-8.

Because of this mismatch invalid values can be expressed in CertificateParams, and won't be caught by any validation. In the cases where we use a yasna writer and write_bytes generically, we'll emit an invalid encoding for the type in use. In the cases where we use a more specific yasna helper like write_ia5_string or write_printable_string, invalid values will cause a panic.

I think we should look at creating a different representation that can impose more validation in order to reject invalid values at construction time as opposed to emitting invalid encodings or panicing when serializing.

[Tudyx]

Does using newtype would make the job?

Something in the idea of the nutype crate but without using derive macro

[djc]

Yeah, we could probably do newtypes for each of the inner variants (that need additional constraints), and have TryFrom impls for them?

[cpu]

That sounds like the right approach to me 👍

[Tudyx]

The created types will look like a lot to the one from the der::asn1 module of the der crate. See for instance the PrintableString struct.
Should we consider adding the der crate as a dependency or it's not worth it?

[est31]

I don't think we should depend on the der crate for that alone. It has a huge list of dependencies of its own.

[Tudyx]

Actually, it has no dependency for our use case. All the dependencies listed in their Cargo.toml are optional, and we only need the alloc feature that doesn't activate any. I have also checked with cargo tree to be sure.

[cpu]

These types will end up in the public API of rcgen and so I think it would be preferential to not tie them to a third party crate.