- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 17 Jun 2021 11:44:58 +1000
- To: Benjamin Kaduk <kaduk@mit.edu>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-semantics@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
Hi Ben, > On 17 Jun 2021, at 6:39 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this quite masterfully done mammoth undertaking! I expect > to ballot Yes pending discussion of one point. > > I'm looking at the following text in Section 4.3.4 relating to how to > handle certificate validation failures for https: > > If the certificate is not valid for the URI's origin server, a user > agent MUST either notify the user (user agents MAY give the user an > option to continue with the connection in any case) or terminate the > connection with a bad certificate error. [...] > > Given the discussion up in §3.5 about requirements to "notify" the user > vs requiring "confirmation" from the user, I don't think that just "MUST > notify the user" is sufficient to prevent the user-agent from > continuing, since it is sufficient to just write a log entry as the > means to notify the user. Is the intent to require confirmation of the > action to continue in the face of such an error (which, again per §3.5 > could be a pre-configured confirmation)? An intent to require > "confirmation" (vs mere "notification") seems consistent with the > subsequent text placing requirements on automated clients and would be > more consistent with my understanding of general IETF consensus for > securing protocols Good catch. I think that 'notify the user' --> 'obtain confirmation from the user' is the right change here (possibly with a reference to 3.5). Anyone disagree? Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 17 June 2021 01:45:42 UTC