- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Thu, 31 Oct 2013 15:44:24 +0100
- To: Julian Reschke <julian.reschke@greenbytes.de>
- 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>
* 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. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Thursday, 31 October 2013 14:44:55 UTC