Disposition of comments for the Web Security Context Working Group

This document appears to have successfully
incorporated the feedback we gave you on the
Requirements Note. Thank you very much.

Al
/chair, PFWG

PS:

You asked us to help you respond to a comment
you received from Sam Hartmans, with
accessibility reasoning.

http://lists.w3.org/Archives/Public/public-usable-authentication/
2008Aug/0003.html

Kenny Johar looked at this and wants clarification from Sam
before responding.

Janina Sajka made the following good point:

The sonicon for change in "security sensitivity" needs
to be timely. But what defines timely is not the visual
display but the change in the severity or sensitivity of
potential system responses to potentially-erroneous user
input. So what you should do is define (in abstract terms)
the event as the change in input exposure to risk or
hazard. Then tie prompt announcement of this in visual
and auditory media directly to that state change, not
daisy-chain the timing of one off the other. Both the
auditory and visual displays need to be
prompt in announcing elevated-risk states. Not that they
need to be strictly aligned in start time. Where possible
the start-time alignment should be achieved as well.

Let's continue that discussion on public-usable-authentication@w3.org
and not have PFWG _consensus_ in the loop to
slow resolution.

Hi,

I stumbled upon several obscure terms and sentences while reading the
spec (see list below). The terms are not defined. As far as I can tell,
they are all basic terms when one is used to dealing with security on
the Web.

Even though it contains "Security", the title looks friendly, and
doesn't seem to infer that a technical background on security is
required. Since there is no audience section, I expect I'm reasonably
well-versed into Web matters to understand the spec. That is not the
case: I understand the clauses, which is good, but I sometimes fail to
understand the rationale behind them.

Depending on the audience you are targeting, you may not want to define
these terms in the spec. That is the gist of this comment: the audience
is not defined. If your primary target is security experts, no need to
read the following list. If your primary target is user interface
developers, you should clarify them. In any case, you should probably
mention it and precise the expected knowledge before reading the spec so
that readers know what to expect beforehand.

Here is the list of security-related topics that are not so common for
other communities (well, "for me" at least, that is ;)):
- Section 5: The "TLS" acronym is actually never defined (only mentioned
in the references part).
- Section 5.1.5: "use of TLS provides confidentiality protection
services against passive attackers". What is a "passive attacker"?
- Section 5.1.5: "this can be strong evidence that protection against an
active attacker has been achieved as well". What is an "active attacker"?
- Section 5.1.5: "evidence that a man in the middle attack occurs". For
once, I know what a "man in the middle attack" refers to, but I'm not
sure everyone does.
- Section 5.2: "for both confidentiality and integrity protection". I
get the difference but that may be worth a little explanation as well.
- Section 7.1.1: same thing with "phishing" and "spoofing" although
probably known by more people.
- Section 8.2: "OCSP" stands for?

As a side note, I am totally fine with the relative complexity created
by the multiple definitions the spec already contains. Precision is good!

Thanks,

Francois Daoust,
W3C Staff Contact,
Mobile Web Best Practices Working Group.

Hi,

"To derive a human-readable subject name from an AAC, user agents MUST
use the Subject field's Organization (O) attribute.
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."

The CPS's of several CA's are clearly stating that certificates for
non-registered organisations (universities, communities, partnerships,
....) or non-organisations (individuals, ...) must not contain an
Organization attribute.

Taking those 2 things together, this guideline is discriminating against
a large amount of people and institutions.

My current idea to somewhat solve this problem is to use either
Oraganization(O), or Surname(SN) + GivenName(GN) in case O is not available.

Best regards,
Philipp Gühring

I have finished reviewing the July 24 draft of the user interface
guidelines. This is excellent work. However I do have a couple of
comments, the first of which I'll raise in this message.

Section 5.1.4 requires that if a user agent is going to render both an
audio and visual logotype, that the rendering by time synchronized so
they both start at the same time.

Outside of accessibility contexts, this is a fine requirement.
However, I'm familiar with a number of Screen Readers (software
designed to make resources accessible to blind users) where this
requirement would be problematic. In particular, on Windows (for
products such as Window Eyes, JAWS and Microsoft's Narrator), for Unix
(products such as Orca) and Mac (products such as Voice Over),
rendering of the audio interface is handled by a separate software
component than the visual interface. The audio interface has access
to special accessibility APIs to get access to the DOM, security
context and other information.

So, it would be very difficult in accessibility contexts to
synchronize the rendering of these two components. I suspect that if
people implement this requirement they will do so by moving the audio
rendering into the main browser rather than the accessibility
component. That seems highly problematic, because it separates
rendering of the logotype from rendering of other security context
information. The information is synchronized visually, but for those
who use the audio user interface, this will mean that logotypes will
be rendered at some random time while the page loads, out of
synchronization with any rendering of signals in section 6. As a
result, it seems like techniques such as using a different voice for
security context information would be ineffective at preventing
spoofing of the logotype. An attacker could simply play the logotype
sound at any point in order to spoof an audio user.

To provide a good security experience for audio users, I think it is
important that the logotype be rendered along with other audio
security context information, regardless of when that happens or
whether it is synchronized with visual indicators.

I think the easiest fix is to remove the requirement for
synchronization. If that is problematic, then scope the requirement
to cases where both logotypes are rendered outside of accessibility
contexts and suggest that accessibility API for browsers provide a
mechanism for screen readers to suppress the browser's own rendering
of the audio logotype. Screen readers are already security sensitive;
allowing them to configure chrome is no worse than any other trusted
component.


Thanks for your Consideration,

Sam Hartman
Principal, Painless Security LLC

Forwarded at the author's request.

The author has one comment that I kind of agree with fairly strongly.
The current document does not handle the issue of key life cycle
management for self-signed certificates well. I tried to see if the
security community (in particular the security directorate) within the
IETF was interested in giving you guys some guidance here, but found
no takers to try and put together a consensus.

Things I'd consider if I were giving guidance in that space would include:

* expiring the binding between a site and certificate when that certificate expried
* allowing one certificate signed by a particular root certificate that does not chain to a trust anchor to replace another chaining back to the same root


---

Hi Sam,

Sam Hartman wrote:

> Peter, list, the W3C W Web Security Context working group is in the
> final week of a public last call on their user interface guidelines.
> These guidelines take a lookboth at the balance between EV-certs and
> at user interface for security indicators.
>
> Comments need to be received by September 15. The draft is at
> http://www.w3.org/TR/2008/WD-wsc-ui-20080724/ and my take is at
> http://www.painless-security.com/blog/2008/08/w3sc-lc/ .


Hmm. I read that. I regret to say I find it unlikely anyone from
the user interface community will find it useful. Here's my
comments. Feel free to forward them to someone, I'm not part of the
W3C, and I have little clue about the context. I'm sure that shows...

First the good one, then the rest.



Promoting Petnames would be a substantial improvement in UI
practices. This document more or less supports them, but, unlike
its promise, does not describe why they are so useful, and
importantly when to use them (suggest to user) rather than any
alternate. We are very far away from useful guidance.

In contrast to petnames, there is little commentary on key
continuity management. These are very close to petnames, is the
point that we may as well just implement petnames?



Overall. The document is very hard to read. It is written in
extremely difficult language, uses many definition of specious
utility, and this use of internal code hides its essential
recommendations.

Until I realised that this was written by PKI developers for other
PKI developers, I was appalled. It was not written by user
interface people and not for user interface people. It has
mountains of PKI assumptions, truisms and commercial aspirations in
it, and by the time we get to the brief user interface guidance in
sections 6,7 the way is lost.

At least I figured out that much. So, probably, it could best be
fixed by changing the title to "Guidelines for PKI Developers" and
starting again, if there are user interface people who want some
guidelines.




3. Conformance seems inappropriate. How can one be conformant with
Guidelines? What happens when a UI developer finds a new way of
doing things? Is the book on user interface design written?

It would seem far better to say "We don't know how to do this. But
here are some top tips..."

3.3 It mixes terms and standards inappropriately. How can
"advanced conformance" be construed to be all "SHOULDS" in a
Guideline for user interfaces? It makes no sense.

3.4.2 This obsession with "strong" TLS is misplaced. No phisher
ever worried about it, why should we?

3.4.3 "broadly accepted practices <-> augmented assurance <-> MUST
do this..." pushes the agent to make decisions that are well beyond
its capability.

The notion that a browser or equivalent would create a separate
class of "augmented" versus "validated" certificates has to be
treated with great suspicion. At a minimum, the browser's legal
counsel needs to be involved in the entry into the active security
process of the user. It is not a thing for browser developers to
treat as "just another setting in the profile".





4.2.1 Primary & Secondary seems over-strained. What is wrong with
agent-directed and user-initiated actions? Its use in the text
indicates a specious distinction that then took on a life of its
own. It is entirely a mystery as to why the robot is primary and
the user is secondary, but there has to be an inner message here.




5.1.2 this is tortured. As a matter of legal interpretation, the
"MUST use O field" makes for a claim that "companies can be
identified better than individuals" which is a nonsense.

"augmented assurance" seems to be a shoe-in for EV. That's no
problem, but not everyone agrees that EV should be given special
treatment. especially, the conclusion that "giving some company
some subsidy" is hard to avoid if it involves special treatment.
6.1.2 concurs with "special treatment".

5.1.3 this is getting more tortuous. The world is divided into
"Ordinary Validated certificates" and "augmented certificates" ...
and the former are "domain validated" only, attests to a binding
between a domain name registration and a key pair; additional
certificate attributes are often not validated!!!!

This document appears to have swallowed the EV kool-aid. It appears
to have sided on the EV group in order to support the barriers to
entry in the CA business.

5.1.5 Incorrect: "In both situations, use of TLS provides
confidentiality protection services against passive attackers. No
binding of a third-party asserted identity to the cryptographic key
is achieved."

SSCs can provide protection against active attackers where key
continuity management is in place. The asserted identity is bound
by the 1st party, not a 3rd party as with CA-signed certificates.


5.1.6 "When the user assigns a petname, the petname presentation
implementation MUST warn the user if the chosen petname is similar
to one currently in use."

Can't use MUST to enforce a similarity... SHOULD be SHOULD. (there
is a difference between a bug and a user interface guideline!)

...

Proper Reference to petnames is needed. I would suggest:
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html

5.2. Worrying about export ciphers and TLS "known flaws" is a joke.
Their presence or otherwise has never stopped phishers exporting
users' money across borders. They are nowhere near the user
viewpoint nor understanding. We should be focussed on validated
security threats, not the bogeymen from the last century.




6.1.1

"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. Otherwise, it MUST
at least be available through secondary user interface."

This really tears the rug from underneath all the security
foregoing. As this provides an option to bury it in some "special
user-directed interface" it essentially says "do whatever you want."
The rest is equally problematic. Here is what I reduced it to:

=============
The identity signal SHOULD appear in a consistent visual position.
Web Content MUST not obscure security chrome

User interactions to access this identity signal MUST be consistent
across all Web interactions facilitated by the user agent.

If the Web user agent has no trustworthy information about the
identity of the Web site that a user interacts with, this MUST be
clearly indicated.

If the unauthenticated or untrusted sources are displayed, and a
positive identity is available, this must also be displayed and
related clearly.
==============

Now, obviously some subtlety might be missed in the above, but
that's a subtlety that will clearly be missed by any user interface
developer, as well.


6.1.2

Weird. "AA"s do not include the certificate issuer's name, so their
pedigree before the user is unknown. How is the user to evaluate
whether the claim means anything?

Meanwhile, the validated certificate result MUST include the
Issuer's Organization field. So this is stronger than the AA, for
the user, because the entire claim is laid out. This is how it
should be, but I wonder if the author made a mistake?

Whether you lay logo types out or not needs to be better stated. At
the moment, it is couched as a "reward" for using an AA. Entering
into commercial battles for market space is not a wise thing for a
standard to aspire to.

Rather, there is should be something like:

===========
"A clear signal such as a consistent colour should be used for each
level of validation (e.g., augmented, validated, petnamed, KCM, SSC,
plaintext HTML, warning, etc.)."
===========


"Note that this behavior does not apply when self-signed
certificates or certificate chains that chain up to an untrusted
root certificate are used."

So, what is the user interface guideline for this? Or is this not a
user interface guideline, but a different document? It should look
like this:
==============
"During interactions with an unknown SSC, the agent shows:
* the basic information
* a signal of caution
* a choice to accept and petname, if implemented
==============


6.2 Seems reasonable!!!!

6.3 So, the TLS indicator is able to light up if only signed, or
only encrypted, or some combination of above?

TLS does several things. These things are only related in the minds
of the protocol engineer, not the minds of the user.

There should be a separate indicator for IDENTITY and another
ENCRYPTION.

6.4.1

"Error signalling that occurs as part of primary chrome SHOULD be
phrased in terms of threat to user's interests, not technical
occurrence."

No. the developer has no clue what the interests of the user are,
and doesn't even know what site she is on. If the developer tries
to guess what her interests and threats are, he ends up confusing or
offending the user, and probably reducing the overall security.

This is why the original model was about "simple."

Instead, focus on claims that the user can understand. E.g.,

"The CA XYZ states that this site is ACME Inc."

OR:

"There is an error; although the site identifies itself as ACME,
the domain is from www.someoneelse.com. This could be an attack."




7.2 specious reference:
https://financialcryptography.com/mt/archives/000179.html



8.3 Hooray!

A couple of comments regarding the wording of a paragraph.

"User agents SHOULD store the state of certificates that were previously
encountered. (specifically, whether or not a site previously presented a
validated certificate). 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. For purposes of this requirement, browsing history
information includes visit logs, bookmarks, and information stored in a
user agent cache."

This sentence requires UAs to store the certificate information until
other browsing history information (specifically bookmarks) is deleted. As
we know that users never delete their bookmarks, the conclusion must be
that the certificate information can never be deleted.

The intention should be that the certificate information gets stored along
with other historical data as long as the user/UA keeps this around.
Bookmarks in themselves are not historical data, though bookmarks may
contain historical data such as time created, last visited, favicons (the
favicon might contain a timestamp) and other. Different types of
historical data might be treated by a UA in different ways (expunged at
different schedules for instance), so treating certificate data the same
way as all the other types might not be possible.

I propose a rewrite and clarification of the paragraph, particularily with
the intention. As the paragraph stands now, a UA cannot let the user
manually expunge certificate information only, as this would be in
violation of the MUST NOT clause. Proposal follows:

"User agents SHOULD store the state of certificates that were previously
encountered. Such state would typically include at least whether or not
the certificate the site presented was valid, and may also include what
the issues were with it (if any), protocol information, a fingerprint of
the certificate and any other information for the purposes of evaluating
security relevant changes of behavior. This information MUST be treated by
the user agent under the same privacy and caching policies as other
browsing history information, such as visit logs, timestamps in bookmarks,
cookies, and information stored in the user agent cache."

> Subject logotypes derived from certificates SHOULD NOT be rendered, unless the certificate used is an augmented assurance certificate.

why is this a should not instead of a must not?

Lisa Dusseault wrote:
>> Although this is an external spec, it would be great to get a
>> couple of IETF reviewers. I'll send this to secdir as well.
[...]
>> The Web Security Context WG announces the publication transition of
>> Web Security Context: User Interface Guidelines.
>> Review ends on on September 15 2008.

All: I reviewed wsc-ui for the IETF APPS area; review is
attached. For any follow-ups, please CC me to the email
since I do not subscribe to the public-usable-authentication@w3.org
list. Thank you.

Review: Web Security Context: User Interface Guidelines,
W3C Working Draft 24 July 2008
Review date: Sept. 3, 2008
Due date: Sept. 15, 2008
Reviewer: Vijay K. Gurbani <vkg@bell-labs.com>

Global: At various places, the draft refers to RFC 3280. That
RFC is obsolete, having been replaced by RFC 5280.

Nit: In Section 5.1.2 second paragraph, second line, small typo:
s/document but/document, but/

The rest of the comments refer to specific sections. In crafting
my feedback below, I quote the specific text in the section first
by indenting two spaces, and follow that with the particular comment
I have on that text.

Section 5.1.2:

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.

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.

A couple of paragraphs before the above quoted paragraphs, it is stated
that a Web user agent may adequately trust a certificate if it is
specially marked using an OID, for instance. But yet the two paragraphs
quoted above appear to be making a case against that statement by
implying that a Web user agent MUST only trust a trust anchor using some
OOB means. So, which is it: an OOB means or a well-known OID?

Section 5.1.2:

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.

What happens if a certificate's Subject field is empty, but the
SubjectAltName extension is marked critical and the subject's
identity is specified in the SAN field? All things being equal
(i.e., an OID marks the certificate), would such a certificate be
considered trusted?

Section 5.1.5:

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

Just curious: do we need to specify how many times the site has to
present the same self-signed cert before being considered trusted?
I think ssh asks for confirmation from the user on the first instance;
after that, connections to the same ssh server are deemed trusted.

Section 5.1.6: I have not used petnames, nor do I know much about their
usage in the context of this document, so treat the rest of this comment
as feedback tinged with curiosity from someone uninitiated with the
workings of W3C and unaware of how pervasive the petname concept is
in that domain (certainly, I do not think I have ran across a current
browser that uses petnames in its chrome.) Please treat this as a
pure comment and not anything that needs resolution.

It seems to me that the petname is a concept layered on top of the
information present in X.509 certificates. As such, it is a level of
abstraction above the X.509 certificate. Especially, the petname
implementor would have to account for wildcards, delegation, etc.
If care is not taken to write a good implementation, then security could
be -- I think -- compromised by someone modifying the contents of the
petname database, or by other means.

If any action item results from this comment at all, it would
be along one or more references on more information into the
petname concept, especially any papers that outline the threat
model of using such a concept. I Googled and ran across
http://www.w3.org/2005/Security/usability-ws/papers/02-hp-petname,
but that does not contain a threat analysis of this concept. It
does, however, explain very well the concept of a petname.

Section 5.4.1

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.

Suggest to clarify what "these interactions" means. Do you mean that
information derived only from self-signed certificates must not be
presented as trustworthy? Or do you mean that information derived from
certificate issued by a CA whose certificate path has been verified is
also untrustworthy? I think you mean the former, but a clarification
will help (as an example, the paragraph right after the one I quote
above makes it abundantly clear that "these interactions" consist of
deriving identity information from untrusted certificates.)

Section 6.1.1

o 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 or a
petname), then it MUST include an applicable DNS name retrieved
from the subject's Common Name attribute or from a
subjectAltName extension.

The PKIX WGs view is that DNS names should not appear in the CN
but rather in the SAN extension. That said, it is the case that
existing certificates in use today for web traffic do carry a
DNS name in the CN attribute. To future proof this specification,
you may want to indicate that if a DNS name is not found in the
SAN (or if the SAN is empty) and there is a DNS name in the CN,
then the DNS name from the CN must be used.

Another aspect to consider is what happens if there are multiple
identities in the SAN? Some may be email identities and other
DNS identities. Any guidance on what the implementation should
do when faced with multiple identities in SAN would be helpful.
As a start, implementations should look for a DNS identity in
the SAN that matches the URI used to reach that resource, keeping
in mind wildcard matching (since this is apparently allowed in HTTP.)

Section 7.1.1
A trusted path can be established between a web user agent
and the user through the use of a secret shared between the
user and the agent.

Here, do you mean that a trusted path can be established between a web
*server* and user? When I read "web user agent", I automatically
think of the browser; but the discussion in Section 7.1.1 appears
to pertain to a web server, especially with references to phishing.
Or am I missing something?

That's it.

Thanks,

- vijay

The July 24 user interface guidelines draft references RFC 3280 as the
certificate and CRL profile. This document has been obseleted by RFC
5280. Having considered the changes between RFC 3280 and RFC 5280, I
believe that the newer document would be a better reference for this
specification.

http://www.w3.org/TR/2008/WD-wsc-ui-20080724/

> user agents, such as plugins, extensions, and others; they are summarily called
> plug-ins, extensions, call outs to external systems which render particular document

plugins/plug-ins (English favors the latter, coders are lazy and use
the former, please pick one :))

> behavior might be determined by scripting, stylesheets, and other mechanisms.

and => or

> anchor is authoritative. Relying parties use trust anchors to determine if digitally

is "Relying parties" a _defined_ term? it seems awkward otherwise....

> Trust anchor installation is typically handled by Web user agent vendors ,systems

the , is on the wrong side of the space

> trust anchor update is therefore often handled as part of Web user agent or operating system software update.

update => updates

> for a single session, sometimes for all future sessions involving that certificate.

Firefox 3 ties a certificate to a host+port.

> some process that adheres to the requirements of an augmented asurance specification

assurance

> user agents MUST NOT consider the certificate as an augmented assurance certificate,

is there some reason not to write AAC or Augmented Assurance Certificate?

> [Definition: An HTTP transaction is strongly TLS-protected if it is TLS-protected, an https URL was used, strong TLS algorithms were negotiated for both confidentiality and integrity protection, and one of the following conditions are true:]

the transaction is not the result of a transaction which is not
strongly TLS-protected.

> warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used.

above? you're in 5.4.2...
I think you mean "higher" or "greater". Above in a document to me
means printed document order (closer to top) and not some more
abstract thing.

> 5.4.3 Redirection chains

> a user agent such as a smart phone, air plane seatback or TV set which has a usage

individual LCD screens on airplanes

> Subject logotypes derived from certificates SHOULD NOT be rendered, unless the certificate used is an augmented assurance certificate.

why is this a should not instead of a must not?

(i ran out of energy and am sending this now, hopefully it's useful)

http://www.w3.org/TR/2008/WD-wsc-ui-20080724/

initial spell checking after visual inspection flagged a word is done
by loading the text into data:text/html,<textarea rows=60 cols=85> in
Firefox 3.0.1 (en-US) and just looking for red squiggles.

> 6.1 Identity and Trust Anchor Signalling
> 6.4 Error handling and signalling

google says the web favors signaling 3:1 (Firefox says signalling
isn't a word{).
Wikipedia says:
signalling (UK spelling) or signaling (US spelling) has the
following meanings:

> [WSC-USECASES] documents the use cases and assumptions that underly this specification.

underlie or underlay

> Mike Beltzner, Joe Steele,Jan Vidar Krey, Maritza Johnson, Rachna Dhamija and Dan Schutzer.

space missing before "Jan"

> It has also benefitted from general public and working group commentary on earlier drafts.

benefited

> This specification also addresses products that might incporate changes to a web

incorporate

> acceptance was caused through a user interaction that happens whlie the user is

while

> those roots embody augmented assurance and can therefore be treated more favourably
> both display the "padlock" security indicator, and a possible "favorite icon"

As an American, I'd expect favorably....

> The identity of the top level resource vouches for the content of all dependant

dependent

=
> This specification addresses Web user agents as one class of product.

typically I expect "class of thing_s_" do you mean "a product class"?`

> 3. What broadly accepted practices are considered sufficient for a trust anchor to be deemed augmented assurance qualified.
> Web user agents MUST establish that a trust anchor is [Definition: AA-qualified ]

use "augmented assurance qualified" or "aa-qualified" but not both :)