On Wed, Dec 22, 2021 at 03:52:22PM -0500, Ben Schwartz wrote:
[ Sorry about the delayed response, on the road since Dec 24th... ]
> I don't want this draft to become an omnibus update to RFC 7671. My goal
> is to produce a short draft that is basically parallel to RFC 7673.
>
> If you want to
On Mon, Dec 13, 2021 at 10:04:55AM -0500, Ben Schwartz wrote:
> >
> > 1. While DANE certificate validation as described in RFCs 7671,7672 and
> > 7673
> > is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some other
> > applications)
> > skipping validation of the target name with
On Sun, Dec 12, 2021 at 09:49:57AM +0100, Philip Homburg wrote:
> >> There is something I don't understand about this draft.
> >
> >The main thing to understand is that complex applications like browsers
> >allow data retrieved from one endpoint to script interaction with a
> >*different*
>> There is something I don't understand about this draft.
>
>The main thing to understand is that complex applications like browsers
>allow data retrieved from one endpoint to script interaction with a
>*different* endpoint, and possibly see the retrieved content, subject to
>various CORS
On Sat, Dec 11, 2021 at 12:24:13PM +0100, Philip Homburg wrote:
> > https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00
> >
> > Thus, unless "UKS" is known to not be a concern, applications
> > should also validate the target name against the server
> > certificate
> 1. While DANE certificate validation as described in RFCs 7671,7672
> and 7673
> is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some
> other applications) skipping validation of the target name with
> DANE-EE(3) records introduces a "UKS" (i.e. "Unknown Key Share")
>
> On 9 Dec 2021, at 5:32 pm, Ben Schwartz wrote:
>
> This is a very small draft explaining how to do DANE with SVCB, mostly
> following the pattern of DANE-SRV. It also updates DANE for use with QUIC.
>
> Please review.
Initial observations:
1. While DANE certificate validation as
