W3C home > Mailing lists > Public > public-wsc-wg@w3.org > February 2008

Meeting record: WSC WG face-to-face 2008-02-06

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 27 Feb 2008 15:17:31 +0100
To: WSC WG <public-wsc-wg@w3.org>
Message-ID: <20080227141731.GA92109@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-02-06 were approved and are
available online here:


A text version is included below the .signature.

Thomas Roessler, W3C  <tlr@w3.org>


            Web Security Context Working Group Face-to-Face Meeting

06 Feb 2008

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


          Thomas Roessler, Mary Ellen Zurko, Serge Egelman, Yngve
          Pettersen, Rachna Dhamija, Tyler Close, Phillip Hallam-Baker,
          Bill Doyle, Maritza Johnson, Hal Lockhart, Ian Fette

          Tim Hahn, Stephen Farrell, Anil Saldhana, Johnathan Nightingale,
          Dan Schutzer, Mike Beltzner, Luis Barriga


          yngve, PHB, tyler, maritzaj, serge


     * [4]Topics
         1. [5]5.1.3 Augmented Assurance Certificates
         2. [6]5.1.4 Self-signed Certificates
         3. [7]5.1.6 Logotype Certificates
         4. [8]5.2 Types of TLS
         5. [9]5.3 Change of security level
         6. [10]5.3.2 Redirection chains
         7. [11]Section 6
         8. [12]page security score
         9. [13]break
        10. [14]6.4 Error Handling and Signalling
        11. [15]6.4.2 Handling certain man in the middle attacks
        12. [16]Section 7
        13. [17]8. Robustness
        14. [18]logistics
     * [19]Summary of Action Items

   <trackbot-ng> Date: 06 February 2008

   <maritzaj> Dear Friend

   <maritzaj> Please make a hotel reservation for me and tell me the
   nearest airport to you and await for my arrival.This is a transaction
   of $11m (eleven million USD) from a genuine source and duly
   certified.It is my inheritance with full legal right.

   <maritzaj> I trust that with you I will be able to invest on the right
   business to maximize profit and grow my money.I am not resident in your
   country,pls be my partner,receive me well and 20% of the total fund is
   for you.Trust me.

   <Mez> hi, we'll call in

   <Mez> who's aaaa?


   <ifette_GOOG> Has the meeting started?

   <serge> yeah, you're late

   <serge> wouldn't want to be in bad standing...

   <ifette_GOOG> lol

   <ifette_GOOG> you're having fun Serge, aren't you?

   <serge> I'll take what I can get

   <Mez> gm ian

   <ifette_GOOG> gm mez

   <Mez> how's santa monica?

   <ifette_GOOG> Santa Monica is quite beautiful

   <serge> so then why the hell are you calling in?

   <Mez> ian, always gracious....

   <tlr> ScribeNick: yngve

5.1.3 Augmented Assurance Certificates

   mez: impression from yesterday, did not put any of the sections to bed
   ... use rest of day to figure out what can make it to last call


   section 5.1.3

   <Mez> Implementations MUST NOT use Relaxed Path Validation if the trust
   anchor is AA-qualified.

   <Mez> Web user agents MUST establish that a trust anchor is
   [Definition: AA-qualified ] through some out of band mehcanism
   consistent with the relevant underlying augmented assurance

   <Mez> Marking a trust anchor as AA-qualified is a security-critical
   step and most often will involve the use of some application-specific
   out-of-band mechanism.

   serge: adding roots, setting EV status in IE?

   phb: user can add roots, may set EV status

   <Mez> gm Audian

   <Mez> come on by! :-)

   <Audian> will see....can't be until later in the day

   <PHB> OK problem with the definition here, the must should not be in
   the definition because it is a definition

   <Audian> but I'll keep my eye on 'yous' guys via IRC

   <PHB> A certi is augmented assurance if and only if it has been
   validated with strong path validation, chains up to marked root

   <PHB> The MUST needs to go in a statement to the effect that browsers
   MUST NOT present a non-Augmented Assurance cert using the distinguished
   presentation reserved for AA

   <tlr> ACTION: phb to write replacement text for 5.1.3 [recorded in

   <trackbot-ng> Created ACTION-387 - Write replacement text for 5.1.3 [on
   Phillip Hallam-Baker - due 2008-02-13].

5.1.4 Self-signed Certificates

   <Mez> The same SSC SHOULD NOT be considered proven for more than one
   web site.

   rachna: Are words like probation period defined in the section?

   mez: yes

   tlr: two ways to read: only one server per certificates, or 2) being
   proved is scoped for a single server, seeing it again for another host
   restarts probation period for that particular host

   mez: section 5.1.4 connected to sec 5.1.5

   <discussion about meaning of 5.1.5 SSC language>

   phb: what about a SSC on a host with multiple SSL servers?

   tlr: probation for each hostname:port and SSC combination,

   hal: SSC language contradicts validation languge earlier in the section

   tlr: language/defintions may be improved

   hal: want some consistency in the section

   tlr: language tries to capture both ordinary certificates and the
   exceptions, but is confusing and must be improved

   tyler: probation period is new, why not ask user like SSH does?

   <hal> probation period is actually number of interactions

   <rachna> issue: 5.1.4 definition of "probation period" does not specify
   whether it is time period, number of interactions, user prompting and
   when user is prompted

   ifette: when does the clock start ticking? e.g. inline secure image in
   a otherwise OK page

   <ifette_SMO> I think the issue is not what browsers currently have the
   ability to do, but what we want them to do (obviously provided that
   it's feasible). We don't really seem to have an answer to what we want
   them to do

   yngve: UAs have varioius ability to remember user OK of problem certs.
   Opera 9.50 can accept until expired and in periods of 90 days after

   ifette: what does visiting X number of times means, e.g. when a inline
   image is used?

   <rachna> tyler: 5.1.4 algorithm for what constitutes probation period
   in this section is not fully baked. Hal agrees this working group
   should not specify algorithm

   tyler: first time may be best time to accept

   tlr: first time will pin the cert and domain name

   ifette: use case?

   <Mez> ian: what's the use case of waiting for a number of accesses
   being the right and desirable thing to do?

   <tlr> You access [23]https://... from behind a captive portal.

   rachna: what happens in MITM situations?

   tlr: warning would be displayed

   hal: can't think of any cases were probation is useful

   mez: put probation on hold, but use hostname binding

   <Mez> The same SSC SHOULD NOT be considered proven for more than one
   web site.

   <ifette_SMO> ACTION: tlr to update definition of 5.1.4 [recorded in

   <trackbot-ng> Created ACTION-388 - Update definition of 5.1.4 [on
   Thomas Roessler - due 2008-02-13].

   <tlr> Change 5.1.4 to drop explicit probation period.

   <Mez> The period starting from the time when a particular SSC and web
   site are first seen by a Web user agent, until that SSC and web site
   combination is considered (by the Web user agent) to be sufficiently
   secure is the [Definition: "probation period."]

   <Mez> drop that

   <Mez> drop for longer than the probation period.]

   hal: three cases: Ordinary, AAC, proven. Are all equally good?

   serge: is there an user interaction for SSC?

   <yngve> yes

   serge: have problem with mandating user interaction, should mandate how
   it should look so that it is different from worse errors

   <rachna> if user is going to agree to accept a SSC cert or to trust a
   SSC, we should specify how errors or consent is obtained

   <rachna> hal: yes-an OCSP error for a revoked cert should not generate
   the same error as a SSC cert

   tlr: drop down passive indicator offering possibility to pin SSC to

   <tlr> Memo to self: Add material to 5.1.4 about interaction for
   accepting certificates.

   <tlr> (Part of ACTION-338)


   <rachna> how many categories of certs do we have? EV 1) augmented
   assurance 2) validated certs that chain up to a trust root 3) SSC that
   are proven 4) blah 5) blah 6) no TLS

   <rachna> hal: where does relaxed path validation fit?

   <ifette_SMO> Please, no more categories

   <ifette_SMO> this is hard enough to understand as is...

   <tlr> 2 and 3 are the same

   <ifette_SMO> are 4 and 5 equivalent?

   <tlr> 4 and 5 is the same; innocuous validation problems / SSCs

   <tlr> 6 no TLS

   <tlr> 4-6 have essentially same interaction

   <serge> I don't think we should distinguish between "proven" and
   "unproven" SSCs

   <rachna> hal's summary: we have 3 categories 1) AAC EV 2) fully checked
   TLS 3) everything else

   <rachna> hal: and user can decide to move things in third category into
   2nd category...

   yngve: with no interaction SSC user may still trust https part of the


   <rachna> tlr: two classes of errors 1) path validation that failed on
   the way to root 2) path validation to unknown root (equivalent to SSC)

   serge: need to be distinction between unverified cert and cert errors
   like revoked and expired

   tlr: some errors are innocious
   ... main non-fatal errors in basic validation is expiration and
   ... expiration is innocious when revocation is not checked

   phb: no reason to distinguish, either a chain is valid or not
   ... attack:phishing gang get certificate, waits until it is expired,
   then starts using it, new alg will not check expiration

   tlr: summary what cert problems should be treated as innocius?

   tyler: problem when previously accessed full cert server changes to use
   SSC (e.g due to attack)

   tlr: change of security history errors handle that

   <hal> PKIX path validation: [27]http://www.ietf.org/rfc/rfc3280.txt -
   section 6.1

   <yngve> New cert remembering functionality in Opera 9.50:

   MEZ: The relationship between change 'o security level and the various
   categories of certs we discussed

   takes us back to 5.3 again

   Serge: did we agree on anything?

   Rachna: ... we agreed to clarify sections 5.1.???

   <ifette_SMO> the beach is soooooo nice...

   <serge> ifette_SMO: you're still in LA, so I'm not particularly jealous

   tlr: what do we want to say on non fatal errors

   <ifette_SMO> I'm in Santa Monica, not LA

   <serge> same thing

   TLR: can live iwth if trust root is unknown then ...
   ... That then means that Error handling for expired certs may become
   sharpetr than today

   serge: creating different classes of error messages, seems that there
   are some errors more severe than others

   get consensus on there should be various levels of errors

   Rachna: suggests errors that should result in user notification and
   those that should not

   serge: interested in warnings, there is actually n ANSI standard for

   Mez: should we classify them according to the type of advice?

   Serge: yes absolutely

   Mez: do we have a place to hang this already?

   serge: what I would like to see is a unified browser errors

   Mez: can you write it up

   <serge> [29]http://www.safetysign.com/CLDR.asp?PG=ANSIStandards4

   <scribe> ACTION: Serge to write up error levels [recorded in

   <trackbot-ng> Created ACTION-389 - Write up error levels [on Serge
   Egelman - due 2008-02-13].

   <rachna> phil: distinguish things that aren't worth mentioning, things
   that inform and things that require a warning (e.g. attacks or where
   use is at risk)

   yngve: have not seen use of these codes for revocation reasons much,
   main one was out of business

   <Zakim> Thomas, you wanted to ask a practical question

   tlr: we have an item in 5.1 that might merge into 5.4. My action items
   stall on Serge completing ACTION-389.

   serge: definitions we need to have a section then map it into the
   various sections

   Rachna: I think we agree

   <yngve> revocation: [31]http://my.opera.com/yngve/blog/show.dml/508407

   Ifette: might not agree on the fine detAils

   serge: notice, purely informational should not popup and annoy the user
   ... there are multiple levels, what you provide in the various levels..

   tlr: and please look at 6.4 while you are doing that

   serge: m paper on phishing warnoings aout to go to print

   tlr: when do I time out on you

   rachna: just do it right now

   tlr: end of next week or the week after next
   ... will time out on you on monday

   <ifette_SMO> 2/18 is a holiday

   serge ok

   <ifette_SMO> presidents day

5.1.6 Logotype Certificates

   Mez: on to 5.1.6

   Have some definitions but only one line of normative language

   <Mez> SSCs MUST NOT be considered logotype certificates.

   tlr: can put it in 5.1.6 ot 6.? where it goes can be left to the editor

   need to be consistent - do not allow SSC and require EV should be in
   the same place

   hal: we don't use these definitions

   mez: yes we do, so there, spell community correctly

   hal: only use of community is in this waffly statement
   ... we don't seem to make use of the distinction

   6.1.2 we might

   RESOLVED: TLR to move pieces about and PHB to check result

   <Mez> serge, you have noticed we have consulted WAI on a number of
   handicapped accessibility issues, right?

   rachna: is there any must?

5.2 Types of TLS

   mez: definitions get used later and become more interesting
   ... not going to do 5.2?

   tlr: probably useful to sumarize for a moment...
   ... call something strongly protected in certain circs. and weakly
   protected otherwise..

   rachna: this is qualifications in the second bucket...

   tlr: two top buckets: AA, strong but not AA and a bottom bucket with
   errors, compromises etc.

   tlr have buckets for certs and for how they are used

   tlr: can have a fine EV cert but a weak algorithm

   hal: we got hung up on some group of wise men should decide what is

   Mez: someone said SSL desired by specified HTTPS by typing it in

   TLR: have that as a separate definition because there might be cases
   when someone was following a link but came up on a less than secure
   ... don't think we need this now we have knifed no interaction certs

   PHB: aren't SSC effectively the same?

   TLR: gets close but not so much

   MEZ: ok that is it for 5.2

5.3 Change of security level

   TLR: hard error, cert validates but path does not match,

   HAL: had a problem

   MEZ: it was with the name change of security level

   hal: change of security level can happen even without an error
   ... should decide how we are going to use this definition and then come

   mez: 5.3.1
   ... these look like what Serge?

   Rachna: this is validated certificate in that category

   TLR: we have a cert for which we know the trust root therefore
   ... know the trust root either because we know the root, its a known CA
   ... signature fails, URI is wrong, whatever..
   ... we believe that trust root is valid but path validation fails

   Rachna: why not certificate error

   TLR: happy to change

   5.3 renamed to error conditions are we done??

   PHB and we come back to change in security level discussion

5.3.2 Redirection chains

   Mez: 5.3.2

   <tlr> ifette, we're in 5.3.2

   ifette: redirection chains, what concerns me is third bullet: I am on
   some shopping site, get redirected to verified by visa. this should not
   be a problem, we should not throw up warnings here.

   <serge> do we actually have data on how widespread this is?

   ifette: regardless of if it is a good practice it is growing if we say
   throw up warnings, it is not going to fly

   tlr: the conditions are AND ed, all must apply
   ... the point is that if I am in a TLs environment, I have a
   redirection path to a possible man in the middle attack

   ifette: we need to make the spec clearer

   <scribe> ACTION: tlr to make it so [recorded in

   <trackbot-ng> Created ACTION-390 - Make it so [on Thomas Roessler - due

   yngve: does different web site also include different port on the same
   server name: in my opinion it should

   hal: I think it depends on whether it is a regular cert or a promoted
   cert or an ev cert

   rachna promoted cert is a good term

   tlr: i like promoted as well
   ... don't care which way we go would like input

   hal: don't normally use port

   yngve: connection is to given host and port

   tlr: for self signed certs pin them to a specific port, for domain and
   EV we don't
   ... OK

   rachna: we going to remove the change of level stuff throughout 5.3.2

   mez: yes

   tlr: you are an SSL site, you go to a redirect through five HTTP sites
   to a new SSL site so that the user can be redirected to a site of the
   attacker's choosing

   tyler: the indicators only reflect the curent state, not how you got

   rachna: now I know the change of security levels relevance

   mez: don't have worked out this category of errors

   rachna: I don't even know if this is an error

   mez: this is the least of them, the category error (as opposed to
   ... need a name for this indicator, call it a Fred.
   ... strongest is going to be Dont do that, middle thatmay be fine,
   lowest blinking something

   ifette: are we fine that the lowest level is going to be noted, do we
   tell the user about te indirect reditrect

   mez: since we don't have a lotta concrete detail

   hal: we should withdole judgement until we have something

   ifette: didn't want us to assume that all levels are woth notification

   tyler: this chan of redirect seems to have the same seto of issues as
   the page with included insecure items.

   bill: if you are on data that you expect to be https and you find you
   are not that is an issue

   yngve: if an attacker changes the url in mid flight, changinmg content
   inside a page can change the way the content is protected but not the
   action made by the page.
   ... depends on how the site is defined ...
   .... opera is treating both the same ...

   ifette: one more thing that might come up, might be the case that I
   want to protect a logon page on HTTPS but don't want to protect
   everything else. Under this we create an error.

   yngve: you heard the side-jacking discussion

   ifette: ok will read the minutes when they are out
   ... just wanted to raise the fact that I may have an issue

   tlr: I think we are clarified I am not sure that we are in agreement

   yngve: looks like it might need more work and it is not yet ready

   tlr: concrete proposals?

   tyler: should have a concrete proposal for how we handle mixed content.

   phb: mixed content really really sucks

   yngve: IE7 tried to prohibit mixed content, could not do that,

   <ifette_SMO> I read the minutes from yesterday around 23:00 and I'm
   still very unsatisfied

   yngve: issue was javascript, links to google analytics.
   ... that caused Microsoft to back off before IE7. ...

   rachnado not want to cause disincentive to use TLS

   <ifette_SMO> I do not agree with the 9.3 replacement text

   tyler: before people wanted to use SSC and just not present the
   security indicators

   yngve: that is what most browsers do today

   rachna: raises LUNCH!!!!!

   Mez: is thisagoodstoppintime

   Mez break for 1hr to 1:15

   <Mez> ian, if you like, you can also log an issue related to the email
   you'll send (or vice versa). that being the way to be sure nothing ever
   gets lost

   <ifette_SMO> grabbing food, back in a sec

   <ifette_SMO> back


   <serge> ScribeNick: serge

   tlr: it's specified it applies to both <reads...mumble...mumble>

   tyler: if you end on an HTTP page, a change of level has occurred?
   ... regardless of redirects you get an error here

   ifette_SMO: worried about common use case warnings

   yngve: should include meta-refresh, etc.

   tyler: do we agree this should be discouraged?
   ... to deal with errors on good SSL sites, raise the error earlier
   ... on the TLS, go to HTTP, nothing happens, stop when it tries to go
   to TLS

   yngve: websites will find out, and then find it's not good and redesign

   Mez: why is this insecure?

   bill-d: attack happens when page was downgraded
   ... but we're talking about wwarning on the re-upgrade

   Mez: sounds like this ends up in the middle vcategory of warning?

   yngve: or separate category for augmented to non-augmented

   tyler: wwhy not just break the redirect?

   ifette_SMO: get on the queue
   ... if we break it, people will switch browsers

   rachna: what about the converse? HTTP->TLS->HTTP?

   yngve: there should be a link instead of a redirect
   ... from HTTP to TLS

   ifette_SMO: happens all the time

   yngve: what about EV->TLS->EV?

   ifette_SMO: but there's no risk of MITM

   yngve: but there's no assurance

   tlr: I can argue both ways

   ifette_SMO: are we tabling?

   Mez: speak now or forever hold your peace

   tlr: TLS continuity, indicator for site changing in the future
   ... 1) is the part abotu strong to weak the same?
   ... 2) is the part about <something something> the same?
   ... 3) augmented assurance

   <Zakim> ifette_SMO, you wanted to complain about EV -> TLS

   rachna: go from TLS to no TLS..

   <Mez> issue-114 is likely to map to the middle notification category to
   be produced by serge

   <Zakim> ifette_SMO, you wanted to give information I couldn't give

   <ifette_SMO> back

   <Mez> we're trying to start again, but not everyone is back

   <ifette_SMO> I might be able to work more once I hit LAX, but I fear
   that the bus ride from Santa Monica to LAX, plus the security line etc,
   is easily going to eat up 2h

Section 6

   <tlr> ScribeNick: tyler

   rachna: Does the URL count as an identity signal?

   Mez: No
   ... trace back the definitions in the spec
   ... anywhere a URL appears should be accompanied by an identity signal
   ... derived from useful data is better than a URL

   <PHB> task centered

   <Zakim> PHB, you wanted to say actually people seem to think the

   <Mez> I've got two issues there

   <Mez> one is that the url is bad. if it wasn't there as the only
   "source", then I wouldn't feel th eneed to counteract it

   phb: we don't want to give more raw information

   <Mez> so I'd love a proposal to take it off, but I believe it won't fly

   phb: but sometimes things are hard to use because there's not enough
   information available
   ... sometime the information is left out because someone thought it
   would just confuse me

   <Mez> the other issue is, I live in product lang. We fight to the death
   for every bit of information in the UI. Which means we all believe it's

   <Mez> and my third issue about phishers going to some amount of trouble
   to get urls that look plausible

   <Mez> I realize that's just restating the same stuff

   maritza: 6.1 is about primary chrome and 6.2 about secondary chrome?

   mez: yes

   maritza: 6.2 is something I would support but not 6.1

   mez: should we do 6.2 first?

   rachna: Don't current web browsers comply with 6.2?

   tlr: Some of the information is not easily accessible
   ... for instance OCSP results are often not available

   mez: How do I get this info on IE6?

   tyler: In Firefox, right click and select "View Page Info"
   ... I have a later version of IE

   mez: IE6 seems like it is non-compliant with section 6.2.

   serge: much of this information only applies to AAC pages
   ... we should better define what the display should be for non-AAC

   mez: In the spirit of consistency I'd like there to always be some
   ... (looking at the Opera display) I would say this is also
   non-compliant since it doesn't provide an answer for each of the items
   highlighted in 6.2
   ... Can you have a validated certificate when OCSP has not been done?

   serge: Can an AAC certificate specify no OCSP or CRL?

   tlr: 3280 is very wiggly about revocation checks

   phb: we include this information in all our certificates
   ... some brands have never revoked a certificate
   ... a godaddy certificate can never be out of compliance
   ... you have to produce a CRL to be compliant with 3280, but you don't
   have to distribute it

   (much laughter)

   yngve: we did treat this as an error, but we don't anymore because
   there were too many errors
   ... the OCSP responder was always responding with errors

   <serge> yes

   <serge> you?

   tlr: some hotspots require a payment before use, but will not let
   through an OCSP check

   yngve: we don't display logotypes at the moment... there is no MAY

   <Mez> issue-141

   <Mez> issue-141?

   <trackbot-ng> ISSUE-141 -- More history that may be part of additional
   security context information -- OPEN

   <trackbot-ng> [34]http://www.w3.org/2006/WSC/track/issues/141

   phb: We need to distinguish between subject logos and issuer logos in
   bullet 9
   ... suggest splitting this into a separate bullet point for each
   ... the issuer field is always augmented assurance
   ... it is expensive to get the audit needed to be included in the
   shipped CA set

   tyler: This auditing has not necessarily been done for CAs the user has
   manually added

   phb: true

   yngve: Should a CA cert not distributed by the browser vendor have its
   logotype displayed?

   phb: my kids are not allowed to install CAs

   yngve: I think we need some language distinguishing vendor provided
   versus user provided certs

   phb: the issuer logo is pulled from the end-entity cert
   ... root CA certs change hands from time to time
   ... since the brand changes, the logo changes

   <ifette_SMO> 6.3?

   mez: any more issues on 6.2?

   tlr: back to 6.1?

   mez: Some people think no recommendation about primary chrome, some
   ... none have recommended a negative recommendation about chrome

   rachna: Didn't we have a SHOULD NOT about letting the web content
   populate the chrome?

   serge: favicons


   rachna: some users who don't understand the URL look for something they
   can understand, such as the page content and the window title


   <ifette_SMO> +1

   <Mez> if I thought we'd actually do ut I'd agree with serge

   <Mez> but we've been dragging our heels on that for a long time

   tlr: Is serge saying we need user studies on SHOULD NOTs in this
   section before last call?

   <ifette_SMO> speaking of which

   <ifette_SMO> are we covering 6.3?

   mez: I think we need a lo-fi prototype before last call. Otherwise we
   don't know what we're talking about

   tlr: I agree

   (general consensus in room)

   mez: We need some more alternatives listed for 6.1

   <ifette_SMO> cacophony

   <ifette_SMO> 3 different conversations

   <ifette_SMO> or maybe 4

   <ifette_SMO> I'm so lost

   (side conversations prevade)

   (side conversations pervade)

   <Mez> blah, blah, blah, blah

   mez: We need to line up the set of proposals we have.


   tlr: if we don't have the identity signal in primary chrome, there
   needs to be an easy way to get to the secondary chrome

   mez: I don't see consensus yet on 6.1

   <ifette_SMO> +1 to removal

page security score

   serge: this is just a bad idea, let's drop it

   rachna: a binary page score is like the padlock


   <tlr> ... that's Tim Hahn's proposal

   mez: Let's go to Tim Hahn's rewrite

   <ifette_SMO> I seem to still be unhappy with the rewrite

   mez: need to have a conversation about what we'll do with this for June
   ... because of the similarity with padlock

   yngve: Opera's old padlock was an implementation of a page security
   score based on encryption level and other problems with the certificate
   ... the latest version puts EV at level 4
   ... we only show a padlock with level 3 or above

   <serge> ...it goes up to 11

   yngve: we show this information in secondary chrome

   mez: Is there a security confidence estimate?

   yngve: no
   ... but there is a fraud control check, that is similar to that concept

   fette: this proposed text resulted in a long email thread on the list,
   which left me still feeling this would not help users

   serge: I firmly believe this is a terrible idea
   ... but if we do recommend, if every browser uses a different page
   scoring algorithm that would be strange

   hal: same goes for the weatherman

   fette: a lot of people are unhappy with the weather analogy

   serge: how about making it like the homeland security color coded
   ... how long has it been on orange
   ... it doesn't mean anything
   ... for example the netcraft toolbar always includes a portion of red
   just in case

   hal: the major sites are all solid green

   serge: google once got a smidgen of red

   hal: they are using a blacklist, where as the current proposal is based
   on collected information at runtime
   ... it's more heuristic

   serge: maybe all the time is useless to users

   mez: No one has argued that it's not current best practice
   ... is some indicator which is at least binary considered a current
   best practice

   fette: no
   ... I feel like all we've done is talk about stuff related to SSL, not
   whether or not I should trust this site
   ... nothing better than the padlock, so don't think we should recommend

   phb: even if 95% of the population is not helped by this control,
   doesn't mean we shoudn't help the other 5%

   <Zakim> ifette_SMO, you wanted to say that cluttering the screen for 5%
   is not necessarily good...

   phb: level of trust needed for slashdot is different than for my broker

   fette: That 5% doesn't need our help
   ... clutter
   ... better to use the space for content

   phb: less appealing for the browser vendors, but not a less desireable
   ... user behavior today and after education may be different
   ... we don't have any good education to give today since the current
   interface is so hard to use
   ... so may be the other 95% will learn

   <Mez> I don't see how recommending exactly what browser vendors are
   doing today makes it less appealing for them

   <Zakim> ifette_SMO, you wanted to say that less appealing for browser
   vendor means less likely our spec gets adopted

   fette: don't think the other 95% will learn since they didn't learn
   from the padlock

   phb: learn what?

   fette: they could click on the lock and see the cert details
   ... could learn how to parse a URL

   tyler: they could also learn how to use ethereal to examine the raw
   packets ;)

   <serge> +1

   mez: put on the agenda for next week a discussion of lo-fi prototypes
   for page security score

   <ifette_SMO> tyler, that would make me so happy ;-)

   maritza: need a concrete proposal

   rachna: if we use the lock icon as the lo-fi prototype there will be

   <Mez> a - would lean towards a recomendation that SHOULDed something
   like the padlock that displays SSL state

   <Mez> b - lean towards SHOULD NOT type rec on same

   <Mez> c - something else in this space, say what

   <ifette_SMO> c - say nothing because I don't think we have anything
   useful to say beyond the existing SSL information

   <yngve> a

   maritza: they want something much richer than just the padlock

   <Mez> a

   <hal> c - sce

   <bill-d> c

   <bill-d> c - sce

   <tyler> b since info about the SSL connection strength is more likely
   to give the user a false sense of security, as the padlock icon
   currently does, as seen in usability studies

   <PHB> c - sce

   <tlr> a, maybe a c -- I'd like something that talks about SSL strength,
   but with additional information. (I.e., I'm not sure how to parse the

   <serge> a

   <serge> what about an indicator to indicate lack of SSL?

   <maritzaj> c - ssl state should be available somewhere in a
   consistently displayed way ...

   <serge> does a) preclude that?

   <rachna> I could say anything that states binary static indicators
   don't work. to recommend anything more, I would need details on the
   implementation or proposal.

   <tlr> mez: rachna, "don't do it" is a "b"

   <tlr> rachna: yes

   rachna: b since it's a static indicator

   <maritzaj> A

   <maritzaj> you guys are all freaking insane

   <serge> a = should we indicate the presence/lack of SSL?

   <maritzaj> then yes

   <maritzaj> A

   <maritzaj> something about ssl somewhere for somebody who cares

   <ifette_SMO> really?

   <ifette_SMO> modulo ian as well

   mez: The straw poll tells me that it's possible to construct a low bar
   proposal that will achieve consensus

   serge: an indicator for lack of SSL would be good

   rachna: but most sites don't use SSL so the cue would lose its meaning

   serge: yes

   fette: want to see sample displays, plus the input to the algorithm
   ... I think the current inputs are the same as for the lock

   rachna: I would also like to see the distribution of how often each
   indicator appears for each site

   serge: we might be able to make the padlock slightly better by
   inverting its meaning
   ... banks won't put this indicator on their login pages

   rachna: phishers won't try to spoof it

   <serge> ....unless they're stupid

   <serge> BoA might use it


   <ifette_SMO> Hi Ho, Hi Ho, it's off to LAX I go...

   <tlr> ScribeNick: maritzaj

   mez: let's do another section, talk logistics, then go home

6.4 Error Handling and Signalling

   rachna: is this the section that Serge is rewording?

   mez: which ones interrupt the users flow of action and which don't,
   providing a nontech explanation is a good idea

   rachna: what's being able to get back to the prior state

   tlr: getting back to the state you were in before the error

   phb: these are things you shouldn't need to test

   tlr: don't interrupt for the lower class of errors, do for the heavier,
   make sure you don't throw away state too early
   ... and explain things reasonably
   ... and don't refer people to the page they can't access without
   agreeing to something

   <serge> here, I mocked up some security score indicators:

   <serge> [39]http://www.guanotronic.com/~serge/security_score.png

   <serge> [40]http://www.guanotronic.com/~serge/security_score2.png

   mez: sounds good, serge will be refining it

   serge: i agree with this, but i plan to mostly rewrite this
   ... i don't like the fact about saying weak tls

   tlr: i'm happy to have a layer of indirection between them

   serge: these are the types of warnings, these do this

6.4.2 Handling certain man in the middle attacks

   tlr: assume there's a mitm attack, but the url doesn't match the cert,
   so it might be the course of action to let the user go to the url that
   you may derive from the cert

   mez: so you want to go to the url of the attacker?

   tlr: yes

   tyler: no. time to duck and cover

   bill: yep

   mez: is there something we should sub for these issues?

   bill: why follow it?

   tlr: you may want to go there, there is an intercept, you are talking
   to a specific server, not the one you wanted, you might want to connect
   to that server
   ... and yes, this is all nasty
   ... if people think it's too unsafe i won't put up a fight

   phb: we're talking about subject information, there's the subject
   domain name and another for the name, so IETF argues over which should
   be used, most CA's populate both
   ... one's the standards, one's what browsers use

Section 7

   mez: let's save 7, we'll do 8/9

8. Robustness

   mez: 8.1.2 has the first normative text

   rachna: i don't understand 8.1.1

   <Mez> issue-112?

   <trackbot-ng> ISSUE-112 -- Conformance models for usability? -- OPEN

   <trackbot-ng> [41]http://www.w3.org/2006/WSC/track/issues/112

   tlr: let's throw it away if we don't need it

   <Mez> issue-173?

   <trackbot-ng> ISSUE-173 -- 8.1.1 Requires user testing for the purposes
   of conformance -- OPEN

   <trackbot-ng> [42]http://www.w3.org/2006/WSC/track/issues/173

   serge: understand the intent, but the wording isn't right
   ... the intent is, the website shouldn't be able to put in a lock icon
   or green url

   bill: why did developers put logins into an http page not https then
   call it secure

   mez: that's section 5

   rachna: serge wanted to remove 8.1.2 and no one objected

   serge: then what do we replace the title with?

   rachna: website provided content goes in one place, everything else
   goes somewhere else

   bill: i agree with that

   serge: what else is there

   rachna: status bar, title bar, the tabs, the favicon

   phb: the titlebar and the tabs compete
   ... we can agree that the titlebar should only show text that's

   rachna: i don't know for sure if we should give up the title bar, it
   was a straw man
   ... it's there for a reason

   bill: well there's something that's informational, but then there's the
   security context info

   <Mez> ack +

   serge: so part of the problem is the url bar
   ... homographic attacks, bad directory structure

   tyler: the cert can be misinformation too

   phb: gives a way to bind the attacker and the domain

   rachna: maybe instead of chosen and not chosen we can say verifiable
   and not verifiable

   seems like people agree, no yelling

   hal: you mean it should be verified, the information was verifiable and
   has been verified

   bill: you've been through the vetting process

   hal: in the real world there's some level of accountability, there's a
   real business address that you can find

   rachna: are we saying only ev cert go into chrome

   hal: a lot of time in the 90s was spent on how to have a transaction
   between two parties that have never met
   ... there are people you can catch and people you can't

   tyler: i agree with all this, but when phb pitches ev certs, he wants
   the green bar for ev experience and the subject name

   phb: case 1, you've never done business
   ... case 2, you have
   ... in the second, it's useful for matching the online identity to the
   offline identity

   rachna: but when there's no ev, what's displayed

   tyler: i was saying there's a useful rule for ev under that
   specification language

   rachna: so what you're saying is nothing gets into the chrome don't
   isn't verified

   tyler: no, only the verified gets into the chrome

   phb: in ev there's also the authenticated identity that they're
   accountable for

   rachna: but ev certs won't be on every site, then what happens

   bill: you can use a verified cert

   rachna: but most webpages don't have those

   bill: you dont know, and that's the problem

   rachna: i think attackers will put whatever the icon is into the

   bill: but you have the secure chrome

   rachna: so you've created the perfect environment for ev certs, but
   haven't solved the problem

   serge: i have an idea to solve this, get rid of chrome
   ... the problem will get so bad, the banks have to use 2 factor

   hal: they're starting
   ... JP morgan, deustche bank, in europe it's huge

   tyler: under the current language, big banks could use ev certs and the
   users would be safe

   rachna: and it won't work

   tyler: that's why we need to integrate safe form editor with ev certs

   <Mez> 8.1.2 - yes to keep, no to remove

   <maritzaj> 1

   <Mez> Web User Agents MUST NOT communicate material controlled by Web
   content in facets of the user interface that are intended or commonly
   used to communicate trust information to users.

   <yngve> yes

   <Mez> 1 is yes, 2 is no

   <tyler> yes

   <bill-d> yes

   <tlr> abstain

   rachna: i still don't see how that's provided by the website owner, the
   cert info

   <serge> no

   <PHB> yes

   serge: it seemed like everyone agreed this would overhaul current

   <hal> yes

   yngve: this might need clarification on what chrome we're talking about

   <tlr> so, as far as I'm concerned, yes, but with clarification

   <rachna> yes- that security indicators that aren't mixed (but I am not
   sure about recommendation that only verified content be presented in

   <Mez> no

   <Mez> yes - maritza, yngve, tyler, bill, phb, hal, rachna

   <Mez> no - serge, me

   <Mez> abstain - tlr

   <serge> The strongest man stands alone.

   tyler: what are your issues that we have to overcome

   mez: it's too much to overcome

   tyler: for me this works only if i can convince the mozilla guys to go

   hal: i'm expecting some very definitive instances of usefulness

   serge: so studies have been done that content is more important to
   users than content
   ... i would concede that allowing anyone can put anything in the title

   <PHB> give the users a fighting chance!


   mez: we have a variant we're directing toward last call in june, need
   to go over section 7, 8, 9
   ... tlr as an editor is going to branch them?

   tlr: at one point we need to fork into 2 documents, maybe not right
   now, or put the split within the document, appendix: this isn't in last
   call, but it'll stay for now
   ... we fork it before last call
   ... then we have a coherent second document

   tyler: i'd rather split it, then we can refer outsiders to the document
   without them getting sidetracked

   mez: we've done some changing and improving SCE will need some work

   tlr: i basically agree, i just don't know it's the next step

   mez: let's talk heartbeat reqs, we're behind

   tlr: tim said it's all ok

   mez: we're about to put usecases to bed
   ... back to xit, the next heartbeat is now

   tlr: go through minutes
   ... i'm tempted to hold on to the draft until it's ready

   tyler: when's is this due?

   tlr: feb
   ... my expectation is to have the fixed up version of this in feb

   mez: what event are you waiting for to separate

   tlr: there's work to get done other than just cut and paste
   ... i want a working draft to show the work we've done this far

   mez: has anyone reviewed xit?

   tyler: firefox, opera

   tlr: serge you're on the critical path now with 6.4
   ... fork as soon as possible, get out a working draft of june

   mez: have to have a meeting on lo-fi prototypes of SCE

   rachna: i don't know if we need a meeting again to discuss, without
   having anything to discuss

   mez: if we can't produce a single lo-fi prototype we can kill it
   ... next meeting, may in oslo, extension in June

Summary of Action Items

   [NEW] ACTION: phb to write replacement text for 5.1.3 [recorded in
   [NEW] ACTION: Serge to write up error levels [recorded in
   [NEW] ACTION: tlr to make it so [recorded in
   [NEW] ACTION: tlr to update definition of 5.1.4 [recorded in
   [End of minutes]

    Minutes formatted by David Booth's [47]scribe.perl version 1.133
    ([48]CVS log)
    $Date: 2008/02/27 14:16:30 $


   1. http://www.w3.org/
   2. http://www.w3.org/2008/02/06-wsc-irc
   3. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0019.html
   4. http://www.w3.org/2008/02/06-wsc-minutes.html#agenda
   5. http://www.w3.org/2008/02/06-wsc-minutes.html#a
   6. http://www.w3.org/2008/02/06-wsc-minutes.html#b
   7. http://www.w3.org/2008/02/06-wsc-minutes.html#c
   8. http://www.w3.org/2008/02/06-wsc-minutes.html#d
   9. http://www.w3.org/2008/02/06-wsc-minutes.html#e
  10. http://www.w3.org/2008/02/06-wsc-minutes.html#f
  11. http://www.w3.org/2008/02/06-wsc-minutes.html#item01
  12. http://www.w3.org/2008/02/06-wsc-minutes.html#item02
  13. http://www.w3.org/2008/02/06-wsc-minutes.html#item03
  14. http://www.w3.org/2008/02/06-wsc-minutes.html#item04
  15. http://www.w3.org/2008/02/06-wsc-minutes.html#item05
  16. http://www.w3.org/2008/02/06-wsc-minutes.html#item06
  17. http://www.w3.org/2008/02/06-wsc-minutes.html#item07
  18. http://www.w3.org/2008/02/06-wsc-minutes.html#item08
  19. http://www.w3.org/2008/02/06-wsc-minutes.html#ActionSummary
  20. http://www.baselinemag.com/c/a/Security/Survey-Users-Believe-Internet-Is-Safer/?kc=BLBLBEMNL020608STR2
  21. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sect-evcerts
  22. http://www.w3.org/2008/02/06-wsc-irc
  23. https://../
  24. http://www.w3.org/2008/02/06-wsc-irc
  25. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#selfsignedcerts
  26. http://my.opera.com/yngve/blog/show.dml/461932
  27. http://www.ietf.org/rfc/rfc3280.txt
  28. http://my.opera.com/yngve/blog/2007/12/21/new-w-not-in-kestrel5
  29. http://www.safetysign.com/CLDR.asp?PG=ANSIStandards4
  30. http://www.w3.org/2008/02/06-wsc-irc
  31. http://my.opera.com/yngve/blog/show.dml/508407
  32. http://www.w3.org/2008/02/06-wsc-irc
  33. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-redirects
  34. http://www.w3.org/2006/WSC/track/issues/141
  35. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirement-dontmix
  36. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
  37. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirement-dontmix
  38. http://www.w3.org/mid/OFE66F7E8F.2BB71D93-ON852573D9.0050788D-852573D9.00532917@us.ibm.com
  39. http://www.guanotronic.com/~serge/security_score.png
  40. http://www.guanotronic.com/~serge/security_score2.png
  41. http://www.w3.org/2006/WSC/track/issues/112
  42. http://www.w3.org/2006/WSC/track/issues/173
  43. http://www.w3.org/2008/02/06-wsc-irc
  44. http://www.w3.org/2008/02/06-wsc-irc
  45. http://www.w3.org/2008/02/06-wsc-irc
  46. http://www.w3.org/2008/02/06-wsc-irc
  47. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  48. http://dev.w3.org/cvsweb/2002/scribe/

Thomas Roessler, W3C  <tlr@w3.org>
Received on Wednesday, 27 February 2008 14:17:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:53 UTC