- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Mon, 12 Oct 1998 14:29:55 -0700
- To: WEBDAV WG <w3c-dist-auth@w3.org>
> > 3. [nit] Is the reference for Dublin Core [Weibel et. al.], equivalent > > to RFC 2413? If so, we'd prefer that to just a URL. > > Note that RFC 2413 includes a URL to DC's site; would that be enough? Referencing RFC 2413 will be fine for our purposes. Since it was published in September, 1998, and the -08 draft was submitted in April, we didn't have an opportunity to cite the RFC intitially. It's a non-normative reference, anyway, and the RFC is informational. This shouldn't have any impact on the DAV properties binding draft you're working on, John. > > 11. on the use of URLs as XML namespaces: there's a scalability and > > reliability issue if any particular URIs used as namespace names are > > distributed in products that are widely used, and they may not work if > > used on private nets not connected to the Internet. > > We don't write anything that would suggest a client might dereference a > namespace URL, do we? I believe this is based on the XML Namespaces that is currently copied by-value in the DAV spec., which has the "src" attribute. This attribute had been intended for use in retrieving a machine-readable description of the namespace schema, and hence Keith's comment addresses this. The problem was if you have a million copies of some application released which all go to this URL everytime they process XML. The new namespace proposal doesn't have an equivalent capability, and so this comment goes away, I believe. > > > 17. section 16.1: > > > > TLS doesn't inherently provide a secure connection, as TLS allows use > > of insecure ciphersuites. TLS is "secure" only if strong ciphersuites > > are used (40 bit ciphersuites are certainly not secure enough for > > passwords that might be reused in other contexts), and I believe you > > need to have mutual authentication to thwart man-in-the-middle > > attacks. (I might be wrong about the latter - server-to-client > > authentication might be sufficient to prevent man-in-the-middle > > attacks) > > I'm pretty sure server-to-client is meant to be sufficient. Existing SSL > clients (well, Navigator, anyway :-) have to deal with this problem when > running through a proxy. Navigator connects to the proxy and > issues a CONNECT > request, which tells the proxy to open up a connection to the > server and relay > bits untouched. If man-in-the-middle were a problem, the proxy > would need to > be trusted, in which case we wouldn't need a CONNECT; we could > proxy https: > just like http:. I think the problem is exactly as Keith stated. It is possible to have a TLS connection with weak ciphers in use, and hence this security isn't very strong, since someone could theoretically capture each packet, decrypt it, and put together the message stream. - Jim
Received on Monday, 12 October 1998 18:08:38 UTC