- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 20 Feb 2016 13:40:50 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP WG <ietf-http-wg@w3.org>
> On 20 Feb 2016, at 1:37 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > > On 19 February 2016 at 18:16, Mark Nottingham <mnot@mnot.net> wrote: >> The remaining question (3 in the issue) is whether we should firm up the definition of "reasonable assurances" to require another way of achieving that to be documented in an RFC that updates this one. >> >> Mike B has already supported this approach; what do others think? > > I think that it's a fine approach. > > Are we simply going to reference RFC 2818 in defining "reasonable > assurances"? Maybe with a "Assurances that are considered reasonable > might include the certificate checks defined in RFC 2818, though > additional or alternative checks might be used by clients." I think so, although with language stronger than "might include"; e.g., "For the purposes of this document, "reasonable assurances" can be established through use of a TLS-based protocol with the certificate checks defined in RFC2818. Other means of establishing them MUST be documented in an RFC that updates this specification. Clients MAY impose additional criteria for establishing reasonable assurances." -- Mark Nottingham https://www.mnot.net/
Received on Saturday, 20 February 2016 02:41:19 UTC