Rebooting Dropsafe: March 6th 2017

Notes:

Well, today would have been Dad’s 98th birthday. I’ll drink a small toast to him, later.

Project Status:

Since I don’t really have a system for posting here at the moment, I think I’ll start with a brief list of everything that I think I am currently doing:

  • Raspberry Pi Rig: currently:
    • 6x RPi 3b in a rack, as a general compute surface
    • 1x RPi 3b in a fan-case, as rig controller/master
    • 1x RPi 3b in a passive case, as backup
  • Mana Project
    • RPi 1 for port of Mana; have finally obtained second wifi adapter
  • Soldering Project
    • RPi ZeroW + Pimoroni “Scroll Phat” dot-matrix display
    • Build & then use for
  • Half-A-Gig Onion
    • On hold, awaiting bandwidth.
  • EOTK
    • Stable, works, is remarkably quick
    • Goal is to ship stable & feature-complete 1.x version then start on 2.0
      • 2.x version will move more rewriting to Lua to reduce dependencies
  • Resurrecting old GPU Rig
    • Inherited 3x Radeon 5870 from JC
    • Unfortunately, Ubuntu stopped loving Radeon in v14 Trusty Tahir
    • Open-source Radeon drivers do not cut the mustard
      • Therefore: adventures in legacy linux and stale proprietary driver code
  • Java Experiments
    • Stalled by EOTK but that’s okay, it needed some thinking-time
  • Garden
    • Total mess.
    • Need to spend a few days sawing and stacking lumber for next winter, to dry out over the summer
    • Also need to push(@compost, shift(@compost)) which will be hard work
  • Work
    • Can wait until after summer.

An Open Letter to CA/Browser Forum re: Personal Certificates for “.onion”

Ryan, I’d like to take you up on your invitation and request that you forward the following text to the CA/Browser Forum public list, please…


Hi CA/B Forum! I’m a software engineer and one of the authors of RFC 7686; since 2001 I have maintained a personal blog and it’s overdue for a complete software refresh. I want to take advantage of Let’s Encrypt to provide normal HTTPS certificates for the blog, and I want a 100% HTTPS deployment when I am done.

I intend also to provide my blog with an Onion Address, thus my question:

On my blog I do not represent a company – I act purely as an individual; I expect to easily get a “normal” domain-related certificate from Let’s Encrypt, but as an individual I will not be able to get an EV certificate for my Onion Site as mandated by CA/B Forum Ballot 144.

This situation inhibits me from protecting my personal blog’s Onion Site with some form of Onion HTTPS certificate.

It further discriminates against my choice of software deployment as an individual.

Perhaps I could run my blog as HTTP-over-Onion and HTTPS-over-Internet, but this breaks my goal of a 100% HTTPS deployment. Clients of my Onion Site would not have access to HTTPS-only “Secure” cookies and other functionality which browsers today (or will soon) restrict to HTTPS sites, e.g. Camera & Microphone access. This would be an undesirable lack of consistency.

It is not viable to hack the Tor Browser to support an “Onion-only” CA, because only some portion of Tor traffic uses the Tor Browser; non-browser apps which use Tor would not be able take advantage of such a kludge, and thereby would not see the benefit of SSL.

In any case, “.onion” is now an official special-use TLD, and therefore should be supported by official means.

After a hint from Ryan Sleevi – plus referring to the Mozilla CA glossary [1] – I did some research and think that I need either an AV (address validation) or an IV (individual validation) SSL Certificate for my personal blog’s Onion Site.

Discussing likely use cases with Runa Sandvik, we believe that people who use Tor desire (at least) all of privacy, anonymity and integrity. The option that seems most sympathetic to all of these requirements is the AV (address validation) certificate. An AV certificate would provide an Onion Address with an SSL certificate (and thus a form of persistent identity) corresponding simply to an RFC822 email address. This would appear extremely well-suited to users of Onion-backed instant messenger software, such as Ricochet, especially those communicating without reference to “real world” identities.

The alternative of an IV (individual validation) certificate appears closer to the goals of the EV certificate, being a more expensive “absolute identity” certificate that would (per the Glossary) require a Driving License, Passport, or National Identity Card to get. This would be useful for instances where people wish to publicly attest to ownership of what they write / blog / post / publish, but would be less useful e.g. for whistleblowers operating in repressive regimes.

Frankly I see a need for both, and would be (for this case in point) happy to get one of either, but am also open to other alternatives which would not require me to register a company to bootstrap.

So, finally, the question: how may I go about obtaining a suitable, personal, Onion-capable SSL Certificate for my blog, please?

Alec Muffett
London

[1] https://wiki.mozilla.org/CA:Glossary – some extracts follow:

AV (address validation) — Many CAs issue end entity certificates to individuals for use with S/MIME email for which the applicant need only demonstrate that they own and/or control the email address named in the certificate. For example, the owner of the “jdoe@example.com” address could obtain an AV certificate for that address based on their demonstrating to a CA that they owned or controlled the email address in question, e.g., by responding to email addresses sent to an email sent to that address. We can refer to such certificates as address-validated or AV certificates.

More formally we can define AV certificates as certificates containing an emailAddress attribute or Subject Alternative Name extension with a value (or values) apparently corresponding to an RFC 822 email address, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that that address in question is owned and/or legitimately controlled by the cert subscriber, and for which the CA makes no claims as to the validity of any individual identity stored in the Common Name attribute of the certificate. Note that “AV” is not a common industry term, but is newly-coined by analogy with “DV”, “IV”, etc. Some people use the term “DV” loosely to cover this case, but arguably it deserves a term of its own.

…and…

IV (individual validation or identity validation) — Many CAs issue end entity certificates to individuals for email, SSL/TLS client authentication, and other uses, for which the applicant is required to supply some sort of evidence as to their identity (e.g., by presenting themselves in person with a copy of their national identity card). These are commonly referred to as identity-validated or IV certificates.

More formally we can define IV certificates as certificates containing a Common Name (CN) attribute with a value apparently corresponding to an actual named individual, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that that value corresponds to the individual identity of the certificate subscriber. Note that some people use “IV” as a synonym for “OV” when referring to certificates issued to organizations. However it’s arguably more clear to use “IV” to refer only to certificates issued to individuals.

Note that an IV certificate could also contain an email address in addition to the individual identity information. Mozilla policy requires that email address to be validated to the same or greater degree as for a AV certificate.