Non implemented or not completely implemented resolutions

LC-2067 Awaits conformance statement ACTION-846

LC-2050 Need to take back to Eduardo

LC-2023 Inserted note in section 4.2.6.1 rather than altering the list

LC-2084 Need example from francois

LC-2047 Need a diagram for what is in scope - could make one out of the 
diagram that used to be in the requirements section

LC-2053 - Classes of devices need clarification

LC-2040 - X-Device-* should be in an Internet Draft

Pending ACTION-879 - Ask [someone] about adding IETF headers [on
François Daoust - due 2008-11-11].

---

LC-2044

RESOLUTION: Ref LC-2044 Resolve yes, and change the text to say
"*values* of User Agent and Accecpt headers", and clarify that we do not
propose guidance for new user agents' use of these headers, it is out of
scope

*** I didn't add the clarification, it seems out of place ***

And anyway

RESOLUTION: re LC-2044, resolution on LC-2069 removes the part that
required clarification, resolve partial, we won't talk about "use of
evidence"

--- The BIG one ---

LC-2026, LC-2027, LC-2085, LC-2028, LC-2029, LC-2030, LC-2015, LC-2031,
LC-2016, LC-2032, LC-2001, LC-2033, LC-2004, LC-2024

Pending
      Francois's ACTION-859 - Contact IETF TLS group and advise
      them of what we are thinking and ask for guidance on what to
      recommend to Content Provider about detecting the presence of a
      man-in-the-middle proxy

Pending
      Discussion with Thomas Roessler about his concerns ref applications
and possible security risks relating to the client thinking that all
hosts are the same (i.e. that they are the proxy).

Discussion: http://www.w3.org/2008/10/07-bpwg-minutes.html#item02

The amended text so far:

4.2.7.2 HTTPS Link Re-writing
Note:

The BPWG does not condone link rewriting, but notes that in some
circumstances HTTPS is used in situations where the user is prepared to
trade usability provided by a transforming proxy for the loss of
end-to-end security. Servers can prevent users from exercising this
choice by applying a Cache-Control: no-transform directive.

If a proxy rewrites HTTPS links, it must advise the user of the security
implications of doing so and must provide the option by-pass it and to
communicate with the server directly.

Notwithstanding anything else in this document, proxies must not rewrite
HTTPS links in the presence of a Cache-Control: no-transform directive.

If a proxy re-writes HTTPS links, replacement links must have the scheme
https.

When forwarding requests originating from HTTPS links proxies must
include a Via header as discussed under 4.1.6.1 Proxy Treatment of Via
Header.

When forwarding responses from servers proxies must notify the user of
invalid server certificates.

Add some stuff below under guidance for servers

Note:

For clarity it is emphasized that it is not possible for a transforming
proxy to transform content accessed via an HTTPS link without breaking
end-to-end security.

Received on Tuesday, 11 November 2008 19:00:52 UTC