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

Meeting record: WSC WG weekly 2008-06-04

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 11 Jun 2008 18:31:06 +0200
To: public-wsc-wg@w3.org
Message-ID: <20080611163106.GA2046@iCoaster.does-not-exist.org>

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


A text version is included below the .signature.

Thomas Roessler, W3C  <tlr@w3.org>


                                 WSC WG weekly
                                  04 Jun 2008


   See also: [3]IRC log


          joesteele, MaryEllen_Zurko, +47.24.16.aaaa, Thomas, jvkrey,
          claudio, Tyler, PHB, +1.202.386.aabb, ifette, +1.312.933.aacc,

          Luis_B, Serge_E, Dan_S, Bill_D, Johnathan_N




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

   <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

   <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

   <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

   <yngve> re: pt1 we don't store history of certs previously used on a

   <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

   <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

   <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

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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

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

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


   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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:21 UTC