W3C home > Mailing lists > Public > public-wsc-wg@w3.org > June 2008

Meeting record: 2008-05-07

From: Thomas Roessler <tlr@w3.org>
Date: Fri, 6 Jun 2008 17:09:40 +0200
To: public-wsc-wg@w3.org
Message-ID: <20080606150940.GA35731@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-05-07 were approved and are
available online here:


A text version is included below the .signature.

Thomas Roessler, W3C  <tlr@w3.org>


                                   - DRAFT -

               Web Security Context Working Group Teleconference
                                  07 May 2008

   See also: [2]IRC log


          MaryEllen_Zurko, Bill_Doyle, johnath, jvkrey, ifette, Thomas,
          yngve, joesteele, PHB, +1.708.524.aaaa, asaldhan

          Tim, H




     * [3]Topics
     * [4]Summary of Action Items

   <trackbot-ng> Date: 07 May 2008

   <Mez> [5]http://www.w3.org/2006/WSC/Group/cheatsheet#Scribing

   <johnath> ScribeNick: bill-d

   <Mez> [6]http://www.w3.org/2008/04/30-wsc-minutes.html

   Mez: approve last meeting minutes


   Mez: open action items
   ... no issues pending

   <scribe> ... closed items due to inactivity

   tlr: is this item going to resurface?
   ... does phil need to take a second look

   mez: agenda bashing, isue 133 what about that plug in stuff, 181 http -
   http3, 183 automatic self signed, 190 relaxing relaxed path


   mez: other issues are listed in f2f, if we have other issues should be
   brought up now

   <Mez> issue-133?

   <trackbot-ng> ISSUE-133 -- How do our definition of Web Page and the
   Robustiness section interact? -- OPEN

   <trackbot-ng> [9]http://www.w3.org/2006/WSC/track/issues/133

   mez: pick up on issue 133 plug in issues
   ... email from Joesteele on issue 133


   joesteele: definition of web page in regards to plug ins was to tight,
   should be more general, second item answers question about robustness
   and plugins interact
   ... existing security plugins, do they need to conform

   mez: 133 may need more discussion and taken to f2f. original approach
   was lowbar. at least should say plugins could undermine security model
   of browsers
   ... and joe has raised questions and text questioning this practice.
   ... question is if the text is clear, crisp enough to change the set of
   recomendations in terms of robustness and compliance

   ifette: it is often not possible for browser to know what the plug-in
   is doing. plugins can invalidate the IA model of browser and that is
   what it is

   <yngve> Opera includes all plugin requests through Netscape

   <yngve> API (via browser) when evaluating security level for the

   joesteele: in regards to what yngve said, user agent may not know what
   plugin is doing, but not sure if this should be the way plugins should

   <yngve> (That does not mean we are able to tell or include everything
   the plugin does in the state)

   joesteele: IE has a way to be notified and should the issue be raised.
   looking at cardspace, cardspace greys out the background and security
   details that may be present

   <Mez> Mez' reply to Joe


   <Mez> Joe's mail:


   ifette: wsc may not be the place to suggest changes to the plugin api

   <Zakim> Mez, you wanted to say I liked the idea of allowing plug ins to
   be compliant

   phb2: part of the plugin architecture should have the capability to not
   IA details

   mez: concept that joe brought forward that seemed agreeable was to note
   how well behaved plugins met WSC guidance

   joesteele: regard cardspace as an external system but triggered by
   browser, are external systems part of WSC guidance, because they are
   launched by the browser.

   ifette: out of system text is in WSC text because of acrobat reader.all
   of the processing is taken on by acroreader. same as windows media
   player. browser is not informed of security status

   <johnath> Mez: fwiw, I'm silent here because I'm thinking about it - I
   will be in Oslo though, so I hope to have a considered opinion by then

   mez: if anyone has strong opinion on subject please take it on, request
   from joesteele to make additional email comments and clarify via email

   <Mez> issue-181?

   <trackbot-ng> ISSUE-181 -- Should there be an authoring practice
   suggesting http/https URI space consistency -- OPEN

   <trackbot-ng> [13]http://www.w3.org/2006/WSC/track/issues/181

   mez: on to issue 181
   ... http - https sharing same uri space, and consistent uri schem

   <Zakim> ifette, you wanted to axe this text

   mez: how users should get security context be obtained - available from
   https / http

   <yngve> [14]https://www.spv.no/

   <Zakim> johnath, you wanted to probably agree with ifette, depending on
   what he says

   ifette: original though was http site, https site should be consistent

   <ifette> +1

   johnath: don't think we need standard language around how the uri
   should be managed

   <joesteele> +1

   tlr: proposed handling for man in the middle attacks, looking for tyler
   to further define how the issue should be defined

   mez: move the issue to after june
   ... issue 181

   <Mez> issue-183?

   <trackbot-ng> ISSUE-183 -- Automatic Selfsigned Certificate
   acceptance/probation MUST NOT be implemented unless there is a history
   capability -- OPEN

   <trackbot-ng> [15]http://www.w3.org/2006/WSC/track/issues/183

   mez: on to issue 183 self signed certificate
   ... question on self signed certificates and pinning them


   tlr: 5.5.1 may support pinning through some interaction
   ... two choices user agent may use a notification that allows accept
   cert with pinning
   ... may use notification or should - not must

   mez: given how is stands a user agent could achieve conformance and
   automatically accept self signed cert, - does this change to must?

   tlr: change should to must to conform with yngve proposal

   <joesteele> +q

   mez: proposal to change 5.5.1 from should to must, does anyone object

   joesteele: likes wording but had question may provide mechanisim to
   pinning, can an automatic mechanism be in place that includes something
   like a whitelist

   johnath: cut them from your own ca and it will be trusted

   tlr: language in 5.5.1 applies to self signed cert that does not lead
   to a trusted root certificate.
   ... a technically self signed cert is validated, a degenerate case. the
   locallly configured trust root is used by the server in the tls
   transaction. noted as a poor practice

   <tlr> ACTION: thomas to propose language for SSC section that covers
   "locally configured trust anchor is actually shown by server" edge case
   - due 2008-06-07 [recorded in

   <trackbot-ng> Created ACTION-427 - propose language for SSC section
   that covers \"locally configured trust anchor is actually shown by
   server\" edge case [on Thomas Roessler - due 2008-06-07].

   yngve: a mechanism that the certificate has been used, accepted before
   by the user


   mez: after clarification from yngve 5.5.1 tls error - change item 4
   from should to must.

   tlr: generic issue if error signaling for non interactive user agents
   would be non compliant

   <tlr> When this specification speaks of a "Web user agent" to describe
   the application through which a user interacts with the Web, then this
   term is used on a conceptual level: No assumption is made about
   implementation details; the "Web user agent" may denote a combination
   of several applications, extensions to such applications, operating
   system features, and assistive technologies.

   <tlr> That, to me, means that non-interactive user agents are simply
   out of scope.

   <tlr> (thinking about it for a moment more)

   tlr: confused about non interactive user agent, wsc defines user agent
   as interactive. and this may need additional clarification
   ... if we have another mechanism to determine if cert is trusted

   joesteele: question on f the note is compete to define this issue



   <Mez> so, joesteele, can you look at the reference and let us know if
   you've got a case you think that doesn't cover?

   yngve: going back to tlr comments on user interaction. where user has
   set up prefetching

   <Zakim> ifette, you wanted to talk to yngve's point abouit prefetching

   yngve: user notes pages to be looked and and browser fills up cache

   <tlr> yeah, just don't prefetch, but fetch in realtime

   ifette: if client is prefetching, browser should not prefetch broken

   <tlr> +1, but I think we don't have to talk about it

   mez: on the table txt 183 change should to must

   <ifette> 3

   <Mez> A) first line [21]http://www.w3.org/2006/WSC/track/issues/183

   <tlr> If a client is able to automatically accept a Selfsigned
   Certificate, or recover from similar problem without user interaction,
   it MUST NOT do so unless the client also have a history mechanism about
   security information.

   <Mez> B) change
   item 4. to MUST

   <Mez> C) do nothing

   <ifette> I vote C

   <tlr> c

   <joesteele> c

   <Mez> Otherwise, user agents MUST use error signalling of class warning
   or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages).

   <Mez> zakim's who's here?

   <yngve> B is acceptable


   <tlr> errrrr

   <tlr> wait a sec

   <johnath> B

   <tlr> B


   <jvkrey> b

   <ifette> C

   <PHB2> b

   <joesteele> C

   <asaldhan> B

   <johnath> cheese doesn't have the same throughput that mice do

   <johnath> (indeed, cheese is famous for slowing urr... throughput)

   <jvkrey> beer is typically 50NOK for 0.4 liter

   <Mez> B: Yngve, Johnathan, TLR, Bill, Jan Vidar, PHB, Anil

   <Mez> C: Ian, Joe

   mez: option b, issue 183 item 4 change should to must
   ... on non interactive agents please further define
   ... request goes out to wsc wg

   <Zakim> asaldhan, you wanted to ask that I need NOK

   joesteele: concern is not so much about non interactive but locally
   configured. the locally configured trust anchors and interaction with
   unsigned certificates

   tlr: assumption self signed certificate could be trust anchor and part
   of the trust chain
   ... not always but sometimes can be trust anchor

   mez: tlr will rewrite text, tlr and joesteele appear to be in agreement

   <asaldhan> ACTION: asaldhan to incorporate above def to spec [recorded
   in [23]http://www.w3.org/2008/05/07-wsc-minutes.html#action02]

   <trackbot-ng> Created ACTION-428 - Incorporate above def to spec [on
   Anil Saldhana - due 2008-05-14].

   <Mez> issue-190?

   <trackbot-ng> ISSUE-190 -- Relaxed Path Validation - optional,
   recommended? -- OPEN

   <trackbot-ng> [24]http://www.w3.org/2006/WSC/track/issues/190

   mez: issue 190

   ifette: had time to think about it, relaxed path validation, browsers
   fine to handle certs in two different ways. but it could be confusing
   if browsers can validate using differnet ways


   <tlr> When, for a TLS-protected HTTP connection, the certificate
   presented is found to have been expired, error signalling of class
   danger (6.4.4 Danger Messages) MUST be used. Note that user agents that
   apply Relaxed Path Validation to non-AA certificates will never detect
   this error condition for such certificates.

   <Mez> as well as all of 5.4

   tlr: text is in 5.5.1


   tlr: 5.1.3 may use relaxed validation
   ... as well as 5.1.2

   <tlr> User agents MUST NOT use Relaxed Path Validation to validate
   paths that lead to an AA-qualified trust root. Instead, Basic Path
   Validation MUST be used.

   <tlr> User agents MAY use Relaxed Path Validation for certificate paths
   that chain up to a locally configured trust anchor which is not

   tlr: question to ian - if we were to drop relaxed path validation what
   is the message to user?

   ifette: user should get a modal warning

   tlr: warning - not danger, danger does not let the user through

   mez: clarify error and warning messages
   ... as to what generates warnings / errors

   <tlr> sorry

   <tlr> danger is explicit for domain mismatch

   <tlr> When the URL corresponding to the transaction at hand does not
   match the certificate presented, and a validated certificate is used,
   then error signalling of level danger(6.4.4 Danger Messages) MUST be

   PHB: starting to agree to punt the relaxed text

   <ifette> ISSUE: Domain name mismatch should be a WARNING and not a
   DANGER interaction

   PHB: agree with ifette

   tlr: would like to have a followup discussion, let it mature and take
   it up at f2f

   <yngve> Mez:

   tlr: continue on mailing list

   <johnath> ifette: don't think trackbot-ng noticed that, for some reason

   <yngve> Oslo Social at [28]http://www.sult.no/englishinformation.cfm

   <johnath> oh, you've noticed that :)

   tlr: next meeting is the f2f
   ... representitive from microsoft will be observing on second day

   <ifette> I is only sometimes a vowel?

   <ifette> :-)

   <Mez> :-)

   <Mez> wow, good question ian

   <Zakim> asaldhan, you wanted to tlr

   <asaldhan> Mez: ignore

   <Mez> sorry

   <Mez> maybe you can ping him on IRC

   <asaldhan> Mez: that is what I am doing now. :)

   <johnath> Mez: I forget, when do you get in again?

   <asaldhan> johnath: I get in Sunday around 1pm

   <Mez> Monday mid day; I'm not going to put in that extra day to frisk
   about after all

   <johnath> asaldhan: probably about the same for me - have to recheck
   that itinerary

   <ifette> I get in sunday around 5

   <Mez> [29]http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners

   <asaldhan> I had to book saturday as it was a difference of 700 dollars

   <ifette> arrives OSL 4:35pKL

   <ifette> KL1147 arrives 4:35p that is

   <Mez> if you put it inthe wiki you only have to type it once :-)

   <ifette> i didnt see a page on wiki for that

   <jvkrey> monday is a public holiday in norway, so shops are closed, btw

   <Mez> [30]http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners

   <Mez> iane

   <Mez> Ian

   <Mez> that's the wiki

   <Mez> page

   <Mez> which I sent out in email

   <Mez> [31]http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners

   <asaldhan> I cannot edit it

   <asaldhan> how do I edit it?

   <Mez> have you ever edited the wiki?

   <asaldhan> yes

   <Mez> did you ever get your name on the ACL t

   <Mez> ?

   <Mez> then it's just like that

   <asaldhan> I do not think it is on the acl

   <Mez> see Edit(Text) at the bottom?

   <Mez> if not, check with tlr about the acl

   <asaldhan> ok

   <asaldhan> pinging tlr

   what has to happen to scribe notes?

Summary of Action Items

   [NEW] ACTION: asaldhan to incorporate above def to spec [recorded in
   [NEW] ACTION: thomas to propose language for SSC section that covers
   "locally configured trust anchor is actually shown by server" edge case
   - due 2008-06-07 [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [34]scribe.perl version 1.133
    ([35]CVS log)
    $Date: 2008/05/07 16:47:21 $

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [36]http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: bill-d
Inferring Scribes: bill-d

WARNING: No "Topic:" lines found.

Default Present: MaryEllen_Zurko, Bill_Doyle, johnath, jvkrey, ifette, Thomas, y
ngve, joesteele, PHB, +1.708.524.aaaa, asaldhan
Present: MaryEllen_Zurko Bill_Doyle johnath jvkrey ifette Thomas yngve joesteele
 PHB +1.708.524.aaaa asaldhan
Regrets: Tim H

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 07 May 2008
Guessing minutes URL: [37]http://www.w3.org/2008/05/07-wsc-minutes.html
People with action items: asaldhan thomas

WARNING: No "Topic: ..." lines found!
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

   [End of [38]scribe.perl diagnostic output]


   1. http://www.w3.org/
   2. http://www.w3.org/2008/05/07-wsc-irc
   3. http://www.w3.org/2008/05/07-wsc-minutes.html#agenda
   4. http://www.w3.org/2008/05/07-wsc-minutes.html#ActionSummary
   5. http://www.w3.org/2006/WSC/Group/cheatsheet#Scribing
   6. http://www.w3.org/2008/04/30-wsc-minutes.html
   7. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0001.html
   8. http://lists.w3.org/Archives/Member/member-wsc-wg/2008May/0000.html
   9. http://www.w3.org/2006/WSC/track/issues/133
  10. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0218.html
  11. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0018.html
  12. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0015.html
  13. http://www.w3.org/2006/WSC/track/issues/181
  14. https://www.spv.no/
  15. http://www.w3.org/2006/WSC/track/issues/183
  16. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
  17. http://www.w3.org/2008/05/07-wsc-minutes.html#action01
  18. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
  19. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates
  20. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates
  21. http://www.w3.org/2006/WSC/track/issues/183
  22. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
  23. http://www.w3.org/2008/05/07-wsc-minutes.html#action02
  24. http://www.w3.org/2006/WSC/track/issues/190
  25. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-pathval
  26. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-validated-certificates
  27. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0039.html
  28. http://www.sult.no/englishinformation.cfm
  29. http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners
  30. http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners
  31. http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners
  32. http://www.w3.org/2008/05/07-wsc-minutes.html#action02
  33. http://www.w3.org/2008/05/07-wsc-minutes.html#action01
  34. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  35. http://dev.w3.org/cvsweb/2002/scribe/
  36. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
  37. http://www.w3.org/2008/05/07-wsc-minutes.html
  38. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Thomas Roessler, W3C  <tlr@w3.org>
Received on Friday, 6 June 2008 15:10:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:21 UTC