Meeting record: WSC WG f2f 2007-10-03

Minutes from our meeting on 2007-10-03 were approved and are
available online here:


A text version is included below the .signature.

Thomas Roessler, W3C  <>


                Web Security Context Working Group face-to-face

3 Oct 2007

   See also: [2]IRC log, [3]Agenda


          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

          Bill Doyle, Tony Nadalin, Dan Schutzer


          asaldhan, maritzaj, luis


     * [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


   <Mez> [23]


   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


   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: 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]

   Mez: newly bashed agenda item - ACTION-307
   ... page security score


   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

   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]

   <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

   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

   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]

overview section of rec-track document

   Mez: agenda item: section item from tyler

   ifette: the rec draft is present in the process document


   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: concern as a chair is that it takes a lot of time to reply to
   ... 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
   ... 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

   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

   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

   <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

   <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

   <Mez> [34]

   Mez: we will go over the issues in the document that editors feel that
   we will make progress on

   <tlr> [35]

   <Mez> [36] 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]

   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?


   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
   ... 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

   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

   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

   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:

   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

   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
   ... let's leave it there for the FPWD

   mikem: would anyone vote differently if it was a logotype linked to an

   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: 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

   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

   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
   ... 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
   ... 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
   ... 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

   users importing roots is an attack vector today, but we have to allow

   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

   <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
   ... if we want to separate from the cab definition let's not call them

   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]]

   <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

   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:

   mez: issue 97


   <Mez> [42]

   johnath: proposes ...

   tlr: refers to 5.1.2


   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


   <Mez> [44]

   <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: 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

   <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]


   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

   <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]

   mez: next 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

   <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

   <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

   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

   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


   <Mez> [51]

   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

   <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]


   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: 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
   ... 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

   <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].


   <Mez> [56]

   "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


   <Mez> [57]

   "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:/
   ... 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
   ... could be integrated into tools


   <Mez> [58]

   <tlr> ACTION: tlr to add authoring BP re HTTPS -> HTTP submits
   (issue-107) [recorded in [59]]

   <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]

   ... 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


   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 $


   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

Thomas Roessler, W3C  <>

Received on Thursday, 25 October 2007 09:35:20 UTC