Our impl also requires Basic+TLS/SSL. I'm fine with adding a constraint that impl's SHOULD support this at a minimum, but nothing more than that.
- James John Panzer wrote: > > I'd be -1 to this, as AOL's servers will simply not operate with clients > that don't support at least HTTP Basic and TLS. Blogger's doing the > same thing (I think). And I'm pretty sure that any server provider who > is concerned about security and interoperability will come to the same > conclusion. Except for Bob, of course, but Bob is artificially > constrained. > > I don't want to try to speak to clients on this subject, other than to > say what our servers will support. I do think that we have an > asymmmetrical situation and if there are SHOULDs and MUSTs, they need to > be spelled out separately for clients and servers. > > -John > > James M Snell wrote: > >> Alternative approach to PaceBasicAuthentication and PaceAuthentication. >> >> http://www.intertwingly.net/wiki/pie/PaceFixSecurityConsiderations >> >> #pragma section-numbers off >> >> == Abstract == >> >> Remove section 13. Replace section 14 with a more generic statement >> about APP being subject to the same security considerations as RFC2616 >> with a constraint that if Basic Auth is used, TLS SHOULD also be used. >> >> == Status == >> >> Proposed >> >> == Rationale == >> >> APP is an HTTP spec. HTTP already has defined authentication >> mechanisms. There is no need for APP to specify specific authentication >> mechanisms. CGI authentication is valuable, but best done as a separate >> spec deriving from RFC2617. >> >> == Proposal == >> >> Remove section 13. Replace section 14. >> >> {{{ >> 14. Security Considerations >> >> Implementations of the Atom Publishing Protocol SHOULD be protected using >> HTTP Authentication mechanisms as defined by or derived from >> [RFC2617]. If >> implementations choose to implement support for HTTP Basic >> Authentication, >> they SHOULD support encryption of the session using TLS [RFC2246]. The >> security of the Atom Publishing Protocol is subject to the same security >> considerations as discussed in [RFC2616] and are entirely dependent on >> the >> strengths and weaknesses of the implementation and chosen authentication >> and >> transport security mechanisms. >> }}} >> >> == Impacts == >> >> >> >> == Notes == >> >> >> ---- >> >> CategoryProposals >> >> >> > >
