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!