- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 31 Oct 2013 15:48:56 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: Stephen Kent <kent@bbn.com>, secdir <secdir@ietf.org>, Barry Leiba <barryleiba@computer.org>, Pete Resnick <presnick@qti.qualcomm.com>, "Mankin, Allison" <amankin@verisign.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2013-10-31 15:44, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> On 2013-10-29 20:35, Stephen Kent wrote: >>> ... >>> Later on page 6 the text says: >>> >>> The HTTP protocol does not restrict applications to this simple >>> challenge-response framework for access authentication.Additional >>> mechanisms MAY be used, such as encryption at the transport level or >>> via message encapsulation, and with additional header fields >>> specifying authentication information.However, such additional >>> mechanisms are not defined by this specification. >>> >>> Encryption is not, per se, an authentication mechanism. Please revise >>> this text. >>> ... >> >> OK. Maybe: >> >> "HTTP does not restrict applications to this simple challenge-response >> framework. Additional mechanisms can be used, such as additional header >> fields carrying authentication information, or encryption on the >> transport layer in order to provide confidentiality. However, such >> additional mechanisms are not defined by this specification." >> >> ? > > I think doing s/encryption/authentication/ instead would be better. > There is no reason to discuss confidentiality here. Encryption and other > cryptographic techniques are used in many authentication schemes, like > with client certificates; that may have been the idea behind the text. "authentication on the transport layer"? That wouldn't cover Basic auth (plain text passwords) over https:, which I think this paragraph is hinting at... Best regards, Julian -- <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782
Received on Thursday, 31 October 2013 14:49:25 UTC