[Servercert-wg] Displaying secure sites to Internet users

[Ryan Sleevi]

Hi Christian,

It's a bit confusing to suggestion "Encryption alone is just one piece of
the puzzle.". As noted with to others, if you'd like to productively
contribute, to offer new or useful insight, it might be useful to sit down
and define a problem.

It should be noted that defining a problem is not about saying "You don't
use my solution". For example, saying "Corporate identity is not displayed
by browsers" is not a statement of a problem, it's a statement that a
preferred solution is not adopted. By being thoughtful, clear, and concise
about the problem to solve, we can then discuss the appropriate approaches
and technologies. It's important to remember that certificates are not the
only means of expressing identity, and TLS is not the only means of
delivering certificates, so we know that any discussion of identity well
exceeds what this Forum is qualified to discuss.

Additionally, do you have any suggestions on how to ensure the identities
expressed in certificates today are reliable? We have ample evidence that
the information presently expressed in EV certificates cannot be relied
upon, and that the standards (such as the EV Guidelines) do not provide the
necessary or sufficient guidance to ensure the information is reliable. It
would be interesting to see proposals on that, based on the lessons from
the many CA misissuance events. If you're not familiar with them,
https://wiki.mozilla.org/CA/Incident_Dashboard is an excellent collection
of systemic issues, which have affected the majority of EV certificate
issuers (by volume and by reliance), and it'd be essential that prior to
any continued discussion of certificates, these issues be comprehensively
addressed. This seems like it will take multiple years, and given that few
(if any) CAs are stepping forward to systemically ensure there's a
consistent level of validation, so that relying parties can have
confidence, so it might be more productive to focus on that first. After
all, what's the point of discussing identity here in the Forum, if, as is
obviously demonstrated, the EV Guidelines does not provide any assurance
that CAs can be relied upon to validate it consistently and correctly

On Fri, Nov 15, 2019 at 10:58 AM Christian Heutger via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi,
>
>
>
> if all of that fail in your opinion, what’s your recommendation? No
> identity at all is no solution. Encryption alone is just one piece of the
> puzzle.
>
>
>
> Regards
>
> Christian
>
>
>
> *Von: *Burton <burton at typewritten.net>
> *Datum: *Freitag, 15. November 2019 um 14:18
> *An: *Christian Heutger <ch at psw.net>, CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>
> *Betreff: *Re: [Servercert-wg] Displaying secure sites to Internet users
>
>
>
> I don't agree.
>
>
>
> Moving back to an identity type security indicator is a bad idea. It's a
> bad idea because extended validation was an identity type security
> indicator and it has all sorts of issues and that caused it to fail.
>
>
>
> Social media check marks are now becoming an issue because people are
> mistaking them are status symbols not identity and even then check marks
> are not good identity status as there has been many instances of accounts
> with check marks being used for phishing.
>
>
>
> Doing a traffic light identity security indicator has been kinda been done
> in IE7 (green: EV, yellow: Mixed content / revocation checks, Red:
> Untrusted / Bad certificates ) and didn't work properly. Also using traffic
> light colours for identity is a bad idea for people with colour
> disabilities.
>
>
>
> Using trademarks are identity status might work for large companies but is
> largely unfeasible for the majority of companies.
>
>
>
> Overall, identity type security indicators are a bad idea given that it
> has been tried before and failed to work as intended. Unless one can design
> an identity type security indicator that works for all users and
> is implemented the same across browsers and does what it says on the tin
> then great! Otherwise it's the same as EV and it has no chance.
>
>
>
> Thank you
>
>
>
> Burton
>
>
>
> On Fri, Nov 15, 2019 at 11:18 AM Christian Heutger via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Fully agree.
>
>
>
> And there exist indicators for the second factor of certificate based
> encryption (which wouldn’t require certificates, if encryption is the only
> reason for SSL/TLS, but by design it wasn’t), e.g. the checkmarks at social
> networks indicating a prooven profile of e.g. a VIP. And also that
> proofment is similar to what CA does and always is able to be improved, but
> it’s better than nothing and help to de-anonymize the internet on topics,
> where identity is important. Cryptography is not only about encryption,
> it’s also about integrity as well as authenticity. Reducing the number of
> information security aspects been covered by a solution may make it more
> reliable, but also remove important factors from its value. So if
> validation is not free from mistakes, it’s a worse decision to remove the
> factor at all instead of improving the factor, also in sense of demand of
> the user base. What was the bigger trouble with EV wasn’t the rare
> validation issues but that the normal end user won’t expect a green address
> bar to be able to be shown as they are not aware of the possibility of
> additional levels. So it would require a different UI indicator, which help
> the user to expect, that there could be something more, e.g. showing a
> padlock on encryption and no or a striked padlock without encryption and
> work similar on validation. I recently promoted to use colors like on
> traffic signs therefore (red = no validation, yellow = weak validation
> (DV), green = strong validation), but that seems not to been adopted. So
> the checkmark, which got common in social networks, would be a good
> alternative.
>
>
>
> Instead of companie names to be validated base on trademarks would also be
> an idea, trademarks are much harder protected than company names (also
> often impossible to prevent a company from naming themselves the same as
> existing companies), there are legal departments doing nothing else than
> that.
>
>
>
> Regards
>
> Christian
>
>
>
> *Von: *Servercert-wg <servercert-wg-bounces at cabforum.org> im Auftrag von
> Kirk Hall via Servercert-wg <servercert-wg at cabforum.org>
> *Antworten an: *Kirk Hall <Kirk.Hall at entrustdatacard.com>, CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Datum: *Freitag, 15. November 2019 um 01:08
> *An: *Paul Walsh <paul at metacert.com>, CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>, Ryan Sleevi <
> sleevi at google.com>
> *Betreff: *Re: [Servercert-wg] Displaying secure sites to Internet users
>
>
>
> Paul - +1.  Please do start drafting a problem statement.
>
>
>
> One half of the Forum’s stated Purpose at Bylaw 1.1 is “creating a more
> intuitive method of displaying secure sites to Internet users”.  Obviously,
> “secure sites” means more than simple encryption – otherwise, all the
> encrypted phishing sites would be considered “secure”.
>
>
>
> It doesn’t sound like any of these other groups are working on identity
> issues and the UI, so I’m not sure what the point would be of moving the
> Forum’s own discussions there.  And there is no reason why we can’t have
> multiple expert groups working on similar issues at the same time – perhaps
> there can be cross-collaboration over time.  Plus, I’m not keen on moving
> Forum discussions to any group that charges to be a member, and the Forum
> is already set up with bi-weekly teleconferences and three F2F meetings a
> year.  So it’s better for the Forum to work on one of our two stated
> Purposes right here.
>
>
>
> Finally, if the browsers are working together on URL UI issues outside of
> the Forum, it would be great (and much appreciated) if you all would update
> CAs in the Forum from time to time – we worked together collaboratively on
> UI issues in our early years, and could do so again.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Paul
> Walsh via Servercert-wg
> *Sent:* Wednesday, November 13, 2019 9:04 PM
> *To:* Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL]Re: [Servercert-wg] Displaying secure sites to
> Internet users
>
>
>
> On Nov 13, 2019, at 7:03 PM, Ryan Sleevi via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>
>
> During our most recent F2F, there was a presentation about ways to display
> secure sites to Internet users. Despite the stated topic, most of the
> discussion focused solely on identity expressed in certificates, which is
> only part of the picture.
>
> This limited view overlooked a number of the considerations involved in
> establishing and communicating secure connections. This prompted my
> questions of whether the proposers had examined other Standards Developing
> Organizations ("SDO"s), and if the CA/Browser Forum was the appropriate
> venue.
>
>
>
> [PW] I acknowledge what you say about other forums and the benefits you
> attribute to them, but can you please explain why you think this can’t
> happen inside this forum?
>
>
>
>
>
> Browsers are already collaborating in other SDOs with domain experts
> across industry on topics, including the display of secure sites to
> Internet users. Given the complexities of modern web security, and the
> difficulty of presenting understandable and actionable information to
> users, new work would be most usefully presented in such forums, which can
> be done without being an existing member or needing to apply to be one.
>
>
>
> [PW] Encryption and UI for website identity are very different. They
> require people with different skills. Identity UI requires product people
> and UX designers. We don’t need more engineers for this problem/solution.
> Right now we mostly have plumbers telling us why people are walking past
> our house without looking at it. They’re great plumbers, so they’re great
> at plumbing. They’re probably not the best people to tell us how to
> decorate our home though.
>
>
>
>
>
> The primary venue for this collaboration are within the W3C’s Web
> Incubator Community Group ("WICG"). It is through efforts like WICG, which
> are used to house and build interest in nascent ideas for the Web that
> solve real problems for users and developers, that mature specifications
> are created and adopted.
>
>
>
> [PW] I co-instigated the first ever W3C Incubator Group in 2006 [1] with
> Phil Archer. The WICG sounds extremely similar. Following a year of
> incubation, our project went onto a Full Recommendation Track, formally
> replacing PICS in 2009 [2]. Our Recommendation was never adopted, for
> numerous reasons, even though it had support from some browser vendors and
> other major potential implementors. Some browser vendors still use PICS
> today.
>
>
>
>
>
> An example of where browsers are already actively collaborating is on the WHATWG
> URL standard <https://url.spec.whatwg.org/>, which similarly provides the
> necessary IP protections while providing opportunities for open
> collaboration. It has already developed a number of guidelines on the more
> intuitive display of secure sites to Internet users. These guidelines,
> which have evolved through rigorous and peer-reviewed usability research,
> and combined with the deep technical expertise involved in how modern Web
> security works, reflect a number of the industry best practices.
>
>
>
> Proponents advocating for the Forum to charter a new Working Group should
> be able to articulate and explain the problem they are seeking to solve,
> and then communicate how their proposed solution fits to solve that
> problem. This approach, where the problem to be solved is clearly
> explained first
> <https://www.w3.org/blog/2015/07/wicg/#what-s-the-process->, has been
> highly successful for collaborations on evolving the Web, and is the core
> approach for most modern Web standards work. This process helps ensure the
> problem is well understood and can bring to light any faulty assumptions or
> premises, which is key to assessing how well different options addressing
> them might work.
>
>
>
> [PW] I’m pretty confident that almost everyone who needs to be involved,
> knows what the problem is.
>
>
>
> I’m happy to write a problem statement and a proposed solution to get
> something started. I’ve contributed to a lot of W3C initiatives and
> specifications and I still think this forum is the most suitable place for
> this particular work. This forum was started and built to address Internet
> Security from the perspective of encryption and identity.
>
>
>
> As a side note, how do you feel about the lack of privacy for visitors of
> the W3C Incubator Community Group Charter URI? [3]
>
>
>
>
> Given the flexibility and open-access provided, along with strong IP
> protections in place with the organizational support of the W3C, the WICG
> does seem like an excellent starting point for any specific problem
> statements and abstract proposals, as a natural evolution for long-standing
> collaborations and discussions within the Web security community. You can
> learn more about the process of making and evolving proposals with the WICG
> here <https://www.w3.org/blog/2015/07/wicg/>.
>
>
>
> [PW] We could easily put together a small team of respected independent
> industry experts from various stakeholders to help manage the project.
>
>
>
> [1] https://www.w3.org/2005/Incubator/
>
> [2] https://www.w3.org/2005/Incubator/wcl/XGR-wcl-20070220/#appendix1
>
> [3] http://wicg.github.io/admin/charter.html
>
>
>
> Regards,
>
>
>
> - Paul
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191115/0c213fae/attachment-0001.html>