Redesign name validation API to allow extensibility in the types of names

[briansmith]

In particular, prepare for allowing IP addresses in an API-compatible way.

[codecov]

Codecov Report

Merging #218 (b36aaf0) into main (81bd1e3) will increase coverage by 3.16%.
The diff coverage is 72.72%.

@@            Coverage Diff             @@
##             main     #218      +/-   ##
==========================================
+ Coverage   51.91%   55.07%   +3.16%     
==========================================
  Files          17       18       +1     
  Lines        2034     2048      +14     
==========================================
+ Hits         1056     1128      +72     
+ Misses        978      920      -58     

Impacted Files	Coverage Δ
src/lib.rs	1.49% <0.00%> (ø)
src/end_entity.rs	42.46% <44.44%> (+10.07%)	⬆️
src/name/name.rs	100.00% <100.00%> (ø)
tests/integration.rs	100.00% <100.00%> (ø)
src/name/dns_name.rs	64.62% <0.00%> (+2.16%)	⬆️
src/name/verify.rs	30.81% <0.00%> (+26.74%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 81bd1e3...b36aaf0. Read the comment docs.

[djc]

Looks good to me!

[lucab]

As this enum is opaque, I think the public API is missing some way for external users to build this. Possibly a DnsNameRef::to_name()?

[djc]

Probably just impl<'a> From<DnsNameRef<'a> for Name<'a>?

[briansmith]

The enum isn't opaque, but I've added the From implementation anyway.

[briansmith]

So...here's the thing I don't like about this API: Almost definitely we're going to add IP address support to it to support a few niche users. Probably we'd eventually add other kinds of names (directoryName and emailAddress come to mind) that almost no applications will want to use--especially for TLS server names. If we have APIs with name: Into<webpki::Name> inputs, it's likely those APIs will accept these inappropriate names in contexts where they probably shouldn't. And I suppose things built on top of webpki would be tempted to have APIs with name: Into<webpki::Name> or equivalent too. Probably at least I need to update the docs for these APIs to indicate that one should be careful with that.

[djc]

Maybe you could set it up such that EndEntity only supports some kinds in the default configuration, and you have to explicitly enable other kinds when building the EndEntity?

[zh-jq]

Any progress?