- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 5 May 2008 10:33:02 +0200
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2008-04-16 were approved and are
available online here:
http://www.w3.org/2008/04/16-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Teleconference
16 Apr 2008
[2]Agenda
See also: [3]IRC log
Attendees
Present
+47.23.69.aaaa, PHB, jvkrey, Thomas, asaldahan, ifette,
stephenF, Maritza_Johnson, Tyler, Bill_Doyle
Regrets
luis, johnathan, serge, dans
Chair
tlr
Scribe
PHB2
Contents
* [4]Topics
1. [5]More on 5.4.1 TLS errors
2. [6]6.4, error handling and signalling
* [7]Summary of Action Items
__________________________________________________________________
<tlr> ACTION-411?
<trackbot-ng> ACTION-411 -- Anil Saldhana to apply change about
multiple error conditions -- due 2008-04-17 -- PENDINGREVIEW
<trackbot-ng> [8]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> [9]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> [10]http://www.w3.org/2006/WSC/track/actions/413
<tlr> Previous minutes:
[11]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
More on 5.4.1 TLS errors
Looking at TLS error part
<tlr>
[12]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
[13]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>
[14]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
[15]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>
[16]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
[17]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>
[18]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
<tlr>
[19]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tls-indicato
r
<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
[20]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
6.4 error handling and signalling
<tlr>
[21]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
[22]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
[23]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
[24]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
Summary of Action Items
[NEW] ACTION: anil make edit about terms of art, threat to user's
interests to 6.4.1 (common error interaction reqs) [recorded in
[25]http://www.w3.org/2008/04/16-wsc-minutes.html#action04]
[NEW] ACTION: Anil to add above text to 5.5.1 TLS errors [recorded in
[26]http://www.w3.org/2008/04/16-wsc-minutes.html#action01]
[NEW] ACTION: anil to change 6.4.2 (notification / status) to include
"MAY solicit user interaction" [recorded in
[27]http://www.w3.org/2008/04/16-wsc-minutes.html#action06]
[NEW] ACTION: phil to draft proposal for slightly stricter variant of
relaxed and basic [recorded in
[28]http://www.w3.org/2008/04/16-wsc-minutes.html#action02]
[NEW] ACTION: stephen to investigate completeness of error handling wrt
TLS extensions - due 2008-05-15 [recorded in
[29]http://www.w3.org/2008/04/16-wsc-minutes.html#action03]
[NEW] ACTION: tlr to either strike last para of 6.4.1 or propose
alternative [recorded in
[30]http://www.w3.org/2008/04/16-wsc-minutes.html#action05]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [31]scribe.perl version 1.133
([32]CVS log)
$Date: 2008/05/05 08:32:12 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0028.html
3. http://www.w3.org/2008/04/16-wsc-irc
4. http://www.w3.org/2008/04/16-wsc-minutes.html#agenda
5. http://www.w3.org/2008/04/16-wsc-minutes.html#item01
6. http://www.w3.org/2008/04/16-wsc-minutes.html#item02
7. http://www.w3.org/2008/04/16-wsc-minutes.html#ActionSummary
8. http://www.w3.org/2006/WSC/track/actions/411
9. http://www.w3.org/2006/WSC/track/actions/412
10. http://www.w3.org/2006/WSC/track/actions/413
11. http://www.w3.org/2008/04/02-wsc-minutes.html
12. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
13. http://www.w3.org/2008/04/16-wsc-minutes.html#action01
14. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0027.html
15. http://www.w3.org/2008/04/16-wsc-minutes.html#action02
16. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#errorconditions
17. https://www.wachovia.com/
18. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
19. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tls-indicator
20. http://www.w3.org/2008/04/16-wsc-minutes.html#action03
21. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
22. http://www.w3.org/2008/04/16-wsc-minutes.html#action04
23. http://www.w3.org/2008/04/16-wsc-minutes.html#action05
24. http://www.w3.org/2008/04/16-wsc-minutes.html#action06
25. http://www.w3.org/2008/04/16-wsc-minutes.html#action04
26. http://www.w3.org/2008/04/16-wsc-minutes.html#action01
27. http://www.w3.org/2008/04/16-wsc-minutes.html#action06
28. http://www.w3.org/2008/04/16-wsc-minutes.html#action02
29. http://www.w3.org/2008/04/16-wsc-minutes.html#action03
30. http://www.w3.org/2008/04/16-wsc-minutes.html#action05
31. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
32. http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 5 May 2008 08:33:41 UTC