Web Security Context Working Group Teleconference
29 Aug 2007

 

 

<trackbot-ng> Date: 29 August 2007

Convene and stuff

<tlr> tlr: shawn MIA, can jvkrey scribe?

<tlr> jvkrey: yes, I wanted to do that anyway

<ifette> Is PIIbar on the agenda today?

<tlr> ScribeNick: jvkrey

<tlr> http://www.w3.org/2007/08/22-wsc-minutes.html

tlr: any problems with the last minutes?

<tlr> ifette: please fix chair name

<tlr> RESOLVED: to approve minutes provided thomas fixes the chair entry

action item review

<tlr> ACTION-281: closed

<tlr> ACTION-248: bump due date

upcoming meetings

<asaldha1> ifette, additionally clean up is needed for the phone numbers

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

<tlr> http://www.w3.org/2002/09/wbs/39814/codesprint/results

<ifette> ? I didn't say anything...

tlr: suggested code sprint on the next f2f

<ifette> @asaldha1, I didn't draft the minutes... did you mean to address that to someone else?

tlr: propose code sprint will not happen this year, but perhaps sometime next year

<asaldha1> ifette, yes. I have adding additional info to ur comment.

<ifette> Aaah ok thanks ;-) I thought you meant I had something to do.

johnath: sounds fine. Tyler might need help implementing PII, but that does not have to be anything formal

<johnath> fine by me

<tlr> RESOLUTION: no code sprint this year; continue to evaluate possibility for 08

tlr: please go to the questionaire

<tlr> http://www.w3.org/2002/09/wbs/39814/wscaustin/

<Zakim> johnath, you wanted to ask about the two remaining meetings

tlr: the Austin f2f is coming up in little more than four weeks, so please sign up soon, so all the practicalities can be made

johnath: Background on the w3c plenary?

<tlr> http://www.w3.org/2002/09/wbs/35125/TPAC2007/

tlr: the tech planary is a week where people for all working groups meet, talks, discussions, etc
... We will need face time since we are behind schedule, so please come to the plenary also

<Audian> TLR has heavy accent today ;-)

tyler: are all days of the tech plenary equally important?

<ifette> @Audian, echt?

tlr: the most important days are monday and tuesday.

<tlr> http://www.w3.org/2002/09/wbs/39814/meet2008/

tlr: recommend the other days also for seeing what's going on in other groups also
... Please have a look at the questionaire for f2f availability in 1st half of 2008

<asaldha1> Australia?

<stephenF> tech plenary registration form lists wsc meeting as member confid, maybe an error

state of note

tlr: use cases was last updated May 25, should be updated last week. We should get this note done or almost done by the next meeting.
... I'd like to review what action items are still open

tyler: I did a few changes for Issue 6. Looked on the list from Luis and Jan Vidar.

<tlr> Conclusion: We believe that ISSUE-6 is done

tlr: need cross checking with Luis

<tlr> http://www.w3.org/2006/WSC/track/issues/92

tlr: Where are we on issue-92, p3p?

<tlr> http://www.w3.org/mid/20070812120610.GX14409%2540raktajino.does-not-exist.org

tyler: do we have consensus on this?

<ifette> There was a conclusion in meeting to add 101 in

<tlr> http://www.w3.org/2006/WSC/track/issues/101

tlr: Issue 101, visiting known sites. We should just add that to the document.

<stephenF> me too

<serge> the blacklisting is out of scope, no? who cares how the backend works, we're interested in the display.

tyler: It worries me that this working group should recommend a black listing technique

ifette: the usecase isn't promoting a black list directly.

tyler: I think this is dancing around the question

johnath: If we include this recommendation, do we need to recommend a malware UI?

tlr: It's one of the things we should be looking at.

ifette: this is something browsers already are looking into. So it is a not a bad idea for us to look at this

PHB2: I agree. We actually have a toolbar that does black listing.

tlr: Should malware detection UI, etc be on the agenda?

<ifette> Yes

<tlr> tlr: in favor

<tyler> The Note is *not* the agenda for what rec proposals will be considered!

johnath: I can live with it, but I'd like to see the text.

<tyler> The Rec proposal list is the agenda

<stephenF> yes

<asaldhan> yes

jvkrey: I can live with it, but no strong opinion

PHB2: yes

rachna: yes, maybe we can make it more general

serge: ambivalent

<tlr> Should we include the use case included in ISSUE-101 in order to keep UIs for blacklists, reputation, etc, on the overall agenda of the group?

<ifette> I think the intent is "The browser believes the site is now distributing malware" not anything regarding blacklists specifically...

yngve: I can live with it

maritzaj_: yes

tyler: object. The question is misleading.
... I think we should do this as a recommendation proposal

<tjh> Tim Hahn joined

tlr: this means two things. 1 - we have dissent. 2 - it will take longer to get to a last call.

<ifette> Use case 19 is Vicki is interested in finding out more about art auctions in the greater Boston area. She engages a search engine and tries to follow a link there. Her web browser consults a reputation service which has recorded that the link target will attempt to subvert the browser and install malicious software. It already "presuppsoes this"

tlr: Tyler, I suggest you adopt the other issues. And we will have another mailing list discussion on issue 101.

<ifette> ok

loose ends for 5.3

<tyler> Ian, I agree that use case is faulty in the same way as the proposed one

<ifette> I wasn't saying 19 was faulty, I was using 19 to justify mine.

<rachna> Tyler, in your email, it would be useful to know why you think this should be a recommendation proposal versus a use case. That might be interesting to discuss.

tlr: Serge, you had an action item to contribute references to 5.3, any progress?

<tyler> Ok, I agree they share the same characteristic we are talking about

<tlr> ACTION-283 continued

serge: yes, finishing up today

<asaldhan> tlr: already pinged serge. he knows about it

<tyler> Rachna, will do

tlr: Section 5.3.2 should include some kind of disclaimer

<yngve> RFC 2817/RFC 2818

<tyler> The Vicki use-case is: <http://www.w3.org/2006/WSC/drafts/note/#any-iui-2>

stephenF: 5.3.2 presupposes URL/cert matching

<tlr> http://www.w3.org/2006/WSC/track/issues/new

section 4, tls for the web

<yngve> RFCs for checking cert for TLS

<tyler> URL?

stephenF: In general I think this section has a few terminiology issues.
... having some pseudo code that explains the whole section better would be nice

<tlr> ACTION: stephen to suggest fine-tuning of terminology in section 4 - due 2007-09-12 [recorded in http://www.w3.org/2007/08/29-wsc-minutes.html#action01]

<trackbot-ng> Created ACTION-284 - suggest fine-tuning of terminology in section 4 [on Stephen Farrell - due 2007-09-12].

yngve: I mentioned a few things earlier. The line about trusted certificates matches dereferenced URI should be cleared up a bit.
... When it comes to weaknesses, key sizes used in certificates should be counted

<serge> I need to get to another meeting.

<tlr> http://www.w3.org/2006/WSC/track/issues/new

<Zakim> stephenF, you wanted to ask about weakness

stephenF: Is it wise to nail down cipher suites and key lengths?

<johnath> stephenF++

<ifette> +1 stephenF

stephenF: I think it is difficult to come up with a exhaustive list of weak ciphers
... Should we leave it up to the implementers to decide what is weak and what is not?

<ifette> Is Camellia included in any of the things we're referencing? cause that's big news in Japan right now and I would hate to leave it out...

PHB2: I think there are other places that can give that information.

<johnath> we should be referencing, not decreeing. I feel like evaluating cryptographic strength isn't even in scope

tlr: I don't think we should give detailed information about individual algorithms

<tlr> ACTION: yngve to propose list of references on strong/weak algorithms; intent to *reference*, not *import* - due 2007-09-12 [recorded in http://www.w3.org/2007/08/29-wsc-minutes.html#action02]

<trackbot-ng> Created ACTION-285 - propose list of references on strong/weak algorithms; intent to *reference*, not *import* [on Yngve Pettersen - due 2007-09-12].

<stephenF> I'd not mention camellia at all

<stephenF> I was asking whether we should keep the idea of the no-user-interaction cert given

<stephenF> that pkix isn't planning to work on it

<stephenF> (I disagree with phb there)

<johnath> tlr: I'm going to drop off - phone issues abound, it seems

<tlr> johnath, would prefer to keep you on ;)

<johnath> I'd prefer that too!

PHB2: would like to issue a certificate that works now, and that doesn't give a pad lock or bother the user with accept dialogs in the future.

stephenF: why no padlock?

tlr: better phrased. The server can say; You don't have to trust me.

PHB2: the issue here is really about the implementation.

<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#id2300585

tlr: One point that bothers me in 4.5.4 of the current editor's draft. Typing in a https address is a bad thing, but clicking on a link is a good thing. Strikes me as confusing.

PHB2: typing in "https" creates an expectation about security.

<PHB2> 'may create' - I am not certain it does create an expectation but some might think it does

tlr: I'd like to make the "typing of https url" more generic.

<tlr> ACTION: tlr to change 4.5.4 into generic "if https typed, then expectation of strong security" text [recorded in http://www.w3.org/2007/08/29-wsc-minutes.html#action03]

<trackbot-ng> Created ACTION-286 - Change 4.5.4 into generic \"if https typed, then expectation of strong security\" text [on Thomas Roessler - due 2007-09-05].

<PHB2> low assurance, ~zero assurance

PHB2: we now have 3 buckets of certificates. Bad ones, normal ones and EV.

<tlr> 4.2 is a way to avoid validity period errors if OCSP isn't checked at all.

<Zakim> stephenF, you wanted to ask if that hard error for OCSP is wise

tlr: If no OCSP or CRL checking is done. then do not do validation checks

PHB2: Public wifi will redirect your webstart. This leads to problems with SSL since OCSP will be blocked, since access isn't granted on the access point yet.

<ifette> FYI re the use cases, consensus was already declared on that use case, so it would be *really* nice if people actually paid attention to their emails :( http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0149.html

<stephenF> ldap/ssl can have the same issue as wifi, but its way less important

tlr: I suggest everyone to have a close look at section 4.5 (change of security level). We will briefly come back to the question on dealing with verification error.

yngve: I'm not sure if I understand 4.2. Clarifications are needed