Re: [Uta] Wildcards

I think there is a growing consensus among network engineers that ICANN and a few at IETF (at least a few years ago) weren't 100% honest regarding how DNS wildcards work. I think we can all agree that the RFCs keep it vague enough that no one can say for sure how wildcards work. This was I think a

Re: [Uta] Wildcards

>> I don't think that makes the above text incorrect, since this draft >> says "only the first label" >Sort of. The text I quoted does not. You could say "can only match the > leftmost label in ...". Assuming we have consensus, the PR on this says that the wildcard character can

Re: [Uta] Wildcards

On Mon, Jul 12, 2021, at 23:59, Salz, Rich wrote: > > +A wildcard in a presented identifier can only match exactly one label > > in > > +a reference identifier. Note that this is not the same as DNS wildcard > > +matching, where the `*` label always matches at least one whole >

Re: [Uta] Wildcards

I think the 6125 was explicit about what it covered, and I hope the new version will be more explicit: how to validate server “names” when using PKIX certs and TLS. Everything else is out of scope. As Viktor said, it’s often local policy. What RFC describes Chrome’s behavior? And why should t

Re: [Uta] Wildcards

> On 12 Jul 2021, at 5:48 pm, Jim Fenton wrote: > > Part of my problem is that I don’t know what the boundaries of RFC 6125 are. > If there’s further validation that happens elsewhere that this depends upon, > it should be specific about what other RFCs define that validation. Not everything i

Re: [Uta] Wildcards

On 12 Jul 2021, at 14:27, Salz, Rich wrote: * that further validation happens outside (before, after, or in parallel to) RFC 6125 processing. It seems like it would be worthwhile for us to mention that in the beginning. Part of my problem is that I don’t know what the boundaries of RFC 6

Re: [Uta] Wildcards

* that further validation happens outside (before, after, or in parallel to) RFC 6125 processing. It seems like it would be worthwhile for us to mention that in the beginning. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/u

Re: [Uta] Wildcards

On Mon, Jul 12, 2021 at 02:14:39PM -0700, Brian Smith wrote: > I think the important point is that RFC 6125 can specify the syntax of a > wildcard, and we can specify how to match a reference ID against it, > without having to dive into determining whether the CA should have issued > that wildcard

Re: [Uta] Wildcards

Ryan Sleevi wrote: > On Mon, Jul 12, 2021 at 4:20 PM Brian Smith wrote: > > If we get to the part of validation where RFC 6125 is relevant then we > already know the wildcard dNSName subjectAltName entry is valid. Given > that, RFC 6125 just needs to specify how to match, syntactically, a > wild

Re: [Uta] Wildcards

On Mon, Jul 12, 2021 at 4:20 PM Brian Smith wrote: > If we get to the part of validation where RFC 6125 is relevant then we > already know the wildcard dNSName subjectAltName entry is valid. Given that, > RFC 6125 just needs to specify how to match, syntactically, a wildcard > against a referen

Re: [Uta] Wildcards

Jim Fenton wrote: > Rich replied: > > > Clients must be free to ignore wildcards, because of things like *. > air-traffic-control.aero and others that are on the public suffix list. > > Does that then mean that there is an obligation on the part of certificate > checkers to make sure that public

Re: [Uta] Wildcards

On Mon, Jul 12, 2021 at 2:08 PM Jim Fenton wrote: > Does that then mean that there is an obligation on the part of certificate > checkers to make sure that public suffixes aren’t wildcarded? I had expected > that to be a responsibility of CAs to make sure that they don’t sign > something inappr

Re: [Uta] Wildcards

>Support for wildcards in RFC 6125 is application-protocol specific, see Appedix B. Well, I want to make 6125bis be a Standard, not a best practices, so Appendix B is gone from my draft :) But yes, I still want wildcards to be a MAY. Perhaps a SHOULD. ___

Re: [Uta] Wildcards

> On 12 Jul 2021, at 2:06 pm, Jim Fenton wrote: > >> A client employing this specification's rules MAY match the reference >> identifier against a presented identifier whose DNS domain name portion >> contains the wildcard character "*" > > I questioned the MAY in this sentence, because it see

Re: [Uta] Wildcards

On 8 Jul 2021, at 7:12, Salz, Rich wrote: > I’d like to know what the WG thinks. As we’re not really using GitHub for > discussion, please comment on this list. I made a comment on the pull request that is beyond editorial, so I’d like to bring that back to the list. Section 6.4.3 begins (ess

Re: [Uta] Wildcards

> +A wildcard in a presented identifier can only match exactly one label > in > +a reference identifier. Note that this is not the same as DNS wildcard > +matching, where the `*` label always matches at least one whole > +label and sometimes more. See {{DNS-CONCEPTS, Section 4.

Re: [Uta] Wildcards

On Sun, Jul 11, 2021, at 07:44, Salz, Rich wrote: > +A wildcard in a presented identifier can only match exactly one label > in > +a reference identifier. Note that this is not the same as DNS wildcard > +matching, where the `*` label always matches at least one whole > +label and sometimes more.

Re: [Uta] Wildcards

Salz, Rich wrote: > I am adding the following commit to > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 which I will > merge if/when we have consensus. > Let me know if this is not ok. lgtm, thanks! Tony. -- f.anthony.n.finchhttps://dotat.at/ Hebrides: Northeast 3 to 5. Mo

Re: [Uta] Wildcards

I am adding the following commit to https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 which I will merge if/when we have consensus. Let me know if this is not ok. MAC ~/git/draft-ietf-uta-rfc6125bis$ g l1 commit d4dcbd397e1342c634f3ab19eb4bc52b4b7ef5e8 (HEAD -> simpler-wildcard) Autho

Re: [Uta] Wildcards

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

Re: [Uta] Wildcards

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

Re: [Uta] Wildcards

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

Re: [Uta] Wildcards

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

Re: [Uta] Wildcards

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

Re: [Uta] Wildcards

It appears that Viktor Dukhovni said: >That said, it'be really super if various applications profiles decided >to do away with wildcard certificates entirely. Their $$$ cost >advantage is long gone, and otherwise they just damage security by >enabling cross application protocol attacks, ... Som

Re: [Uta] Wildcards

On Thu, Jul 8, 2021 at 5:47 PM Viktor Dukhovni 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 operators. Whi

Re: [Uta] Wildcards

On Thu, Jul 08, 2021 at 01:52:42PM -0600, Peter Saint-Andre wrote: > > So the sooner we can get rid of wildcard certificates entirely, the > > better. They've outlived their usefulness. > > Jeff Hodges and I had hoped to push for deprecating wildcard certs when > working on RFC 6125 10+ years ag

Re: [Uta] Wildcards

On 7/8/21 1:41 PM, Viktor Dukhovni wrote: > On Thu, Jul 08, 2021 at 02:12:51PM +, Salz, Rich wrote: > >> A discussion started on the GitHub repo >> https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is >> allowed for the wildcard character, such as in DNS entries in >> subjectAlt

Re: [Uta] Wildcards

On Thu, Jul 08, 2021 at 02:12:51PM +, Salz, Rich wrote: > A discussion started on the GitHub repo > https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is > allowed for the wildcard character, such as in DNS entries in > subjectAltName. I am about to publish a new draft which tak

Re: [Uta] Wildcards

In anticipation of consensus around "only * as the left-most label," I created a PR; https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

On 8 Jul 2021, at 7:12, Salz, Rich wrote: > A discussion started on the GitHub repo > https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is allowed > for the wildcard character, such as in DNS entries in subjectAltName. I am > about to publish a new draft which takes the old adop

Re: [Uta] Wildcards

On 7/8/21 9:02 AM, Alexey Melnikov wrote: > Hi Rich, > > On 08/07/2021 15:12, Salz, Rich wrote: >> >> A discussion started on the GitHub repo >> https://github.com/richsalz/draft-ietf-uta-rfc6125bis >> about what is >> allowed for the wildcar

Re: [Uta] Wildcards

Hi Rich, On 08/07/2021 15:12, Salz, Rich wrote: A discussion started on the GitHub repo https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is allowed for the wildcard character, such as in DNS entries in subjectAltName.