You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #42 we adopted some upstream work that included a new GeneralDnsNameRef enum that had a DnsName variant for a standard DnsNameRef (no wildcards, can be used for subject matching) and a Wildcard variant for a new WildcardDnsNameRef type (wildcards supported, only used in the context of a presented DNS name). The original idea that prompted development of this enum is that it would support changing the GeneralName::DnsName enum variant from holding untrusted::Input to holding GeneralDnsNameRef. This allows more specificity while still maintaining a strong separation between the appropriate uses of the two types of name refs (see briansmith/webpki#66).
We never fully implemented this idea after landing #42 and using it only in the context of iterating certificate SAN dNSNames for informational purposes. We considered exporting the types in #178 but arrived at a simpler solution whereby we iterate &str and don't need to expose the underlying types. As a result, we removed the GeneralDnsNameRef type entirely as it was unused.
This issue is a reminder that we should consider restoring the GeneralDnsNameRef type and using it for its intended purpose: as part of the GeneralName enum.
The text was updated successfully, but these errors were encountered:
In #42 we adopted some upstream work that included a new
GeneralDnsNameRef
enum that had aDnsName
variant for a standardDnsNameRef
(no wildcards, can be used for subject matching) and aWildcard
variant for a newWildcardDnsNameRef
type (wildcards supported, only used in the context of a presented DNS name). The original idea that prompted development of this enum is that it would support changing theGeneralName::DnsName
enum variant from holdinguntrusted::Input
to holdingGeneralDnsNameRef
. This allows more specificity while still maintaining a strong separation between the appropriate uses of the two types of name refs (see briansmith/webpki#66).We never fully implemented this idea after landing #42 and using it only in the context of iterating certificate SAN dNSNames for informational purposes. We considered exporting the types in #178 but arrived at a simpler solution whereby we iterate
&str
and don't need to expose the underlying types. As a result, we removed theGeneralDnsNameRef
type entirely as it was unused.This issue is a reminder that we should consider restoring the
GeneralDnsNameRef
type and using it for its intended purpose: as part of theGeneralName
enum.The text was updated successfully, but these errors were encountered: