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
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
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
t; against a reference identifier. (I think this is compatible with what Ryan
> Sleevi wrote in this thread.)
Right, I think we agree that 6125bis doesn't need to tackle that, but
it does sound like we disagree why.
It seems you're in favor of the "fail fail" scenario, wh
On Fri, Jul 23, 2021 at 3:37 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 23/07/2021 19:32, Peter Saint-Andre wrote:
> > The authors of rfc7525bis have noticed that the Commercial National
> > Security Algorithm Suite (CNSA) contains some strong recommendations
> > regarding topics of interest, inc
Hey Rich,
I left a comment on GitHub with respect to the question about
"confusables". I'm not sold that the suggestion I made is the best, but I'm
mostly trying to see about aligning terminology to the modern reference and
save a few indirection clicks (from IDNA-DEFS to UTS36 to UTS39).
I'm a l
On Fri, Oct 1, 2021 at 10:07 AM Salz, Rich wrote:
> I still would like comments on the last paragraph of the section:
>
>
>
>- To accommodate the workaround that was needed before the development
>of the SNI extension, this specification allows multiple DNS-IDs, SRV-IDs,
>or URI-IDs i
On Mon, Oct 4, 2021 at 9:29 AM Salz, Rich wrote:
>
>- What sort of ripple effects are you thinking?
>
>
>
> Purely editorial within the document which talks about one or more
> DNS-ID/URI-ID in a couple of places.
>
>
>
>- I agree that, in practice, the use of multiple names has been
>
Hi Rich,
I reviewed these changes, and agree, they look good. Thanks for doing them.
I left a few comments/suggestions on the GitHub PR for possible clarity,
but these are not blocking and entirely optional.
On Wed, Oct 20, 2021 at 11:21 AM Salz, Rich wrote:
> I have a number of editorial chang
the server is
> used are not used for any other protocol without ALPN support" or similar
> conditions.
See the past list discussion that raised concerns about that proposed
change, which this language was trying to address.
>
> On Wed, Nov 17, 2021, at 07:14, Salz, Rich wrote:
&g
On Sat, Nov 20, 2021 at 6:58 AM John Mattsson wrote:
> - In some applications using mutually authenticated TLS, e.g., between
> nodes in 5G core networks or in mesh networks there is basically no
> difference between the client and the server. It would be very good if the
> document states that f
On Sun, Nov 21, 2021 at 2:53 AM John Mattsson
wrote:
> John: I agree with Section 6.1.1 that the client need a limited set of
> reference
> identifiers. Reading 6.1. again, i think that the term "set" that you use
> might be better than list. Is the intention to forbid sets of reference
> identi
On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor
wrote:
> This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
> client deliberately fail a connection when the problem might be a flaw
> with an unrelated network service or a client-specific routing failure?
>
> I think we can
On Fri, Jan 21, 2022 at 9:52 AM Daniel Kahn Gillmor
wrote:
> I share your skepticism, but i'm still trying to salvage something
> useful -- for the purpose of defending against CA malfeasance -- from
> the mechanisms we have available.
>
Indeed, I think the goal is admirable, but I'm not sure th
On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni
wrote:
> > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > we urge the CAs to be more strict here? Perhaps that would be another
> > recommendation.
>
> CAA lookups must not softfail. This needs to be the case whether t
On Mon, Jan 24, 2022 at 11:18 AM Daniel Kahn Gillmor
wrote:
> So, arguably, the advantage of revocation checking via OCSP stapling
> over short-lived certificates today has to do with keeping CT logs a
> manageable size, not with any particular security gain in terms of
> revocation functionality
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
>
> Browsers are the only software that use browser's implementation of
> certificate
> verification and revocation.
>
> And while they are significant users of TLS, they're definitely not the
> only important users of TLS.
In the context of
17 matches
Mail list logo
