- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 11 Jun 2008 18:31:06 +0200
- To: public-wsc-wg@w3.org
Minutes from our meeting on 2008-06-04 were approved and are
available online here:
http://www.w3.org/2008/06/04-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
WSC WG weekly
04 Jun 2008
[2]Agenda
See also: [3]IRC log
Attendees
Present
joesteele, MaryEllen_Zurko, +47.24.16.aaaa, Thomas, jvkrey,
claudio, Tyler, PHB, +1.202.386.aabb, ifette, +1.312.933.aacc,
anil
Regrets
Luis_B, Serge_E, Dan_S, Bill_D, Johnathan_N
Chair
MEZ
Scribe
joesteele
Contents
* [4]Topics
1. [5]Pick a scribe
2. [6]Approving minutes from 5/21, 5/28, F2F
3. [7]Outstanding ACTION items
4. [8]Agenda Bashing
5. [9]Testing Opera compliance with RFC 2119 text
* [10]Summary of Action Items
__________________________________________________________________
Pick a scribe
joesteele is the scribe
Approving minutes from 5/21, 5/28, F2F
minutes are approved
Outstanding ACTION items
<Mez>
[11]http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0094.html
<Mez>Thanks everyone who completed action items
<Mez> Action items CLOSED (due to inactivity) -- none!
Agenda Bashing
<Mez> Opera is the main topic today
<Mez> Next Mozilla on tap for same issues
<Mez> request for spec version we can markup during discussions
<tlr> no easy way -- could setup a table based on 2119 issues
<Mez> [12]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
Testing Opera compliance with RFC 2119 text
<Mez> planning on using (version) 9.50
<Mez> do you expect to include mobile testing?
yngve> short answer is yes
<Mez> assume planning is for 9.50 + 9.20 (aka 9)
<yngve> mobiles versions prior to 9.5
<Mez> Web user agents MUST establish that a trust anchor is
[Definition: AA-qualified ] through some out of band mechanism
consistent with the relevant underlying augmented assurance
specification
<Mez> Augmented Assurance Certificates
<Mez> Opera plans to comply?
<yngve> setting up a framework, depends on EV audit passing
... not possible to define it -- only ygnve can define
<Mez> Implementations MUST NOT enable users to designate trust roots as
AA-qualified as part of a different interaction
<Mez> Implementations MAY make user interfaces available for the
purpose of designating AA-qualified trust roots.
<Mez> If the certificate's Subject field does not have an Organization
attribute, then user agents MUST NOT consider the certificate as an
augmented assurance certificate, even if it chains up to an
AA-qualified trust root. User agents MAY consider such a certificate as
an ordinary validated certificate.
<Mez> will Opera recognize certs like this?
<yngve> at the moment not checking ... this is a compliance question
for the CA
<Mez> but this is a MUST
... we should discuss making this a MUST NOT
<tlr> if you have an EV cert w/o org attribute what is the behaviour?
<Mez> this will be worked out as we go along
<scribe> 5.1.4 Logotype Certificates
Where this specification suggests or mandates the rendering of (either
audio or visual) logotypes, the logotype is chosen as follows: * When
the logotype information is derived from an augmented assurance
certificate, then the subject logotype MUST be rendered, if present. *
Otherwise, when the logotype information is derived from a validated
certificate, then the issuer logotype MUST be rendered, if present.Note
that an augmented assurance
<yngve> at the moment no support for logotypes
<Mez> For Web user agents that use a visual user interface capable of
displaying bitmap graphics the identity signal MAY include display of a
suitable logotype, selected according to the rules in 5.1.4 Logotype
Certificates.
<Mez> in 6.1.2
<Mez> ditto for
<Mez> Web user agents that use sound to communicate with the user MAY
render an audio logotype that is embedded in the certificate using the
logotype extension, according to the requirements in 5.1.4 Logotype
Certificates.
<Mez> 5.1.4 not in opera
<Mez> Web user agents MAY support [Definition: pinning] a self-signed
certificate or more generally a certificate chain that leads to an
untrusted root certificate to a particular Web site, to enable behavior
based on recorded state about certificates shown previously by the same
site. Such behavior includes, e.g., warning users about changes of
certificates, and not showing warning messages if a site shows a
certificate consistent with previous visits.
<yngve> support for pinning in 9.5
<jvrkey> could be support in the mobile
<yngve> persistent pinning
<Mez> The interaction that enables users to pin a certificate to a
destination SHOULD NOT cause a self-signed certificate to be pinned to
more than one site, identified through URI scheme, domain, and port.
The interaction MUST NOT cause an untrusted root certificate to be
accepted automatically for additional sites.
<yngve> pinning is not distinguished on URI scheme at this point
... academic at this point
<Mez> will you pin to more than one site?
<yngve> only pinning to one site/port combo at this point
<Mez> If a client is able to automatically accept a self-signed
certificate, or recover from similar problem without user interaction,
it MUST NOT do so unless the client also have a history mechanism about
security information.
<yngve> no automatic recovery method
<Mez> sounds like you will be supporting all the language then
... you won't satisfy the IF clause then?
<Mez> A Web User Agent that can display an AA indicator MUST NOT
display this indicator unless all elements of the page are loaded from
servers presenting an AA certificate.
<yngve> this is not up to date with the latest text
<Mez> your blog says you will be conforming with the latest revision
<yngve> TLS pages having non-TLS content?
<Mez> might not be there yet
<jvrkey> "This definition implies that inline images, stylesheets,
script content, and frame content for a secure page need to be
retrieved through strongly TLS protected HTTP transactions in order for
the overall page to be considered TLS-secured."
<Mez> this text has taken a while to get comfortable with
... this is the definition of TLS-secured (we are discussing)
<Mez> If multiple error conditions apply, the most severe signalling
level currently known MUST be used, as defined in 6.4 Error handling
and signalling.
<yngve> we are doing this
... and adding a comment field
<Mez> When, for a TLS-protected HTTP connection, the certificate chain
presented by the server does not lead to a trusted root certificate,
and the certificate chain presented was not pinned to the destination
at hand, the following applies:
<Mez> If a validated certificate (including an augmented assurance
certificate) was previously presented by the same destination, then
error signalling of class danger (6.4.4 Danger Messages) MUST be used.
<Mez> If a different certificate was previously pinned to the same
destination, then error signalling of class warning or above (6.4.3
Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used. User
agents MAY offer the possibility to pin the newly encountered
certificate to the destination at hand. Note that this newly pinned
certificate could be the basis for a spoofing attack, or it could
represent a refresh of an Self Signed Certificate.
<Mez> Otherwise, user agents MAY use error signalling of class
notification (6.4.2 Notifications and Status Indicators ) to offer
pinning a given certificate, consistent with 5.1.5 Self-signed
Certificates and Untrusted Root Certificates.
<Mez> Otherwise, user agents SHOULD use error signalling of class
warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger
Messages).
<yngve> re: pt1 we don't store history of certs previously used on a
site
<jvrkey> also for mobile
<yngve> we are not looking at whether a validated certificate was used
previously -v- one with a warning
... we do show a warning if certificate does not work
<Mez> need to discuss how compliant this is
<yngve> need some kind of flag on this (warning certificate used)
... we have a cache of TLS certs used for a given host (not in 9.5)
>jvkrey< mobile devices cannot store this info
<Mez> does mobile version (of Opera) have this storage in some
versions?
<yngve> payload delivered to the device works differently
... re: pt2 if new cert is causing trouble, we will warn but no note
made about previously pinned cert
... pinning is temporary.. only until cert expires and then 90 days
after
<Mez> possibility of pinning newly encountered cert?
<yngve> yes
<Mez> is error signalling the right class (NOTIFICATION)?
<yngve> no -- notification is WARNING. No system for NOTIFICATION
(signalling) yet
<scribe> last two comment were re: pt 3 of 5.4.1
<yngve> revocation or blocked (site) will cause the DANGER warning
<Mez> When certificate information is presented in these interactions,
human-readable information derived from the certificates (e.g., Common
Name or Organization attributes) in question MUST NOT be presented as
trustworthy.
<yngve> displaying the information -- not making claims about
correctness or trustworthiness
<Mez> 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.
<yngve> info from cert is displayed -- not distinguishing self-signed
certs from validated certs
... displayed in secondary chrome
... self-signed certificate will trigger a warning and not display a
padlock
... displaying a short name in initial dialog, secondary dialog has
detailed info
<Mez> could be a conformance issue here
<yngve> we are displaying the common name along with the warning
message
<Mez> When, for a TLS-protected HTTP connection, the certificate
presented is found to have been revoked, error signalling of class
danger (6.4.4 Danger Messages) MUST be used.
<yngve> we are doing that
<Mez> When, for a TLS-protected HTTP connection, the certificate
presented is found to have been expired, error signalling of class
danger (6.4.4 Danger Messages) MUST be used.
<yngve> we are using a warning on that
... prefer to block here -- but at the moment not feasible
... need to get coordination with other browsers
<Mez> maybe we can get this
<Mez> When certificate status checks are attempted, but where the check
fails, (i.e. does not produce an answer as to certificate status), due
to network errors or related error conditions, the following applies:
<Mez> If a certificate check was successfully performed before, or if
an Augmented Assurance Certificate is used, then error signalling of
level danger (6.4.4 Danger Messages) MUST be used.
<Mez> Otherwise, error signalling of level warning (6.4.3
Warning/Caution Messages ) SHOULD be used.
<yngve> at the moment we are
<Mez> When the URL corresponding to the transaction at hand does not
match the certificate presented, and a validated certificate is used,
then error signalling of level danger(6.4.4 Danger Messages) MUST be
used.
<Mez> do you downgrade (no padlock) if no revocation available?
<yngve> yes
... displaying a WARNING currently
... prefer DANGER here as well, but must be coordinated
<tlr> current version of FireFox has DANGER-like behavior
... points the user at the actual domain name in the certificate
... given the possibility to go there directly
... may want to consider this for further recommendations
<yngve> could be important if there are multiple domains in the cert
<Mez> If TLS negotiation otherwise fails, error signalling of level
danger (6.4.4 Danger Messages) MUST be used.
<tlr> not sure how to handle that -- could investigate
<yngve> we do
<Mez> Historical TLS information stored for the purposes of evaluating
security relevant changes of behavior MAY be expunged from the user
agent on the same schedule as other browsing history information.
Historical TLS information MUST NOT be expunged prior to other browsing
history information.
<yngve> expunging data -- we get rid of the data after 30days -- but no
info about the certs currently
... some info is only kept in RAM
<Mez> not used for error message then (the history)
<Mez> User agents that use third party services or heuristic approaches
to assess the possible danger of a pending Web transaction MUST use
error signalling of class danger (6.4.4 Danger Messages) to signal
positively identified dangers, e.g., identified malicious downloads or
exploits of user agent vulnerabilities.
<yngve> for protection -- suspicious webs site will be blocked
... security level calc is the closest thing to a heuristic we do
<Mez> To signal risks that are identified with high likelihood, but
involve further user decisions (e.g., phishing heuristics were
triggered), error signalling of class warning or above (6.4.3
Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used.
<yngve> not aside from what warnings are displayed for
<Mez> Web user agents MUST signal an error of class warning or above
(6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) when a user
interaction with a TLS-secured page causes dereferencing of a URL that
leads to a chain of Web transactions that:
<Mez> does not involve user interactions, and,
<Mez> involves weakly TLS-protected or unprotected HTTP transactions.
<yngve> we lower the security level immediately
<Mez> instead of displaying error message?
<yngve> dialog with do not show again can be displayed
<scribe> yngve's last comment referred to other browsers
<Mez> particular, even if the retrieval of the final resource in the
chain of redirections is strongly TLS protected, clients MUST signal an
error.
<Mez> Web user agents MUST make information about the [[identity]] of
the Web site that a user interacts with available.
<yngve> we do
<Mez> This [Definition: [[identity signal]] ] SHOULD be part of primary
user interface during usage modes which entail the presence of
signalling to the user beyond only presenting page content
<yngve> it is in the address bar
<Mez> Otherwise, it MUST at least be available through secondary user
interface.
<yngve> yes -- clicking on ? will provide a detailed dialog
<Mez> mixed modes available?
<yngve> don't display a padlock
... if we don't have full security -- no identity signal
<Mez> If a positive form of identity is available, the identity signal
MUST be part of primary user interface when any identity sources that
are from unauthenticated or untrusted sources are (also) part of the
primary user interface. These sources include URLs.
<yngve> just display a ? in this case (mixed security as well)
... not sure about this one -- hard to parse
... possible ACTION around on this
<Mez> User interactions to access this identity signal MUST be
consistent across all Web interactions facilitated by the user agent,
including interactions during which the Web user agent has no
trustworthy information about the [[identity]] of the Web site that a
user interacts with. In this case, user agents MUST indicate that no
information is available.
<yngve> security toolbar should be available even when other bar is
collapsed
<Mez> User agents with a visual user interface that make the identity
signal available in primary user interface SHOULD do so in a consistent
visual position.
<yngve> identity info can be accessed thorough this and keyboard
... ok on this one
<Mez> Information displayed in the identity signal MUST be derived from
validated certificates, or from user agent state. Web user agents MUST
NOT use information as part of the [[identity signal]] that is taken
from unauthenticated or untrusted sources.
<yngve> we are using the validated cert for this
... don't get the identity signal if cert is not validated
<Mez> The identity signal MUST include human-readable information about
the certificate subject, derived as specified in 5.1.2 Augmented
Assurance Certificates, to inform the user about the owner of the Web
page
<yngve> 9.5 is displaying the ORG name for AA certificate -- others
display just the host name
<Mez> If the identity signal does not include any other human readable
information about the identity of the certificate subject (derived,
e.g., from an augmented assurance certificate), then it MUST include an
applicable DNS name retrieved from the subject's Common Name attribute
or from a subjectAltName extension.
<yngve> displayed if not an AA
<Mez> The identity signal MUST include the Issuer field's Organization
attribute to inform the user about the party responsible for that
information.
<yngve> not at this time in primary chrome
<jvrkey> for mobile -- info may not be available
<Mez> even in validated cases you may not have?
<yngve> may not have good enough connection
<Mez> Subject logotypes derived from certificates SHOULD NOT be
rendered, unless the certificate used is an augmented assurance
certificate.
<Mez> this one does not count because no logotype support
<Mez> 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.
<yngve> displaying the ? in this case
... not displaying any identity information otherwise
<jvrkey> no positive indicators (displayed)
<Mez> Web user agents MUST provide additional security context
information as described in this section through one or more
user-accessible information sources.
<yngve> we do have the dialog with detailed cert info
<Mez> Where security context information is provided in both primary
and secondary chrome, the presentation and semantics of the presented
information MUST be consistent.
<yngve> one of the panels has security state
... yes
<Mez> The information sources MUST make the following security context
information available:
<Mez> the Web page's domain name
<Mez> Owner information, consistent with 6.1.2 Identity Signal Content
<Mez> Verifier information, consistent with 6.1.2 Identity Signal
Content
<Mez> The reason why the identity information is trusted (or not). This
includes whether or not a certificate was accepted interactively,
whether a self-signed certificate was used, and whether the self-signed
certificate was pinned to the site that the user interacts with, and
whether trust relevant settings of the user agent were otherwise
overridden through user action.
<yngve> primary chrome is derived from secondary chrome text
... yes we are saying that user pinned
... we are providing some info about why it got that security level
<jvrkey> on mobile -- depends on what mobile device can provide
<yngve> depends on the mobile environment not the device
<Mez> The information sources SHOULD make the following security
context information available:
<Mez> Whether a Web page is TLS-protected, whether the protection is
weak or strong, and the reasons for the value of the protection.
<Mez> When the Web page is TLS-protected and a validated certificate
was used, whether or not a certificate status check has been performed.
<Mez> If a certificate status check has been performed, what the result
was.
<Mez> Whether the user has visited the site in the past.
<Mez> Whether the user has shown credentials to this site.
<Mez> Whether the user has stored credentials for this site.
<Mez> Whether the site content was encrypted in transmission.
<Mez> Whether the site content was authenticated.
<Mez> Logotypes embedded in certificates used, consistent with 6.1.1
Identity Signal and 5.1.4 Logotype Certificates.
<yngve> definitely the first one
... no info on cert status check when performed, but info when it fails
... (whether user visited the site in the past) no real info provided
directly in interface (security UI)
... no info about credentials provided directly in that UI (security
UI)
... do give some info about encryption used
... no info (for the MAYS) in the security UI
<Mez> User agents that provide information about the presence or
absence of Cookies [RFC2965] MUST NOT make any claims that suggest that
the absence of cookies implies an absence of any user tracking, as
there are numerous tracking and session management techniques that do
not rely on Cookies.
<yngve> may be available in the history by searching
... no info about cookies in security UI
<Mez> pause for now -- up to end of 6.2
... question for next time (when) other browser vendors present
<Mez> claudio not here next week
<Mez> anything else?
... thanks all -- esp. Opera
<yngve> can we put this (2119 compliance) on the wiki as a checkbox
list?
<Mez> probably have to -- tls was implying this earlier
... someone want to do this?
... I have pictures
<tlr> sounds plausible, yes
<Mez> sounds like not in the next couple of weeks
<tlr> adjourned
Summary of Action Items
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [13]scribe.perl version 1.133
([14]CVS log)
$Date: 2008/06/11 15:10:47 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jun/0001.html
3. http://www.w3.org/2008/06/04-wsc-irc
4. http://www.w3.org/2008/06/04-wsc-minutes.html#agenda
5. http://www.w3.org/2008/06/04-wsc-minutes.html#item01
6. http://www.w3.org/2008/06/04-wsc-minutes.html#item02
7. http://www.w3.org/2008/06/04-wsc-minutes.html#item03
8. http://www.w3.org/2008/06/04-wsc-minutes.html#item04
9. http://www.w3.org/2008/06/04-wsc-minutes.html#item05
10. http://www.w3.org/2008/06/04-wsc-minutes.html#ActionSummary
11. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0094.html
12. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
13. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
14. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 11 June 2008 16:31:44 UTC