See also: IRC log
<tlr> ACTION-411?
<trackbot-ng> ACTION-411 -- Anil Saldhana to apply change about multiple error conditions -- due 2008-04-17 -- PENDINGREVIEW
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/411
<tlr> ACTION-412?
<trackbot-ng> ACTION-412 -- Anil Saldhana to number bulleted list in 5.5.1, and while doing so, swap first two bullets. -- due 2008-04-17 -- PENDINGREVIEW
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/412
<tlr> ACTION-413?
<trackbot-ng> ACTION-413 -- Anil Saldhana to add stephenF's note re newly pinned certs to 5.5.1 and re-iterate it in security considerations section -- due 2008-04-17 -- PENDINGREVIEW
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/413
<tlr> Previous minutes: http://www.w3.org/2008/04/02-wsc-minutes.html
Minutes of previous meeting
<tlr> RESOLUTION: minutes accepted
Accepted nem con
<tlr> trackbot-ng, close ACTION-390
<trackbot-ng> ACTION-390 Make it so [clean-up of error messages part of spec] closed
<tlr> trackbot-ng, close ACTION-400
<trackbot-ng> ACTION-400 Merge text from ACTION-376 (history storage language) closed
<tlr> trackbot-ng, close ACTION-403
<trackbot-ng> ACTION-403 Check reservation code for f2f hotel closed
<tlr> trackbot-ng, close ACTION-409
<trackbot-ng> ACTION-409 Revise "MUST include applicable DNS name" based on discussion closed
Looking at TLS error part
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
<tlr> trackbot-ng, close ACTION-411
<trackbot-ng> ACTION-411 Apply change about multiple error conditions closed
<tlr> trackbot-ng, close ACTION-412
<trackbot-ng> ACTION-412 Number bulleted list in 5.5.1, and while doing so, swap first two bullets. closed
<tlr> trackbot-ng, close ACTION-413
<trackbot-ng> ACTION-413 Add stephenF's note re newly pinned certs to 5.5.1 and re-iterate it in security considerations section closed
<scribe> Done since then: Anil discharged action items on preference fgor multiple error conditions, bulleted lists fixed and Stephen F.'s uissue on linked certificates
<tlr> trackbot-ng, close ACTION-414
<trackbot-ng> ACTION-414 Revive relaxed path validation and use it from error handling part of spec closed
<tlr> When certificate information is presented in these interactions, web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.
Want to deal with open question from the last meeting where proposal was there should be language as above
included in the error handling
Is this text in order or should it be phrased more broadly.
Ifette: question with regard to error handling and TLS, just noticed that we have quite a bit of deviation. Some browsers treat mixed content as deviation, others do not (e.g. linked images).
phb: make it explict, not just general
TLR: suggest we go with text Mez
proposed, then look into more detail on mixed content
... are we agreed here?
<tlr> ACTION: Anil to add above text to 5.5.1 TLS errors [recorded in http://www.w3.org/2008/04/16-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-415 - Add above text to 5.5.1 TLS errors [on Anil Saldhana - due 2008-04-23].
TLR: relaxed path validation
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0027.html
TLR: email suggests keeping
existing text may not be a bad idea.
... text says must not use relaxed for an AA qualified root,
must use basic, may use relaxed for non-AA roots
PHB: suggest changing 'AA-qualifier' to 'represent to the user as aa qualified'
<stephenF> fwiw, relaxed stuff looks good to me, I can imagine we might wordsmith more given the number of minor changes accumulating
TLR: user agent would make an
implementation time decision not to present a certificate as
AA
... as you are phrasing it you are saying you can fallback to
relaxed
<Zakim> ifette, you wanted to say ie does this already
TLR: this would be an issue for revocation checking, what if the EV cert is expired?
<stephenF> tlr: s/validity checks/status checks/ I think you meant
TLR: not required to check revocation for relaxed
<ifette> q+ to ask whether we expect this behaviour to be default and if so if we really want this behavior
<Zakim> ifette, you wanted to ask whether we expect this behaviour to be default and if so if we really want this behavior
PHB: Is the resulting behavior the right one, an expired cert is very bad and treated as revoked, however this does not apply to relaxed
ifette: if we make this the
default in browsers this will create a situation where most
people do not enable their cert and they will use expired
certs
... do we intend this to be the default and are we happy with
it
tlr: way it is phrased now creates a choice. if you are checking for revocation you cannot distinguish between revoked and expired
<stephenF> and we're not saying when a UA does or doesn't do validity checks, right?
tlr: if you do validity checks
and it is expired you must do serious error messages, otherwise
do not bother the user with the expired message either.
... current situation is just bad
ifette: no user is ever going to configure this if browsers adopt this there will be a much reduced incentive to renew certs
StephenF: actually the notAfter field is a mistake, it was intended for logging into X.500 directories.
<tlr> phb: from pov of commercial issues, most web sites are not going to be happy with situation in which cert works in 70% of cases, commercial pressure is not really affected at all, as long as there's any significant number of browsers that do not accept expired certs, that's going to be enough sand in shoe to cause renewal, other issue is that it depends on revocation technology, expiry field has had its day, reason for that is that we're using OCSP for revocation info in online status model, only reason for ever needing expiry field is if you want to limit the period in which people are asking for OCSP response as soon as cert is revoked, we put ocsp token in file, that's shipped out in perpetuity ocsp responses in reql time vs stapling responses, should notice when using expired cert customer with cert about to expire, roll over of key to new cert continue to use old cert on server ocsp tokens telling people not to trust cert?
StephenF: rare to get both the DNS domain and the private key
TLR: Issue is whether we should
fallback to relaxed.
... ok relaxed off the table for AA
... second point then remains is there something more than
relaxed, or should there be an opening for user agents to
signal strong errors when it succeeds
... heuristic such as this is two years old.
StephenF: two weeks would be a problem for self-signed
TLR: this is validated certs,
self-signed does not really apply
... browsers who use relaxed may employ additional techniques
to detect expired certs
Stephen: such as?
third issue: do we want to say anything about defaults?
ifette: if browsers have
different configs and others do not, people are likely to
switch to the browser that provides least annoyance
... different browsers should not do different things on the
same site.
TLR: for AA should always do full, for validated should use relaxed...
StephenF: what is downside of saying always use relaxed for non-AA certs
<tlr> phb: don't want to downgrade all non-AA certs by cutting out revocation
<tlr> ... the cases where revocation checking doesn't help is CAs that never issue revocations ...
TLR: there may be room between relaxed and basic but where?
<tlr> ACTION: phil to draft proposal for slightly stricter variant of relaxed and basic [recorded in http://www.w3.org/2008/04/16-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-416 - Draft proposal for slightly stricter variant of relaxed and basic [on Phillip Hallam-Baker - due 2008-04-23].
TLR: ifette please put issue into
the tracker to say that we have not considered whether relaxed
should be mandatory
... Issue 418 is related to and blocks
<tlr> s/issue 418/action-416/
TLR: relaxed is done so error
handling for mixed content
... current text in 5.5.1. does not mention mixed content
<ifette> Link pls?
<ifette> for 5.5.1
TLR: this theoretically applies to any sub-content on the page. there is mention in the identity signal about downgrade
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#errorconditions
TLR: is there anything that we
need to say about error conditions when receiving error content
when retrieving a toplevel resourse
... do we need to distinguish further between dependent
resources?
<Zakim> ifette, you wanted to say that differences suck and to
ifette: there is lots of
variation on this, IE does one thing, Firefox another.
... would like to see statement that all subcontent should be
fetched via https:
<stephenF> ifette: is a warning needed for images?
ifette: suggestion would be that
browser would not load subcontent
... yes can change wachovia image to huge logo saying 'call xyz
to authorize account'
<tyler> Not loading the mixed content also has the advantage that the browser may never need to pop a warning if the user was just browsing and moves on.
TLR: currently During interaction with mixed content we just say must not display the positive identity signal
<tyler> Reducing the number of warnings is always useful
TLR: From what hearing seem to be two choices: first whether in case mixed content behaving as designed, we should say that such resources should not be rendered. otherwise should say that we want to limit the error handling
<tlr> tlr: do we want to say "don't load insecure subresources"?
PHB: sth like "display images" when they don't load
<Zakim> ifette, you wanted to encourage people to look at the source of https://www.wachovia.com and cry - the site looks really broken if you filter it out and to
ifette: do like the idea of not loading resources, but some sites are totally broken without it. If you co to wachovia without it it looks like gopher from 1990 because they use http to load all the sub-resources.
[lets work out a more aggessive idiot box]
bill: mute button for obnoxious content
tyler: if the browser developers had not shown the mixed content the webmasters would not have got so lazy but horse out of barn
ifette: with regards to designed mixed content not clear
TLR: referring to http links, not https that has failled
ifette: what is the point of SSL in these cases
TRL: that is already there, is there something beyond that?
<tlr> During interactions with a mixed content Web page, the identity signal MUST NOT include any positive indicators exceeding those in use for unprotected HTTP transactions. In this situation, the identity signal MAY include indicators that point out any error conditions that occurred.
TLR: not in 5.5.1 text is above
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tls-indicator
<tlr> The TLS indicator MUST present a distinct state that is used only for TLS-secured Web pages. The User Agent SHOULD inform users when they are viewing a page that, along with all dependent resources, was retrieved through at least weakly TLS protected transactions, including mixed content.
<tyler> I like the text TLR just posted into IRC. I think that's the right way to deal with this case
TLR: one thing we are saying on the topic is TLS indicator shall have a distinct state that is only used for TLS resources
ifette: I think that to do this we all have to do it
PHB lets render non compliant sites in black and white
Bill: its also non protected links
<tyler> So does akamai not offer HTTPS service? It looks like that's the reason for the Wachovia page design
ifette: if a user explicitly types in https and all they get is the absence of a lock, is that sufficient?
TLR: good question
PHB: and what about the bookmarks
TLR: ifette free to send message
to mailing list suggesting behavior otherwise we drop
this
... Ok other question dealing with error signals where we
actually have https uris to deal with dependent resources, do
we need specific language to deal with this there or is the
generic error handling enough?
<stephenF> tlr: do we have an example of such an error case?
TLR: one example would be a site that is TLS secured, have to have a validated certificarte for toplevel resource that works well, have an image with an https uri, but a a certificate that was not currently pinned to that location, is that the right behavior or should we say don't show that resource
you have wachovia, you have foobar.org present a selfsigned cert that is not pinned
<tlr> RESOLUTION: generic handling is enough
TLR: anything else about error handling other than the typo?
OK, in that case done with this agendum. Move to 6.4 error handling and signalling
Stephen, TLS has extensions now, someone should look into whether this will cause issues.
TLR: well volunteered, when will you be done
<tlr> ACTION: stephen to investigate completeness of error handling wrt TLS extensions - due 2008-05-15 [recorded in http://www.w3.org/2008/04/16-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-417 - investigate completeness of error handling wrt TLS extensions [on Stephen Farrell - due 2008-05-15].
6.4 error handling and signalling
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
<Zakim> stephenF, you wanted to ask what's not technical jargon? (would positive be better than negagtive guidance)
TLR (sumarizes the section)
StephenF: what is the compliance criteria for not technical jargon?
TLR: mostly agreement but how to check it?
StephenF: could we relate it to the help screen? Language of the user agent?
<maritzaj> talking into mute of course ... but no, not now
<PHB> pbaker: maybe a parenthetical explanation is a good thing
<PHB> ... "a warning that can only been understood with recent concepts is probably not acceptable"
<tyler> warning should be phrased in terms of the threat to the user, not the technical occurence. Make it clear what the impact of the technical failing is.
Stephenf: not something that can be checked easily
<Zakim> asaldhan, you wanted to say that MikeM should be included as this is his proposal
Stephen: there are people who can generaly check that labels are understabdabhle by a 12 year old or so?
Anil: whatever discussion we have should ping Mike McCormick as this is his proposal
TLR: he is not here
... One way is to specify a user with a certain level of
education
<Zakim> ifette, you wanted to say oh god no
<tlr> tlr: SHOULD NOT plus Tyler's text?
TLR: should not plus tylers proposal then
<tlr> "technical jargon" -> "terms of art"
<bill-d> ok
<tlr> SHOULD NOT include terms of art. SHOULD be phrased in terms of threat to user's interests, not technical occurence
TLR: should not include terms of art, should be phrased in terms of threat to user, noth the technical occurrence
Stephen: not sure that threats against users interests is right test
<tlr> ACTION: anil make edit about terms of art, threat to user's interests to 6.4.1 (common error interaction reqs) [recorded in http://www.w3.org/2008/04/16-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-418 - Make edit about terms of art, threat to user's interests to 6.4.1 (common error interaction reqs) [on Anil Saldhana - due 2008-04-23].
TLR: OK anything else on this
one
... ok will remove last requirement because it does not work
with the requirements model
<tlr> ACTION: tlr to either strike last para of 6.4.1 or propose alternative [recorded in http://www.w3.org/2008/04/16-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-419 - Either strike last para of 6.4.1 or propose alternative [on Thomas Roessler - due 2008-04-23].
action on TLR
TLR: 6.4.2 notification and indicators,
<Zakim> stephenF, you wanted to ask what MUST include textual means
Stephen: what does MUST mean
here
... is a hover ok
TLR: hover is secondary chrome, not compliant
<stephenF> ok, just wondering (might be a challenge to implement?)
TLR: self signed certificate with
pinning would use this approach. We say that bookmark apis
should use notifications from this section (mistake?)
... is this a problem?
... currently we are only discussing pinning for self signed
certificates, we may want to revisit that
... for instance do not know what this is, we may want to.
Stephen: user may be asked for an action but there is no need to provide an interaction to continue with the primary task
<tlr> stephen: maybe say "MAY solicit user interaction, but MUST NOT force it"
TLR: objections?
... action to anil...
<tlr> ACTION: anil to change 6.4.2 (notification / status) to include "MAY solicit user interaction" [recorded in http://www.w3.org/2008/04/16-wsc-minutes.html#action06]
<trackbot-ng> Created ACTION-420 - Change 6.4.2 (notification / status) to include \"MAY solicit user interaction\" [on Anil Saldhana - due 2008-04-23].
<stephenF> 2nd "must" in 2nd para of 6.4.3 is lowercase btw,
TLR: three minutes left but not got to the petname section, suggest we end.
ifette: anyone else going to be in Beijing
TLR: me, ian, tyler, joint
appearance
... closes
next call 30th april, TLR will not be present
Register for the F2F