I agree with the reasoning, but I think you have to deprecate before removal
and therefore not in this draft.
We could update the security concerns and say MAY NOT about issuance perhaps.
The text already says clients MAY use them.
They're still allowed in the WebPKI, and I am unsure of non-web
On Thu, Jul 08, 2021 at 06:52:15PM -0400, Ryan Sleevi wrote:
> > Can "the industry" (CAs, software vendors, ...) unite behind getting the
> > users to accept the right, but arguably less convenient, tradeoff?
>
> No. I think deprecating wildcards would be a bad outcome for users and for
> server
Jim Fenton wrote:
>
> I would expect subjectAltName to have the same constraints as DNS
> entries have, which only allow wildcards for full labels, so I support
> only allowing *.apps.example.com.
Well, it's more complicated than that, because it isn't feasible to get
certificate wildcards to hav
On Fri, Jul 9, 2021 at 3:03 PM Tony Finch wrote:
> My understanding is that PKIX wildcard matching originally used glob(3),
> (with . as the separator instead of /) which is both more relaxed and more
> restricted than DNS wildcards.
>
I'm not aware of any implementations with that semantics. At
Ryan Sleevi wrote:
> On Fri, Jul 9, 2021 at 3:03 PM Tony Finch wrote:
>
> > My understanding is that PKIX wildcard matching originally used glob(3),
> > (with . as the separator instead of /) which is both more relaxed and more
> > restricted than DNS wildcards.
>
> I'm not aware of any implement
