See also: IRC log
<trackbot-ng> Date: 29 August 2007
<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: any problems with the last minutes?
<tlr> ifette: please fix chair name
<tlr> RESOLVED: to approve minutes provided thomas fixes the chair entry
<tlr> ACTION-281: closed
<tlr> ACTION-248: bump due date
<asaldha1> ifette, additionally clean up is needed for the phone numbers
<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
<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: the tech planary is a week
where people for all working groups meet, talks, discussions,
... 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: 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
<stephenF> tech plenary registration form lists wsc meeting as member confid, maybe an error
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: Where are we on issue-92, p3p?
tyler: do we have consensus on this?
<ifette> There was a conclusion in meeting to add 101 in
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?
<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
jvkrey: I can live with it, but no strong opinion
rachna: yes, maybe we can make it more general
<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
tyler: object. The question is
... 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.
<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
<yngve> RFCs for checking cert for TLS
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.
<Zakim> stephenF, you wanted to ask about weakness
stephenF: Is it wise to nail down cipher suites and key lengths?
<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: 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