WSC weekly 2007-04-04 -- 4 Apr 2007

tlr: how much time?

<scribe> ScribeNick: johnath

<tlr> ACTION-175, ACTION-184 due in two weeks, tlr to change in tracker

tlr: how much time is needed

jvkrey: 2 weeks sounds good

johnath: agree

tlr: Mez_ do we have regrets for Staikos?

Mez_: no, no regrets

<tlr> ACTION: thomas to ping george staikos by e-mail and negotiate corresponding action [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action02]

<trackbot> Created ACTION-176 - Ping george staikos by e-mail and negotiate corresponding action [on Thomas Roessler - due 2007-04-11].

<jvkrey> johnath: yes, he said so last week

TLS practices

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0008.html

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Feb/0050.html

<tlr> http://www.w3.org/2006/WSC/wiki/NoteKDECertificateValidationErrors

<tlr> http://www.w3.org/2006/WSC/wiki/%20NoteMozillaCertificateValidationErrors

tlr: we had actions around documenting user agent behaviour with SSL cert errors...
... need to look into where there are matches/mismatches
... volunteers?

beltzner: we have asked our security community about this kind of flow chart, but they don't have one

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Feb/0050.html

beltzner: this is the wrong way to approach it - we should care more about the user-visible errors than the decision flowchart

tlr: yngve sent a similar list for opera as beltzner did for mozilla. Agree we don't need full flow chart, but we do need to understand what the user is presented

tlr: someone needs to look across the browsers, to see what consistencies/differences exist

Chuck: what kind of problems are we solving here, where is our scope

tlr: we want to understand what questions the major implementations expose to people wrt TLS/SSL validation problems

<beltzner> "how are we dealing with the user interface issues?"

Chuck: the variation between browsers is bigger than I expected.

<beltzner> "poorly"

Chuck: different tools about managing certs, different OS-specific dependencies, different rules about overrides

<Mez_> can you turn "poorly" into an "antipattern" recommendation? I've tried that with one of the items I've put in the recommendations list, to see how it flies

<beltzner> Mez_, that's a pretty good idea

<beltzner> "don't do it this way"

Chuck: to address this - we need experts assessing the landscape and providing common recs

<Mez_> here's the antipattern one I put in

<Mez_> http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge

tlr: We are taking the first step towards that, documenting in this group the behaviour of the browsers

<Paul> In the MS case, the scenarios get quite complicated since browser behavior is also dependent on host OS, and many, many configuration parameters that may or may not be in the user's control.

tlr: I'd like to keep away from the deeper stuff for now, and focus on the first issue around the errors/warnings in browsers

beltzner: things like validating ssl certs are out of scope - lower level protocol

<Mez_> yes Paul, I doubt we can do anything "completely", given that

tlr: but the UI presented by the user agent as a result is in scope
... so do we have a taker to survey across the browsers and look for commonalities/differences?

Mez_: standards bodies can include documenting existing common-sense behaviour

<Chuck> I guess we've discovered something that is both hard and time consuming

beltzner: the impediment is that I don't want to install every browser/platform
... cross-referencing is more containable than cataloguing

tlr: agree

beltzner: then I will take the cross-referencing item

<Paul> If there is a wiki page that demonstrates how we want to document the different behaviors I should be able to convince some co-workers to document at least some common scenarios in a similar format. However, it will be much easier to get that resource commitment if I can show them an example.

<tlr> ACTION: beltzner to aggregate material on TLS user interaces across browsers, based on input from vendors - due 25 April 2007 [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action03]

<trackbot> Created ACTION-177 - aggregate material on TLS user interaces across browsers, based on input from vendors [on Mike Beltzner - due 2007-04-25].

What is a secure page

<Mez_> Paul there are some examples in the agenda on this item; any of them what you were hoping for?

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0007.html

tlr: do we have any takers for the task of summarizing, as mentioned in the linked note?

<Paul> OK, are agreed that we want screen snapshots of the dialog boxes and description of the scenario that led to the dialog box?

<Mez_> Paul, yes, I like that format

<Paul> I'll see if I can get the commitment from our SWRT group.

<tlr> ACTION: yngve to pull together mixed content / "what is a secure page" material from earlier list discussions - due 18 April 2007 [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action04]

<trackbot> Created ACTION-178 - pull together mixed content / \"what is a secure page\" material from earlier list discussions [on Yngve Pettersen - due 2007-04-18].

tlr: lacking any volunteers, I will give it to Yngve, who had offered by e-mail to take it

Workshop recommendations

<tlr> http://www.w3.org/2006/WSC/wiki/InScopebyCategory

tlr: I'd like to ask hal if he can look at extracting concrete recos from the wiki page in terms of sizing

hal: honest answer is, I haven't thought about it. I had been assuming the doc would be more of a checkklist for proposals generated elsewhere...
... but I see your point. There is value here, but I don't have a sense of how much work it would be. A day or two, maybe, at most.

tlr: Suggest that we log an agenda item for the f2f in late May to revisit this list

<tlr> ACTION: zurko to put check of recommendation material against InScopbyCategory wiki item on f2f agenda; find volunteer to lead that discussion - due 15 May 2007 [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action05]

<trackbot> Created ACTION-179 - put check of recommendation material against InScopbyCategory wiki item on f2f agenda; find volunteer to lead that discussion [on Mary Ellen Zurko - due 2007-05-15].

maritzaj: are we recommending what not to do, as well?

Mez_: thomas - would you give maritzaj an action to map existing usability research to status quo in terms of best/worst practices

<tlr> PROPOSED ACTION: maritza to make pass to SharedBookmarks and other material; map testing results to status quo

<tlr> ACTION: maritza to make pass through SharedBookmarks and other material; map testing results to status quo [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action06]

<trackbot> Created ACTION-180 - Make pass through SharedBookmarks and other material; map testing results to status quo [on Maritza Johnson - due 2007-04-11].

<tlr> ACTION-180 due on 2007-04-18

Mez_: these can be turned into anti-pattern recos as well

Lightening Discussions of Proposed Recommendations

<tlr> ScribeNick: tlr

<Mez_> http://www.w3.org/2006/WSC/wiki/RecommendationIndex

MEZ: list of possible recommendations; thanks to everybody who added material
... on different levels of detail ...
... one of the talk of doing lightning discussions is to get feed-back ...
... idea is to talk about an item for 5 min, then trash^Wdiscuss it for 10min, then move on ...
... let's try that structure ...
... MEZ to monitor the time ...
... will take fairly literally ...

<ses> <--dropping off shortly.

EV certificates

MEZ: Phil, want to lead discussion on that, introduce the topic and possible recommendations?

phb: I was muted
... the basic idea of EV certs is accountability ...
... when somebody shops online ...
... they should know when their transaction is governed by accountability ...
... and when it isn't ...
... if I go online and buy expensive hi-fi from unknown ...
... and buy it from a shop that's not accountable, I might have lost my $3000 ...
... no redress ...
... money handed away, no effective redress...
... but if I know the shop well, know there will be accountability ...
... then I can buy with confidence ...

<ses> signing off

phb: idea is if I go to the shop and I know they are a registered business ...
... that gives degree of confidence ...
... that civil process can be served ...
... not about absolutely preventing something bad going wrong ...
... can buy plasma tv, company might be crook ...
... but know there's recourse ...
... deal with party that can be held accountable ...
... through law ...
... that makes big difference to security ...
... idea is to have set of standards that are minimum across CA industry ...
... CABforum ...
... it includes the major CAs ...
... and most of the browsers ...
... the thing about accountability is that it's not just about accountability for cert holder ...
... but also for issuing CA ...
... important element of IE7 EV user interaction ...
... people also get to see who issued cert ...
... that's critical ...
... if CA screws up ...
... and there will be failures ...
... failure rate is << 1% ...
... but there are bad certs ..
... make sure the issuer name appears in the chrome ...
... so when the Times complains, the trademark and confidence get tarnished ...
... all about accountability ...
... consumers either have accountability to actual merchant ...
... or to issuer of cert ...
... in future years, new classes of certificates may be ...
... insurances and other things like that built into certificates ...
... also, IE7 UI changes for EV certs ...
... any bowser can do that ...
... you see the subject name of the cert in the right hand side ...
... name of the company that the CA has vetted, rather than just domian nae ...
... domain names are easy to come by ...

mez: which parts of EV are appropriate for REC?
... about how to represent quality and signer? ...

phb: representing the quality is important ...
... distinguishing between EV and non-EV is important ...
... that is what browser vendors and CAs went into process to achieve ...
... displaying issuer is really crux of it ...
... if you don't, you don't get accountability ...

johnath: would like to supplement answer ...
... company name is important, rather than just domain name ...
... these are concrete pieces of information to extract from EV ...
... support different treatment ...
... do want to get to whether we are also contemplating specific UI recommendations ...

phb: need to make sure that folk don't confuse the issue by having presentations that suggest green bar for things that aren't EV cert
... think it would be appropriate to come out with some kind of statement ...

<johnath> http://blog.johnath.com/images/Identity%20Verified.png

phb: other possible approach would be to allow user to customize EV experience themselves ...

<johnath> mockup of another EV presentation style

phb: pros and cons to that approach ...
... some help against picture in picture, but some also mean each user has a different experience ...

chuck: want to poke at some of the assertions regarding how user should interpret indication that they deal with EV authenticated site ...
... implication was that somehow user is safer, might have recourse ...
... that seems to be slippery slope ...
... have never heard of CA backing up claim against malfeasance of biz ...
... is that practical to imply?

phb: CA at this point isn't insuring transaction.
... technically possible if the business model is right ...
... but might have defined process ...
... process in place that makes it likely that regress can be found

chuck: another benefit is enforcement of OCSP
... yet to see a browser that reports the success of OCSP check ...

phb: don't believe that current draft requires OCSP
... sth that VSGN argued for, but would have to re-read ..
... current req might be "must be revocation supported"

<johnath> thinking on alternate EV UI (per Mez_'s request): http://blog.johnath.com/index.php/2007/03/21/revisiting-security-ui-part-2/

<Zakim> tlr, you wanted to ask what "different" would be and to also comment on the green bar

<Paul> I'm concerned that EV certs become worthless if the storage of the root certificates on the user's machine become compromised. This leads me to think that we would also need to make recommendations regarding how certificate stores are managed and updated.

<Zakim> johnath, you wanted to reply to chuck's interpretation of EV=safety

<Zakim> paul, you wanted to ask Does lead us to also make specific recommendations about how root CAs are managed for all platforms?

<scribe> ACTION: hallam-baker to summarize EV cert discussion and deliver proto recommendations in Wiki - due 18 April 2007 [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action07]

<trackbot> Created ACTION-181 - summarize EV cert discussion and deliver proto recommendations in Wiki [on Phillip Hallam-Baker - due 2007-04-18].

SSL/Certificate dialogs

e.g. http://lists.w3.org/Archives/Public/public-wsc-wg/2006Dec/0166.html

mez: michael, do you have recommendations here?

mikeMcC: bad example from MS ...
... there's an anti-pattern in here ..
... would be happy to turn that into an anti-pattern ..

mez: 5 min!

mike mcC: visited web site -- think it's X9 ...

scribe: they didn't chain to root ...
... was led by IE6 UI down a rabbit hole of incomprehensible error messages ...
... interesting terminology ...
... request to contact the very URI I was trying to visit, but which led to the problem ...
... slightly crazy ...
... core anti-patterns use of obscure technical jargon ...
... even if user knows what certificate is ...
... use of punting to web site as anti-pattern ...

tlr: the mozilla dialogue...
... action advice to users should be safe and feasible ...
... trustworthy and untrustworthy information must be marked clearly; don't lead users to decide based on untrustworthy information ...

mikeM: +1; not easy to distinguish to distinguish a chrome-like dialogue from one that might have come from javascript ...

<beltzner> +q

<tlr> the one I'm talking about is here: http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors?action=AttachFile&do=get&target=mozillaSSLerror-generic-warning.png

mikeM: think these are good anti-patterns in addition to jargon ...

chuck: there's the certificate for the site ...
... and there's context information ...
... what's confused is the context information for issuers ...
... there are some problems with CAs that aren't known by browser ...
... context you're really dealing with not the cert you visit, not the root, but an intermediate ...
... there's almost no guidance to what the significance is ...
... browsers and other UIs take user into context that's separate from site ...
... take then into context to deal with issuer, give them tools to deal with the issuer ...
... current practice is source of a lot of confusion ...

<tlr> see http://www.w3.org/2007/03/30-tlr-budapest.pdf, slide 64, btw

beltzner: if user ever gets to that dialogue, then they've lost
... it's all gobbledygook ...
... the real anti-pattern is we shouldn't be asking users questions that they can't reasonably answer ...
... these are asking users questions that they can't reasonably answer ...
... if somebody has a properly validated cert, then users shouldn't see this ...
... can find a lot of metaphors ...
... the anti-pattern is exposing the technology model ...

phb: hang on, two questions here ...
... "why is this not paypal" ...
... "why isn't this somebody I expect" ...

<Chuck> I agree, it's gobbledygook to me as well, and I've set up multi-level cert hierarchies. My point is that the dialogues are dealing with something that is outside of the user's context. Either take them into a context where they can deal with the problem, or give them a rational interpretation of how to proceed, or not.

phb: keep slipping into idea that problem knowing "is it" paypal ...

<Mez_> PKI and bookmarks and petnames and such; all ways to say "is this someone I should have heard of"

phb: or "is Victoria British" ...

tlr: what's the positive recommendation here.

beltzner: suggesting that exposing the technology is an anti-pattern ...
... will make suggestions as part of dealing with prior action ...

johnathan: coming back to tech layer and validating intermediary CAs isn't going to give answer about the trusted vendor

phb: Generically, if we get into that dialogue, 99% of the cases we are at the Victoria British site ...
... and some bozo hasn't renewed cert ...
... these dialogues were in there as a debugging tool ...
... I've been told ...
... agree that it isn't useful ...

<johnath> Mez_: duly noted

<johnath> :)

phb: conclusion we're drawing here is "this ain't victoria british" ...
... it might mean they've just done some sort of boo-boo ...

mikemc: some more detail about the example that started this ...
... it was x9.org ...
... I was on that site ...

<PHB> Maybe the recomendation here should be for Web SERVERS, do not present a stale cert

mikemc: never really in doubt ...
... they used their own CA ...
... that root wasn't in the key store ...
... [reads the IE message] ...

<Chuck> The reality is that lots of users are getting errors relating to intermediate CAs, so we have a larger problem that the security context is "too complex" for real users, and even security experts. This kind of problem crops up even when the site's cert is valid, but the chain is not recognized by the user's browser.

mikemcC: what are the consequences of clicking "yes"? What are the risks?

mez: take notes, put together updated item into wiki with possible recs

<PHB> My take on the X9 situation: turn on SSL without bothering the user at all. Just don't show the padlock or anything that says secure

<PHB> Incidentaly, this issue does not occur with EV, it is not possible to add an EV root to the store as a user.

<scribe> ACTION: McCormick to summarize TLS discussion and extract proto recs into wiki [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action08]

<trackbot> Created ACTION-182 - Summarize TLS discussion and extract proto recs into wiki [on Michael McCormick - due 2007-04-11].

<scribe> due at same time as Beltzner's action to summarize prior input about TLS

wrap-up

MEZ: we're running out of time

Tyler: I'd have a good use for 4 min of presenting

TrustMe

Tyler: segways nicely from the certificate discussion ...
... browser shouldn't ask unreasonable questions ...
... URI inside domain name includes arbitrary delegation chain ...

<Mez__> http://www.w3.org/2006/WSC/wiki/TrustMe

Tyler: users odn't understand that ..
... similar to cert chain, there's long sequence of updated RFCs ...

Tyler: to define the semantics, that took a while ...
... asking users to vet URIs is unreasonable ...
... users can't do it ...
... recommend against displaying URI on top of the page ...

beltzner: have you seen any of the location bar ^2 discussion?
... demoed this at last f2f ...
... gone through cycle from reasonable through crazy through reasonabe ...
... doesn't show full URI ...
... strips some useless stuff off ...

tyler: update available?

<johnath> wiki discussion of locbar2: http://wiki.mozilla.org/Firefox3/Location_Bar

beltzner: johnathan is working the laptop
... it dovetails nicely into some sort of interface recommendation ...

<johnath> project page for locbar2 http://en.design-noir.de/mozilla/locationbar2/

tlr: I think there's a flip side in here that users need *some* way to get to the URI

johnathan: location bar ^2 goes back to original URI on hover ...
... can edit as a text box ...
... stylized when not interacting, to remove the useless parts ...

beltzner: maintain type-in ability, but take away distraction
... more understandable display ...

tyler: dispute the notion that expert users can safely use URIs
... if you have a name that's a close homograph ...

beltzner: don't disagree ...
... only saying that modifying URI is an interaction that's still available ...

tyler: requirement that there be a way to type in a URI?

beltzner: type in and modify?

tyler: mode where you hit key and then you've got a dialogue -- is tha tok?
... but no version displayed on default screen?
... would that take care of requirements?

beltzner: close, but there are ways to do this without modal interfaces

tyler: confident that there is display of domain names that prevents homograph attacks?

beltzner: we're getting closer

tlr: a rec would speak about this in the abstract, then list implementation techniques

<scribe> ACTION: tyler to go over TrustMe notes, update in wiki - due 2007-04-18 [recorded in http://www.w3.org/2007/04/04-wsc-minutes.html#action09]

<trackbot> Created ACTION-183 - go over TrustMe notes, update in wiki [on Tyler Close - due 2007-04-18].

wrap-up 2

applause

mez: next week
... we'll continue ...
... please request other agenda items if there are things you want to discuss ...
... please do what you can to get them in ...
... meeting adjourned ...

WSC weekly 2007-04-04
4 Apr 2007

Attendees

Contents

approval of last meeting's minutes

newly closed action items

robustness practices

TLS practices

What is a secure page

Workshop recommendations

Lightening Discussions of Proposed Recommendations

EV certificates

SSL/Certificate dialogs

wrap-up

TrustMe

wrap-up 2

WSC weekly 2007-04-04 4 Apr 2007

Attendees

Contents

approval of last meeting's minutes

newly closed action items

robustness practices

TLS practices

What is a secure page

Workshop recommendations

Lightening Discussions of Proposed Recommendations

EV certificates

SSL/Certificate dialogs

wrap-up

TrustMe

wrap-up 2

WSC weekly 2007-04-04
4 Apr 2007