See also: IRC log
<tlr> Scribe: brad
Minutes approved
<tlr> RESOLVED: minutes approved
Action items closed
<tlr> http://www.w3.org/2006/WSC/wiki/UserDebugging
<beltzner> debugging use case: http://www.w3.org/2006/WSC/wiki/UserDebugging
Mez: Debugging use case is about making lower
level security context information available in some fashion... applicable in
use cases where someone is trying to help a user and needs lowerlevel
information to assess what is happening
... Outside of the remote debugging category, group has generally said lower
level information should not be available to user
... there are other cases such as browser evaluation where more details is
helpful
Mez: We also note that it seems outside our
scope to specify how lower level details are presented
... but we don't want to do anything that precludes it
Bob: Is there anything on the website that describes the process from use case->recommendation
Mez: We don't have a document describing our process, W3C has a very large document on W3C Process
TLR: Charter that describes general
proceeding
... suggest for debugging use case that we take this one into the note with a
remark that this is a use case we do not want to preclude
chuck: might not want to throw this out so quickly... users do want to be able to get some 'confirmation'
chuck: what we're talking about is not so
different than clicking on the lock icon
... is there justification for putting a button in the chrome that means 'i
want additional information and confirmation of this site and if you want
3rd-party review, click here'
... this could be very useful to users and may be something that we would
want in scope
hal: I think we should say that this information should be only "on demand"
<beltzner> bwporter: I think you're designing the ui and back-fitting the use case; the motivation should begin with what the user wants, and I suspect that you're actually talking about a different use case than Mez
hal: may want this data to analyze network configuration
<Tyler> Do any of the arguments made in favour of debugging information require a consistent user interface across all web user agents? I think no.
beltzner: we're splitting this from the original use case where the user wants help which is different from the use case where the user wants to verify or debug
beltzner: we should focus on core and let browser vendors innovate at the edges
chuck: this is an area where we need browsers
to be consistent
... at one level this is a tool for users to gain additional confidence
... for example, my daughter was going through a credit application for a
student loan... at that point, IE7 started complaining that the cert had been
revoked
... i was at a standstill to try to figure out what was going on
... we have the debugging problem and the question -- what is the
interface?
tlr: i see this use case as a 'catch-all' that
we should document that we do not want to preclude expert interface
... what i hear from chuck is a use case that is quite different from the
'catch-all' use case
... would you be willing to write up that use case?
<tlr> ACTION: chuck to document the debugging-related "positive" use case [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action01]
<trackbot> Sorry, couldn't find user - chuck
chuck: I would be willing to write it up, i think it has some overlap with what is already here, but it may help flesh out the different issues
<tjh> there is a difference between "expert investigation" (sometimes called debugging) and "end user alerting"
tyler: this might fit into the non-goals section that we removed... shall i add it back in?
<tlr> tjh, right, that's the point
mez: why don't you float it out and see if
there is consensus?
... i hear some dissention about whether this is a non-goal or not
<tlr> http://www.w3.org/2006/WSC/wiki/TLSMiddleMan
<Tyler> http://www.w3.org/2006/WSC/drafts/note/Overview.html#MITM
<tlr> http://www.w3.org/2006/WSC/drafts/note/Overview.html#MITM
tlr: question is what should happen if the TLS information doesn't match... recommend that this is something we should take up in the final document
tlr: discussion on the mailing list that 'misconfigured' certificates like this might be 'ok'
george: there are some cases where we allow a
certificate to go through in a scenario that has to do with a horribly
configured server
... we should deal with this directly
... if browsers aren't consistent, people just switch browsers
mez: why would we consider certain types of security information worse than no security information
george: we start to reduce the number of
different cases... closer to boolean
... isn't boolean today -- lockbox and dialogs today
tyler: urls set up by https are setting an expectation that the session is going to be well configurated
brad: fail fast policy is simpler, easier for users, and cleaner to implement
hal: believe the RFC states that you should flag an error explicitly
<tlr> ACTION: hal to dig out TLS RFC's normative language on mismatch between cert and domain name [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action02]
<staikos> and definitely no-one is doing that now :-)
<trackbot> Created ACTION-83 - Dig out TLS RFC\'s normative language on mismatch between cert and domain name [on Hal Lockhart - due 2007-01-30].
<Tyler> Are we all happy with the wording of this use case in the Note?
<Mez> Are we unhappy?
phb: folks are also looking into a situation where a cert has multiple domains listed
<tlr> Doesn't subjectAltName take care of that?
<tlr> (or whatever it's called)
<Tyler> Theres a TLS extension for handling Phil's case
phb: ssl session needs to be set up before website domain is established
mez: is there a link to something that describes this scenario?
<tlr> ACTION: Hallam-Baker to produce material on name-based virtual hosting and TLS [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action03]
<trackbot> Created ACTION-84 - Produce material on name-based virtual hosting and TLS [on Phillip Hallam-Baker - due 2007-01-30].
<tjh> perhaps an example there of what certificates contain (including wildcards) and what implications that has on systems/IP stacks, etc.
<tjh> would be good
chuck: picking up on phils point -- wildcarding has left browsers and users in a state of confusion... may be an opportunity here
<staikos> phb: I believe that using SSL on a multi-domain host, thereby causing domain mismatch errors would also be considered broken system administration and an error case
mez: at a note level is there anything we want to address this?
<tjh> should we offer best practices/guidelines for web masters/hosters for setting up certs along with their systems?
chuck: will summaries core issues
<Zakim> hal, you wanted to RFC 2818
<tlr> ACTION: chuck to summarize issues around deployment of certificates in wildcard / virtual hosting situations [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action04]
<trackbot> Sorry, couldn't find user - chuck
<tlr> ACTION: wade to summarize issues around deployment of certificates in wildcard / virtual hosting situations [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action05]
<trackbot> Sorry, couldn't find user - wade
hal: RFC 2818 describes HTTP over TLS and does discuss processing by client
<tlr> traackbot, initialize
<tlr> trackbot, initialize
<trackbot> Tracking ISSUEs and ACTIONs from http://www.w3.org/2006/WSC/Group/track/
<tlr> ACTION: wade to summarize issues around deployment of certificates in wildcard / virtual hosting situations [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action06]
<trackbot> Sorry, couldn't find user - wade
hal: section called "server identity" states client MUST check against URI
<tlr> ACTION: thomas to prod chuck to summarize issues around deployment of certificates in wildcard / virtual hosting situations [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action07]
<trackbot> Created ACTION-85 - Prod chuck to summarize issues around deployment of certificates in wildcard / virtual hosting situations [on Thomas Roessler - due 2007-01-30].
phb: may be in an area where we're highlighting
a problem in TLS
... we do not want to use chrome to fix a problem at the TLS layer -- layer
conflict
<Chuck> Changes to TLS, or to the way that http operates over TLShal
phb: if out-of-scope for our work, we may still want to file a defect report with the TLS working group
tlr: focus on getting material for note, and then decide whether to use the material on the note or on a defect report
hal: just a comment that current text in TLS man-in-the-middle is very cryptic... is this use case a hack or normal behavior?
tlr: meant to be a description of an interaction we need to consider
tyler: do we need to answer the questions in the note or just document that these are questions we want to answer?
hal: we should take a stance on whether this is correct or incorrect behavior
<tlr> http://www.w3.org/2006/WSC/wiki/CAAcceptance
<Tyler> http://www.w3.org/2006/WSC/drafts/note/Overview.html#unknown-CA
<Tyler> "Click here to continue" as the CA name
<staikos> we could give the hex bytes for the UTF-8 encoding of the O field. Do you trust "0x ......" :-)
tlr: how should user interface look when encountering an certificate that is not signed by a trusted authority?
hal: generally feel that given all the ways a certificate can fail we may find that each scenario needs to fail separately
<staikos> oh boy that's a big task for KDE :-) we pop up far too many
tlr: would like to ask browser vendor representatives to look through code and help categorize failure modes
<tlr> ACTION: staikos to document what certificate validation errors Konqueror displays [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action08]
<trackbot> Created ACTION-86 - Document what certificate validation errors Konqueror displays [on George Staikos - due 2007-01-30].
tyler: second notion that each should be a separate use case
<tlr> ACTION: yngve to document what certificate validation errors Opera displays [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action09]
<trackbot> Created ACTION-87 - Document what certificate validation errors Opera displays [on Yngve Pettersen - due 2007-01-30].
<Zakim> tjh, you wanted to ask if the "user agent" cannot tell a bug/config error from an attack/threat ... do we recommend "implied deny" or "implied permit"?
<tlr> ACTION: beltzner to document what certificate validation errors Firefox displays [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action10]
<trackbot> Created ACTION-88 - Document what certificate validation errors Firefox displays [on Mike Beltzner - due 2007-01-30].
tyler: extreme scenarios, but also rare occurences
<PHB> Reply from EKR on the TLS issue: "There is an extension designed to support name-based virtual hosting.
<PHB> See RFC 4366 S 3.1"
<Tyler> and therefore important to be presented consistently across user agents
<tlr> ACTION: thomas to ask Rob to do the same for IE7 [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action11]
<trackbot> Created ACTION-89 - Ask Rob to do the same for IE7 [on Thomas Roessler - due 2007-01-30].
tjh: can user agent tell the difference between
bug and configuration error? if user agent can't tell, can the user?
... implied deny or implied permit?
<tlr> ACTION: thomas to ask Rob Franco to document what certification verification errors IE7 displays [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action12]
<trackbot> Created ACTION-90 - Ask Rob Franco to document what certification verification errors IE7 displays [on Thomas Roessler - due 2007-01-30].
maritza: should there be a difference between the types of dialogs a user sees when they're accepting for one-time or for all-time?
brad: in favor of taking a hard stance and not document every edge case
tlr: helpful to understand what the browsers are doing... result might be an appendix saying this is what happens today
brad: agreed on knowledge-gathering, frightened by evaluating each one-by-one in designing solutions
<Tyler> http://www.w3.org/2006/WSC/drafts/note/Overview.html#warning-lost
<beltzner> Mez: do we have details on where within the BEA HQ we're supposed to go, btw?
<beltzner> http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners is where this info should go, maybe?
<tlr> ACTION: thomas to start discussion about RevistingPastDecision on list [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action13]
<trackbot> Created ACTION-91 - Start discussion about RevistingPastDecision on list [on Thomas Roessler - due 2007-01-30].
<tlr> ACTION: hal to send more detailed geography info about meeting to member-visible list [recorded in http://www.w3.org/2007/01/23-wsc-minutes.html#action14]
<trackbot> Created ACTION-92 - Send more detailed geography info about meeting to member-visible list [on Hal Lockhart - due 2007-01-30].
<tlr> I'm collecting stuff at http://www.w3.org/2006/WSC/f2f2.html