- From: Paul Hoffman <paulh@imc.org>
- Date: Thu, 29 Aug 1996 11:24:24 -0700
- To: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 3:41 PM -0700 8/27/96, Larry Masinter wrote: >Writing MUST instead of SHOULD in the specification is not any way to >force some vendor to either implement or not implement something. I strongly disagree. Noncompliance to a spec is a very big marketing force. >The >spec should say what makes sense, not what is politically >expedient. -It makes sense to stop sending passwords in the clear. -It makes sense to have *a single way* to stop sending passwords in the clear. -It makes sense to require that any browser that allows a user to send a password allow that user to send it securely. -It is not politically expedient to try to force the largest manufacturer do anything. This argument is a (dare I say it?) red herring. >We should write "MUST" if non-compliance causes systems to >break. The IESG has told us to consider security part of the system. Sending passwords in the clear breaks the security system. >I think there are too many "MUST"s in HTTP/1.1, but agreed to wait >until the review for "Proposed" -> "Draft" to review them. I don't see >any reason to add one here, though. I disagree, and it seems like the rough consensus so far is to use MUST. >As >has been pointed out in many cases, Basic authentication is as safe as >Digest if used in conjunction with some other one-time password system >(SKey, SecurID, etc.). Huh? It has been pointed out that Basic authentication does *not* work well with OTP because every transaction is re-authenticated. >I think we're deluding ourselves if we think we can require "MUST >implement" I strongly disagree. --Paul Hoffman --Internet Mail Consortium
Received on Thursday, 29 August 1996 11:26:28 UTC