- From: Thomas Roessler <tlr@w3.org>
- Date: Thu, 25 Oct 2007 11:35:07 +0200
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2007-10-03 were approved and are
available online here:
/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group face-to-face
3 Oct 2007
See also: [2]IRC log, [3]Agenda
Attendees
Present
Luis Barriga, Johnathan Nightingale, Tyler Close, Rachna
Dhamija, Serge Egelman, Ian Fette, Mary Ellen Zurko, Phillip
Hallam-Baker, Maritza Johnson, Yngve Pettersen, Hal Lockhart,
Michael McCormick, Anil Saldhana, Thomas Roessler
Regrets
Bill Doyle, Tony Nadalin, Dan Schutzer
Chair
MEZ
Scribe
asaldhan, maritzaj, luis
Contents
* [4]Topics
1. [5]ISSUE-83
2. [6]Page Security Score
3. [7]overview section of rec-track document
4. [8]Tracking motivation examples, text
5. [9]Short Name for rec track document
6. [10]Review of Open Issues
7. [11]ISSUE-96
8. [12]ISSUE-97 / ISSUE-102
9. [13]ISSUE-97
10. [14]ISSUE-98
11. [15]ISSUE-99
12. [16]ISSUE-103
13. [17]ISSUE-104
14. [18]ISSUE-105
15. [19]ISSUE-106
16. [20]ISSUE-107
17. [21]ISSUE-108
18. [22]Last Call for wsc-usecases
__________________________________________________________________
Agenda bashing
<ifette> ScribeNick: asaldhan
mez: ACTION-307?
... great if we could decide on a short name
... take a look at rec track doc and see if we can make progress
... anything for agenda bashing
ISSUE-83
<Mez> [23]http://www.w3.org/2006/WSC/track/issues/83
<Mez>
[24]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0012.html
Mez: irc has links to the issue and the email I sent
... use case 2, we use the text tlr sent last night
... I did track down Ian's message
... could not find any issues raised by anyone
<Mez>
[25]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0009.html
tyler: pointer to use cases we are considering
Mez: in the link here
... usecase 1,2,3
tyler: people have sent new drafts of use cases?
<tlr> anil, if you have a log of the last 5 minutes, this would be an
excellent time to paste it into IRC
<Mez>
[26]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0011.html
Mez: no new drafts.
johnath: use case. drop text. preamble.
Mez: only new text from thomas
tyler: like thomas's proposal for use case 2
Mez: good job thomas. Anybody else with text for the new proposal
johnath: your proposal to include use case 3?
Mez: yes
... I declare consensus. ISSUE-83 is resolved
RESOLUTION: ISSUE-83 closed. use-case 1 dropped; use-case 2 replaced by
tlr's text, use-case 3 adopted
Page Security Score -- ACTION-307
<Mez> [27]http://www.w3.org/2006/WSC/track/actions/307
Mez: newly bashed agenda item - ACTION-307
... page security score
<Mez>
[28]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0013.html
Mez: do not insist that we deal with it now
... link to the mail msg. Let us take few minutes at it and have
discussion to raise any issues that may come up
<MikeM> concur with language (except typo on last line)
hal: which email messages
<tlr> "it"?
yngve: some may object to third section, formula not being available
<Mez> concern about publishng formula - some believein security through
obscurity
Mez: yngve is concerned about 3rd section, formula unavailable
hal: any good security system keeps some measures secret
Mez: glad that yngve brought a good point for fpwd
... I am surprised with Mike that you surprised with the last one
... everyone wants to correct grammar in real time
<MikeM> :)
tlr: what does strictly comparable mean
Mez: could not find mathematical term
... it is like a balance
hal: it is like a partial order.
luis: somebody mentioned that the formula is replaceable
Mez: I have not picked any issue from yest. Do u want to draft a
suggestion on irc?
luis: not part of the user agent.
<MikeM> "pluggable formula"
Mez: someone wants to take an action on this or just leave the
conversation where it is
tyler: did we skip agenda bashing
Mez: no
tyler: there is a overview section of rec track document and I wannt to
discuss it
Mez: ACTION-307
... if no one raises any issue
... couple of mins
ifette: ???
... user agent must make the formula directly available
Mez: point of having a name was to dereference to the formula
ifette: proprietary formula may not be shared
Mez: what would be the resolution on this?
ifette: user agent should identity the formula
<ifette> ifette: My prefered language would be "The user agent MUST
identify the algorithm used to calculate the score"
PHB: there are many algorithms that no one understands
Mez: how do u like this, phil?
PHB: identified
Mez: few more minutes
<Mez> [29]http://www.bartleby.com/165/1.html
<MikeM> "Agent MUST allow the user to choose an algorithm provider."
tlr: one more question on the language
... documentation has it
Mez: something new
tyler: we are writing a requirement in the document that it is
accessible
tlr: requirement for a formula is quite weak
ifette: formula can be swapped out and changeable means something in
the agent should identify which is being used
... do not want to press F1 to find which formula I am using
Mez: use amended line and reference to document
MikeM: I am saying the same thing as ifette
ifette: ???
johnath: I think my preference would be to use products that disclose.
But I am not sure we need to mandate
... some people may prefer an algorithm that is widely discussed in
research etc
Mez: does anybody hate the idea of reducing it to identify the
algorithm
PHB: not necessarily they will reverse engineer the code
hal: we are not prohibiting anybody. right?
... because they may want to keep the algorithm secret
MikeM: I want to know who the provider here
johnath: want to know who the browser is connecting to etc
... people are complaining about firefox dumping data to google etc as
an example
<MikeM> identify the algorithm and the provider
yngve: some body will do packet sniffing. Advertising service in opera
some years ago. First thing, people did was to packet sniff to see if
opera was sending bad data
Mez: not getting alternative proposal to the line
... consensus
tlr: changes are "identify provider and algorithm"
Mez: in place of the third section
<Mez> [30]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Overview
overview section of rec-track document
Mez: agenda item: section item from tyler
ifette: the rec draft is present in the process document
<Mez>
[31]http://www.w3.org/2005/10/Process-20051014/process.html#first-wd
ifette: question remains if the status goes into the document, what
goes into overview
<tlr> s/in place of overview/in the document/
Mez: people with suggestions for the overview can send asap
Tracking motivation examples, text
<Mez>
[32]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0014.html
Mez: concern as a chair is that it takes a lot of time to reply to
comments
... expect more on rec track document than use cases
... will take us a lot of time to get through comments on rec track
... need volunteers
... number of areas in rec track document to identify text.
... email archives, wiki
... folks replying to comments can use these
... as we are getting closer to fpwd, wondering if it can be made
easier
... I am tracking about motivation on important things
tyler: we owe it to readers to collect and put it in the document
ifette: I thought rec track document was a recommendation and not meta
information
tlr: explanation can be placed as long as things being specified do not
get confused
... space present in the document to explain and make things better. I
would not include all background such as email link
Mez: I find it useful to add meta link as well
tlr: part of it is use issue tracker for questions
Mez: I would like a way to specify in the document
tlr: natural for working draft but less natural for final document.
Editor notes etc are fine to be added during the process
tyler: we are different from other WG like we are doing R&D here. So we
need to add more explanation
johnath: agree with tyler. I also want to find out once FPWD is done,
how often do we push rev
... if we get comments in 2-3 days, can we give a response at the
earliest
Mez: with the resources we have, it will be difficult
tlr: our comments are publicly archived. So responses will be
available. They have to search
johnath: I know we cannot have a wiki, but would like a fluid way to do
locate the responses for the responses.
... if we add motivation to every section, it will improve acceptance
of the document
<johnath> please hold - network issues locally
johnath: want to add a trail to where the readers are coming from
Mez: want to get to FPWD real soon
... displayed by my strong desire for timeliness via placing proposals
on the wiki
tyler: some support got on ???abc
... explanatory text can be placed in the document in place of the wiki
Mez: I would prefer consistency
ifette: depending on the volume on the explanatory text, it should be
fine to put it in the document
<tyler> tyler: there was some support for adding more explanatory text
to the FPWD, perhaps as an appendix. I'm willing to do that work for
PII editor, can I add explanatory text to the FPWD?
Mez: 3 proposals to place text in the rec track document for fpwd
... with the need for rapid fpwd, I want a proposal that does not take
more than 4 hours to execute
tlr: first of all, some of the proposals have seen multiple changes
before landing into the document
... some proposals have been broken into pieces before placing
... less time on the proposals will mean counter productive
... for some, it is obvious what to link. But for others, not obvious
... many proposals were just not dropped into the draft, but were
worked on
<Mez> tlr worried that putting in the pointers will cause some
confusion since many have been clarified
<Mez> mez acks; likes the tradeoffs anyway
<Mez> before that, tlr doesn't like appendices for similiar reason
<Mez> mez takes the bet to put in an hour and propose where the links
to the proposals should be
<Mez> someone should create her an action
Mez: we are between proposal 1 and 2
tyler: should I move the PII editor text into the wiki?
Mez: yes
<johnath> ACTION: mez to provide a first pass of associating wiki links
with the FPWD text [recorded in
[33]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-312 - Provide a first pass of associating
wiki links with the FPWD text [on Mary Ellen Zurko - due 2007-10-10].
tlr: waste of time to reformat into wiki. take the overview html, throw
about the rest and place it as a separate html
Mez: that takes care of the agenda item
... to the next agenda item
Short Name for rec track document
johnath: let us do wsc-recommendations
<MikeM> Final Rec Document (FRD)
phb: web security experience document
<Mez> Web Security Experience, Indicators and Trust: Scope and Use
Cases
<Mez> is the note
<Mez> wsc-usecases
<Mez> wseit
<johnath> Web Security Experience, Indicators and Trust abbreviates
nicely to Web SEXIT
<ifette> +1
<tlr> wsc-exit
<Mez> WSXIT
<Mez> wifse
<Mez> web indictors [for] security experience
<Mez> wsxit or wise
<ifette> -q
<ifette> -1
<ifette> +1 to @johnath
<tlr> wsc-exit
<tlr> wsc-xit
johnath: like wsxit
tlr: I would stay away from ws-*
<Mez> experience indicators and trust
<tlr> wsc-xit
<ifette> WSC-XIT?
<tlr> Web Security Context: Experience, Indicators, and Trust
Mez: proposal from thomas here
<ifette> to be abbreviated WSC-XIT, no?
Mez: going once, going twice
<ifette> not EIT...
Mez: consensus
<tlr> Xprinc
<ifette> RESOLUTION: name for document is Web Security Context:
Experience, Indicators, and Trust, to be abbreviated WSC-XIT
Mez: after the break, want to take a look at the issues in the rec
track document
<tyler> tyler: Want it in the record, that I am frustrated that we all
agreed for a template for the recommendation proposals and now we are
not using any of the text created to that template, except for the
"Conformance" section. In my opinion this change does not reflect the
consensus opinion reached by the working group.
<tlr> tyler, your change to the 19 Sep minutes is in the online version
now.
<Mez> [34]http://www.w3.org/2006/WSC/track/products/4
Mez: we will go over the issues in the document that editors feel that
we will make progress on
<tlr> [35]http://www.w3.org/2006/WSC/track/products/4
<Mez> [36]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html and search
for Issue
<Mez> two lists
Mez: follow the above link to get the issues and search for "issue" in
the rec track document
<ifette> ScribeNick: maritzaj
Review of Open Issues
<Mez> [37]http://www.w3.org/2006/WSC/track/products/4
mez: and now the plan is to look through the issues on our rec track
document to see if we can make progress on some
... if not, we'll move on
... when I put together the list of issues in the minutes, i skipped
the ones that didn't seem addressable in our meeting, 96 is the first
listed -- anyone think these issues are ones they'd like to address?
ISSUE-96
ifette: looks like the people on 96 aren't here
mez: note that none of these are stopping the FPWD
ifette: all the emails seemed to be caused by whether or not the
should/may is applied to primary or secondary
mez: good point
johnath: i had said may for both, but may in primary and should in
secondary seems good
... right now it feels like there's nothing there except what might be
there so maybe we shouldn't impose it on primary chrome but every
browser has secondary info, which right now is a hex field, it'd be
sensible to put a 'should' display for secondary
... may for primary
phb: i second that
... in terms of getting browser support, get it in secondary chrome,
first i want the phishing targets to get the logo into the cert, and
then we need it displayed, the should be secondary is a good migration
path
... placing it in primary at the user's discretion would be good too
<tlr> all issues from the draft are now in tracker; will edit them out
of the document
phb: in the firefox extension, the logotype shows up in the dockable
toolbar
yngve: adding to phb about cellphones -- opera device customers are
very conscious about what the real estate is used for and want minimum
space taken from the pages
phb: but because of the form factor on a cell phone, phishing is
extremely tough
... most folks won't enter a lot of data
mikem: so the x.509 standards are defined for logotypes, i'd rather
take a logotype over a favicon anyday
johnath: there isn't any higher validation for logotypes
mikem: we should give a comment to the cab forum about the process for
logotype acceptance, shouldn't be too similar
phb: i raised the issue of logotypes at the cab forum, i think
logotypes should be in an ev cert, it's not true to say there aren't
any rules, the second question is should the can forum call out the
logotype piece and say -- you have to treat the subject logo with the
same diligence as the subject name
... if you add that criteria, and you have a complete set of
requirements
hal: phb raised the issue of whether users should be able to
reconfigure their primary chrome
... i'll raise it as an issue
ifette: i'm wondering if we're restricting users from changing their
chrome
phb: i just want to point out that when this was raised earlier we need
a way for users to get back to the shipped config
mez: so on issue 96, i'm hearing we have agreement on about should for
secondary, may for primary
mikem: i reluctantly agreed for mobile browsers
mez: mikem likes should and should
hal: plus 1 to should/should
ifette: so screen real estate is always a constraint, i don't think we
should say use x number of pixels for something that hasn't been
standardized or deployed
... but that doesn't take up space in primary chrome
phb: i'm very reluctant to make a proposal that goes beyond what the
browser vendors are willing to take
... i don't think this will be final fixed forever, this will be
revised, so when value is demonstrated, it might become standard
<tlr> to create new issues, go here:
[38]http://www.w3.org/2006/WSC/track/issues/new
phb: we do not have from cab forum a set of criteria for evaluating,
but we do have a set of criteria for evaluating certs
... so there are constraints we have to meet, they aren't explicit, but
the audit process includes them, the lack of a cab forum document isn't
relevant
tyler: another outcome, we might find that passive indicators, so we
might not need a should or must, but another way to use the logotype
... creating a passive chrome indicator isn't the only thing we can do
mez: so i hear secondary is a should, and primary is still in
discussion
... let's leave it there for the FPWD
mikem: would anyone vote differently if it was a logotype linked to an
ev
some: no ...
ifette: my concern wasn't with the quality of the logotype or the ca
process, i'm more concerned with the value of displaying the logotype
mez: IOW, ian and tyler are in violent agreement
<tlr>
[39]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
tlr: i want to go back to what phb said, the current draft leaves open
the should/may issue, i didn't hear anyone saying there are changes
needed
phb: my point about ev is that it depends on how concrete you want the
spec to be
... should we allow room for other groups that offer high assurance
certs
mez: are we done with issue 96? ... yes
... and now issue 97
ISSUE-97 / ISSUE-102
tlr: we've covered that too
mez: where are we?
tlr: what is our notion of an ev or ev-like cert
... to understand 97 we need to look at issue 102
johnath: one way to approach is to say user agents already make
decisions about trusting cert anchors, so we can say anything the
browsers trusts just is
... do we want to draw a line in the sand about x amount of work
needing to be done to verify things
... we should either point to the cab forum as an exemplar, or we
should draw our own line
yngve: a point about what the browser trusts, you can add roots, the
question is whether or not this is something where the vendor has an
additional list that is a subset of the roots that they extend some
higher trust to, like EV or something similar
hal: i want to raise this in a question, can the user configure their
browser so they had trusted ev and non-trusted ev
phb: IE7 doesn't allow the user to identify a root as an ev trust
anchor
... i believe there is some extension in the trust list, says this cert
can be used as ev if this is present
... the definition needs to be -- the point is it provides an assertion
as to the subject of the certificate has successfully passed an audited
authentication process
(tlr and phb dictating new content directly into the rec draft)
ifette: traditionally the decision has lied with browsers on which to
trust
... rephrase -- the decision in the default config is with the browser,
but the user can override the settings
... i don't see why this should be changed
... i also think the user or the enterprise configuring the workstation
should be able to change these
... we shouldn't take away this user ability
mikem: are we talking about logotypes?
ifette: i'm talking about certs in general
tlr: the definition shows there are levels of certs and there are
assumptions about the data in the certs, phb has put in the clause that
users must not be able to change the settings are part of a different
interaction -- don't ask them to make this decision or change their
settings within an idiot box
hal: i agree with ian in principle, which the current standard doesn't
match
... it seems there are restrictions on how the user can express their
trust policy
phb: we seem to have agreement that it's bad if the interface that
leads you to a selection box is a webpage (content provider)
... there are certainly use cases where you want to trust roots
determined by someone else
... must not have content directed user changes to settings
... but there should be the ability for someone to intentionally go in
and alter the settings
<ifette> +1 phb
phb: there should be two separate specs for this
getting better text from phb
real time edit taking place to text
mikem: i think we're conflating two things here, there are users
importing roots, then there are users changing the categories of their
roots
users importing roots is an attack vector today, but we have to allow
it
scribe: allowing the user to change the category of a non-ev to ev
... is no ok
tlr: +1 to phb about requesting this part, right now the root has a
dual purpose, a trust anchor and a middle xv that might come with a
policy, and within the issued cert you might have an additional
requirement for an ev root
... the other side to this, because the policy is vendor specific, to
make a root ev enabled you have to say the root is qualified and you
have to identify the policy OID
ifette: specifying a new policy OID that you use should be possible
johnath: we have the same thing were people want to add their own trust
certs, and they may want to extend the trust, so it shouldn't be
totally forbidden
hal: one, based on history, finding the right OID will be easier for an
attacked than the user, but the other thing, we can't lose the
requirement to be able to import a root
... as long as there's a way to say i trust this root but not to issue
evs
<Zakim> Mez, you wanted to say that reusing the term ev is probably
keeping us from seriously considering ian's point
mez: one thing i'm hearing between ian and mikem, ian and others are
treating the ev notion as a different level of trust abstraction, while
mike and some other are treating them as something very specific with
intentions and definitions, i think for us to seriously consider this
issue, we need to use terms that don't have other pre-existing
definitions
... if we want to separate from the cab definition let's not call them
EV
phb: let's not call them high assurance either
tlr: right now the text is set up so we can change to text easily once
we decide
mez: i think we're talking about certs that the user has deemed more
trustworthy than other roots
tlr: the distinction is that you can derive useful information from the
cert and it's useful when seen by the user instead of relying on some
other info that's being placed there by a low assurance ca
mez: that's not what i'm hearing from ian
... i hear the display is enough to convince the user
... the actual detailed info might not be important
tlr: anyway, what we need is something to put instead of EV
phb: augmented assurance
<tlr> ACTION: tlr to change EV to "augmented assurance" in editor's
draft [recorded in [40]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-313 - Change EV to \"augmented assurance\"
in editor's draft [on Thomas Roessler - due 2007-10-10].
mez: how are we doing with our notion of AA certs
ifette: at the end of the day i want the user to be able to configure
all the states for certs
mikem: what you don't want is a dialog that says 'you don't currently
trust this as EV, do you want to?'
... but you want there to be a different path to change this?
ifette: yes
hal: i don't the option to exist where the administrator can say
they're AA certs when they aren't
... and not even the CA calls them this
... if the cert didn't go through the right process, it shouldn't be
considered a AA
<ifette> ifette: I would be happy with the end user designating a root
certificate as being capable of issuing "AA" certificates, if CA
identified by that root certificate identifies a paritcular certificate
as being AA
<ifette> ifette: provided that it's not a part of some tangental
workflow etc, i.e. it should be hard to get to, designated ui, etc
mez: so, issue 102?
mikem: we're trying to decide if the cert had to be AA in order to
display a logotype, right?
mez: are we good on issue 102?
johnath: we made it more generic, im not sure we got anywhere
tlr: i think we're losing that this property is a property of the cert
and we're using a certain policy oid that is cert specific and
recognized by the browser
johnath: implementation detail
... doing it this way with ca specific policy oid
ifette: as long as we have language that a CA has the power to say a
cert is AA or not
phb: i would like to drop the dependency on OID
yngve: about section 4.3.1, i suggest it is changed to 'recognized by
the client or user agent as AA qualified' without mentioning a specific
mechanism
tlr: i hear, throw out the part about validiation?
more changes to rec doc
yay for lunchtime :)
mikem: wait, did we resolve issue 97
after lunch.
<ifette> As a formal note in writing:
<ifette> I will be leaving meeting early to catch a flight... if any
issues come up re: favicon
<ifette> I give my proxy vote to johnath
<ifette> mez:
[41]http://www.w3.org/2005/10/Process-20051014/policies#Votes
mez: issue 97
ISSUE-97
<Mez> [42]http://www.w3.org/2006/WSC/track/issues/97
johnath: proposes ...
tlr: refers to 5.1.2
<tlr>
[43]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
tlr: reading referred text
... regarding logotype
mez: discussion MAY or SHOULD
tyler: asking logos and certs for any other purposes
johnath: this is only a change to identity signal content
hal: logotype is better than favicon
<Mez> the chair acknowledges the proxy from the gentleman from Google
tyler: no restrictions
mez: yes, no restrictions
... editor closes the issue
ISSUE-98
<Mez> [44]http://www.w3.org/2006/WSC/track/issues/98
<tlr> Agreement in the room that current spec text does not preclude
use of logotypes (or even non-AA logotypes) outside the context of the
page info summary.
mez: next issue 98
... The PKIX logotype extension describes issuer, community, and
subject logotypes. Assuming that web user agents display some kind of
logotype, which one should be picked, and when?
... this issue came in the context of 5.1.2
... shall it be in a broader scope?
<Mez>
[45]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
mez: secondary chrome
ifette: a cert viewer should show all the contents
... of the cert
<tlr> ISSUE-97 is closed
hal: today nothing is displayed as a graphic
ifette: where is it going to be used?
... a page totally devoted to showing everything
... if it's a different page, the no idea
hal: cert may contain 0,1,2,3 of these logotypes
phb: important to have consistency .. the subject logo is more specific
... you can have multiple community logos
mez: more writing needed to encapsulate details?
hal: other opinions on logotypes?
mez: not part of this issue
phb: you can have multiple logos in different resolutinos
mez: secondary chrome ...
... no proposals for tracking logotypes and favicons
johnath: we are in issue 98
tlr: identity signal in 1:ary or 2:ary chrome ...
<luis_> mez: need to tweak the text before discussing further
hal: favicon is a ???ed logotype
johnath: logotype provide richer context
hal: logotype comes from CA and favicon comes from web server
mez: move on?
mez - pls. write the agreement
<tlr> ACTION: tlr to add language to 5.2, SHOULD list, to show any/all
logotypes available from AA certs [recorded in
[46]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-314 - to add language to 5.2, SHOULD list,
to show any/all logotypes available from AA certs [on Thomas Roessler -
due 2007-10-10].
<Mez> [47]http://www.w3.org/2006/WSC/track/issues/99
ISSUE-99
mez: When the identity signal includes information from X.509
certificates, what fields need to go into the identity signal?
johnath: all CA fill the CA part quite well
... what to do with extra information
... people can pull needed information from the cert
tlr: is CA practices harmonized so we can rely on them?
... is there a need to define which information is needed for the
various use cases?
... should that be unspecified
johnath: we don't display Subject Org, but we display domain
<ifette> ifette: bye all, time to head to airport
tlr: Firefox has a non normative proposal
yngve: putting a lot of information in secondary chrome ...waiting for
EV to be active
... similar to Firefox
... in the primary chrome the org name available in the cert
tlr: both FF and Opera trust the CA for the org name
... summarizes which fields can be extracted
... CN, ON
phb: the issues logo is already there
tlr: to take an action
<tlr> ACTION: tlr to add language to 5.1.2 to display info as
follows:if not AA, then domain name info from CN or subjectAltName; if
AA, then Organization attribute from subject; always: organization
attribute from issuer; close ISSUE-99 [recorded in
[48]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-316 - Add language to 5.1.2 to display
info as follows:if not AA, then domain name info from CN or
subjectAltName; if AA, then Organization attribute from subject;
always: organization attribute from issuer; close ISSUE-99 [on Thomas
Roessler - due 2007-10-10].
<Mez> [49]http://www.w3.org/2006/WSC/track/issues/103
mez: next issue 103
ISSUE-103
mez: Assuming that self-signed certificates are treated as pure
containers, what should the treatment be for unknown CAs?
tlr: summarizing the issue ...
tyler: how does this affect the key management part
phb - pls. summarize your comment. I lost WLAN
tyler: i want to ensure that i'm talking to the same entity i was
talking to
tlr: related to PII bar where you establish a relationship with an
entity that has some secret
tyler: in my case i'm binding a secret to a key
... while in the other case it's a binding key-hostname
... add text regarding the probation time
tlr: how does PII bar relates to TLS errors?
... or should that be limited to data entry ceremonies
... leave it as an open item in the draft. There is some inconsistency
tyler: there is some inconsistencies to solve in the FPWD
johnath: to create an action
... is there a fundamental difference?
tyler: "only legitimate sites use expired certs"
johnath: raising the same question again. Is there a fundamental
difference?
<johnath> ACTION: tlr to note the open discussion about how PII notions
of cert-handling fold into the rest of the document, particularly
around self-signed certs and KCM [recorded in
[50]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-317 - Note the open discussion about how
PII notions of cert-handling fold into the rest of the document,
particularly around self-signed certs and KCM [on Thomas Roessler - due
2007-10-10].
luis: some CA in desktop browsers are not found in phones
tlr: it's a different use case.
tyler: any setup that we can make for desktops would not fit cell
phones
tlr: needed some material that some validation is needed
johnath: concur
hal: the user should always be able to find out more in 2:ary chrome
tyler: In Dublin we discussed that some cases no warning is needed for
some SSC use cases
tlr: is there a user interaction that fullfill both requirements?
... the current dialog is not useful at all
... we don't know yet how to solve this
... there is
... providing an example with redirection with URL and secret to site
...
yngve: ... doesn't agree
(quite detailed discussion on methods and artifacts)
(for handling sessions)
tlr: what's the data source?
<Mike> leaving soon for my 5pm flight also
<Mez> tx Mike
tlr: starting from a given security level
... there will be a TAG session
... is that an open session?
... there is a TAG session on passwords in the clear
... issue is URL containing passwords
... summarizing ...
<Audian> ol
<Audian> ola
tlr: use additional information to deduce CA validity, e.g. OCSP
phb: revoking the cert doesn't necessarily revoke the key
tyler: gaves example with a compromised site
... where key needs to be revoked
yngve: OCSP has a "key compromise" field
tyler: an attacker issues a SSC with a compromised key
... whoever has a previous SA with that key would trust the SSC
tlr: attacker can attempt to get a new cert from another CA (?)
... why do you (Verisign) revoke a cert with a wrong name?
phb: many reasons
yngve: you are paying for one cert
mez: break
<Mike> ciao
mez: break until 3 p.m
ISSUE-104
<Mez> [51]http://www.w3.org/2006/WSC/track/issues/104
It feels like we need a sentence or two somewhere that says
that the content of certificates may not be trusted, and that
untrusted and trusted certificate content MUST NOT be mixed when
displayed to users. Some of that is in the last sentence of 4.3.7
[1], but I don't think it's even near enough.
tlr: the UA should know what is trusted
mez: are we talking about certs at various levels of trust?
<Zakim> johnath, you wanted to disambiguate
johnath: do users need to be informed about some certs being more
trusted than others
tyler: when u create a bookmark, the name of the bookmarkmay be chosen
by the attack via the HTML TITLE element
jonhnath: a new section is needed unser section 7
tlr: proposal for language in section 7
johnath: to give an action
<johnath> ACTION: tlr to draft a new subsection to section 7 discussing
the mixing of trusted/untrusted information in the UI [recorded in
[52]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-318 - Draft a new subsection to section 7
discussing the mixing of trusted/untrusted information in the UI [on
Thomas Roessler - due 2007-10-10].
<Mez> [53]http://www.w3.org/2006/WSC/track/issues/105
ISSUE-105
scribe: Whether or not the client keeps state that can be played back
to the Web site is probably relevant security context information.
Talking about cookie state display might be useful.
tyler: the user shouldn't get the impression he is being tracked
mez: any text saying displaying this info?
<Mez>
[54]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
mez: nothing about cookies
... don't see compelling reason to address this issue
tyler: for a user is good to know if a site is storing persistent
information
... the UI should notify about making (wrong) dangerous assumptions
... something that can be tested
... e.g. as Mozilla does today
... any studies?
maritzaj: Serge should know
yngve: it is possible to see what information is sent to the web site
... there is a cookie panel to provide preferences for sites
tlr: adding some text to section 5 on cookies
hal: objecting to enumerated cases
... being more specific
<tlr> ACTION: tlr to add text in section 5 to note that "no cookies =>
no tracking" doesn't hold, re ISSUE-105 [recorded in
[55]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-319 - Add text in section 5 to note that
\"no cookies => no tracking\" doesn't hold, re ISSUE-105 [on Thomas
Roessler - due 2007-10-10].
ISSUE-106
<Mez> [56]http://www.w3.org/2006/WSC/track/issues/106
"If we are react to certs that don't match a URL then we need a
well defined matching rule"
mez: do not discuss since Steve is not here
tyler: hasn't that been defined by someone else?
yngve: there is an RFC on how to match
... RFC 2818 (?) ...
hal: section 3.1. specifies that
... what's the issue?
mez: that's why we need Steven
ISSUE-107
<Mez> [57]http://www.w3.org/2006/WSC/track/issues/107
"Per ACTION-289, I've updated the editor's draft to call out explicitly
that we do not consider it a "change of security level" if a form on an
HTTPS site is submitted by plain HTTP."
tyler: what does it mean "change of security level"?
yngve: concern about passwords not protected
tlr: isn't this an authoring practice?
tyler: doesn't meet our goal of helping users to make trust decisions
mez: if sites want to be more trustworthy they have to follow this
johnath: all current browsers already warn about this
yngve: there are POST case submissions from HTTP to HTTPS
... sent from applets. Opera generates errors
... other browsers give forms warnings
... serious sites should not provoke security warning/errors
mez: >> best practices
<Mez> for authors
yngve: best approach today. Later let UA handle that.
... two-phase approach
johnath: go to https:/www.verisign.com
... somehow a POST message generates a warning
... it's very hard to warn more precisely
... it's worse not to warn at all
yngve: secure flashapplet was used to submit unsecure POST
... no browser warned, except Opera
... it was a missconfiguration of the site
... other cases where by accident mixing HTTPS with HTTP
tlr: is there space for authoring practice?
... also, browser making a warning?
and, finally, error h...andling
maritzaj: related to the SSL upcoming study
... if any messages are relevant to the user
johnath: shouldn't be warning all the time when it's benign
yngve: is there a backup to authoring guidelines
mez: the tools
tlr: the UA adapting to the user mode
maritzaj: feed to Tim on the profiles Browser lockdown?
johnath: the Firefox web development kit is useful to validate many
things
... could be integrated into tools
ISSUE-108
<Mez> [58]http://www.w3.org/2006/WSC/track/issues/108
<tlr> ACTION: tlr to add authoring BP re HTTPS -> HTTP submits
(issue-107) [recorded in [59]http://www.w3.org/2007/10/03-wsc-irc]
<trackbot-ng> Created ACTION-320 - Add authoring BP re HTTPS -> HTTP
submits (issue-107) [on Thomas Roessler - due 2007-10-10].
<scribe> ... ongoing study with thousands of users on SSL warnings
unknown was available on-line PDF, but no longer
... 30% were confused. 1/3 - thought misconfiguration ....
... others thought were under attack
<johnath> [60]http://venafi.com/web_form_encryptionstudy.html
... they had a convincing study to sell professional services for
managing certs ...
(lost connection....)
"Actual implementation work currently assumes that favicons remain in
primary chrome, and might (e.g. for firefox) be used as the widget that
users interact with to raise an identity signal. The spec currently
says that favicons are a positively bad idea.
This sounds like we might have new information to consider on this
point, or at least need to understand the reasons for the divergence"
tlr: there is some information leaking to the web site about the mental
model of the user
(sound like exformation)
johnath: on issue 110, being specific is OK. Generalizing is a problem.
yngve: looks like we need use cases
mez: suggest to end this part of the agenda
... wrapping the meeting
Last Call of wsc-usecases
tlr: anything standing for the last call?
mez: recaping on use cases that tyler has to work on
tlr: refers to email posted by mez
<tlr>
[61]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0012.html
yngve: ... at 7.23 local time
mez: last call for use cases is left for mechanics
tlr: showing process for last call
... review period should last at least 3 weeks
... could be longer
... if technically complex or significant external dependencies
... on PII bar. There are many privacy surrounding issues ...
... since personal identfiable data is being handled
... rather than using PII bar, better use personal data entry
mez: towards FPWD
... recap on various APs
... meeting over
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [62]scribe.perl version 1.128
([63]CVS log)
$Date: 2007/10/25 09:32:04 $
References
1. http://www.w3.org/
2. http://www.w3.org/2007/10/03-wsc-irc
3. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0000.html
4. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#agenda
5. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#item01
6. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#Page
7. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#item02
8. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#item03
9. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#item04
10. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#Review
11. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-96
12. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-97
13. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#item05
14. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-98
15. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#item06
16. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-103
17. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-104
18. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-105
19. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-106
20. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-107
21. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#ISSUE-108
22. file://localhost/home/roessler/W3C/WWW/2007/10/03-wsc-minutes.html#Last
23. http://www.w3.org/2006/WSC/track/issues/83
24. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0012.html
25. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0009.html
26. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0011.html
27. http://www.w3.org/2006/WSC/track/actions/307
28. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0013.html
29. http://www.bartleby.com/165/1.html
30. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Overview
31. http://www.w3.org/2005/10/Process-20051014/process.html#first-wd
32. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0014.html
33. http://www.w3.org/2007/10/03-wsc-irc
34. http://www.w3.org/2006/WSC/track/products/4
35. http://www.w3.org/2006/WSC/track/products/4
36. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
37. http://www.w3.org/2006/WSC/track/products/4
38. http://www.w3.org/2006/WSC/track/issues/new
39. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
40. http://www.w3.org/2007/10/03-wsc-irc
41. http://www.w3.org/2005/10/Process-20051014/policies#Votes
42. http://www.w3.org/2006/WSC/track/issues/97
43. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
44. http://www.w3.org/2006/WSC/track/issues/98
45. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
46. http://www.w3.org/2007/10/03-wsc-irc
47. http://www.w3.org/2006/WSC/track/issues/99
48. http://www.w3.org/2007/10/03-wsc-irc
49. http://www.w3.org/2006/WSC/track/issues/103
50. http://www.w3.org/2007/10/03-wsc-irc
51. http://www.w3.org/2006/WSC/track/issues/104
52. http://www.w3.org/2007/10/03-wsc-irc
53. http://www.w3.org/2006/WSC/track/issues/105
54. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
55. http://www.w3.org/2007/10/03-wsc-irc
56. http://www.w3.org/2006/WSC/track/issues/106
57. http://www.w3.org/2006/WSC/track/issues/107
58. http://www.w3.org/2006/WSC/track/issues/108
59. http://www.w3.org/2007/10/03-wsc-irc
60. http://venafi.com/web_form_encryptionstudy.html
61. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0012.html
62. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
63. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Thursday, 25 October 2007 09:35:20 UTC