2006/6/7, James M Snell <[EMAIL PROTECTED]>:
Implementations SHOULD use client authentication mechanisms to […]
Servers utilizing authentication MUST reject unauthorized or […]
Servers utilizing authentication mechanisms that involve the
clear-text
transmission of a password (e.g. HTTP Basic Authentication) MUST
secure
the connection using, for example, a Transport Layer Security (TLS)
connection.
-1
And more generally, -1 to any constraint. A "Security Considerations"
section should IMO only describe potential issues wrt security and
let
implementors do their choice, eventually influenced by some pointers
to other specs.
I already said I'm not able to secure connections using TLS, as are
many people using low-cost shared hosting solutions for their blogs
(and believe me there are a lot, at least in France, where you have a
100Mo storage space with MySQL and PHP for free with your ISP
account,
which can also be free if you don't want/can't have a DSL
connection),
and I don't want to use anything other than HTTP-Basic at first
glance
(because I can have it in a ".htaccess" instead of my Python
scripts).
However, I'm +1 to a note intended to server implementors recalling
them (if they don't already know it) that HTTP-Basic is a
"password in
the clear" authentication mechanism, and they might want better
protection using HTTP-Basic over TLS, or another more secure
mechanism
sending hashed passwords.
14.4 XML External Entities and Links within Atom document
Atom Feed and Entry documents MAY utilize XML External Entities as
defined in section 4.2.2 of [REC-XML]. However, because the Atom
Syndication Format does not require DTD validation, Atom
implementations
are not required to support external entities. Implementations that
choose to support external entities within Atom documents need to be
aware of the risks inherent in doing so. Specifically, external
entities are subject to all of the same security concerns as HTTP
GET
operations and run the risk of signficantly altering the
semantics of
the Atom document.
Likewise, servers should consider resources linked to by
atom:link and
atom:content elements as being inherently untrustworthy and
subject to
all of the same security risks as HTTP GET operations.
+1
14.5 Digital Signatures and Encryption
When a client sends an XML Encrypted Atom entry document to a server
using either a POST or PUT HTTP request, and the Content-Type
header of
the HTTP request message specifies the "application/atom+xml"
media-type, the server SHOULD treat the request the same as it would
treat a non-encrypted Atom entry document, assuming that it is
capable
of decrypting the entry. If, however, the Content-Type header of
the
request specifies any other media-type (e.g. "application/xml"), the
server SHOULD treat the request as it would any other form of
media post
(e.g. by creating a media-link entry that references the XML
Encrypted
resource).
-0.5
I'm not sure how this (different behavior depending on the
Content-Type of the POST) is related to XML encryption, and I'm not
sure how I'd like to see it spec'd (when sending an Atom Entry
Document with a "generic" text/xml or application/xml, I'd have
rather
expected the server to detect that it's an Atom Entry Document and
process it as if the Content-Type would have been
application/atom+xml; however, I'm not bothered at all with the
behavior you describe; nevertheless, this consideration should go in
another section of the spec, it has nothing to do with security
considerations).
A server receiving an atom:entry that contains an XML Digital
Signature
is not required to preserve the integrity of that signature.
That is,
the server may modify the entry in such a way that the original
signature included with the POST is broken or it may choose to
remove
the signature from the entry. The server MAY choose to add its
own XML
Digital Signature to the entry.
+1
14.6. Unsafe Media Posts
Server implementations that allow clients to post non-Atom
resources to
a collection to create media-link entries need to be aware of the
potential threat of allowing clients to send arbitrary and
inherently
unsafe media-types. For example, a collection allowing any
arbitrary
media-type to be posted could be used by an attacker to distribute a
virus to subscribers of that collection's Atom feed. To reduce the
likelihood of such attacks, implementions should enforce limits
on the
types of media resources that may be posted to a collection.
+1
--
Thomas Broyer
