[Trans] pretty URIs whose integrity is associated to transparent certificates

Eduardo Robles Elvira <edulix@agoravoting.com> Sun, 21 September 2014 11:37 UTC

Return-Path: <edulix@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 50A071A00A6 for <trans@ietfa.amsl.com>; Sun, 21 Sep 2014 04:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7vwZkfWloWO6 for <trans@ietfa.amsl.com>; Sun, 21 Sep 2014 04:37:01 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87651A00A5 for <trans@ietf.org>; Sun, 21 Sep 2014 04:37:00 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id l18so449480wgh.21 for <trans@ietf.org>; Sun, 21 Sep 2014 04:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=33iuQQSHaOrMcc1jXRIf5IhV50nkJyZ4x/vUFyGL/7E=; b=OphtMpqPE1qrHkH2VJRdROvpJTXdvBm1+gfLTW0MICwCjMXVqbfysO/fThn4jsPcNI Rj05lz4Pa4NwypSwZfmcNr0y+ACTHuw0eMmPRl2OH0FblOehT3cRQk2fLCBk64L+pc/d Nx9T5ojpfTRn9Jr3tc+WaXthGobh0pwrGgyBZZEQnsap03t+RDhAp3XZeVhQUgdhggo/ Au6HV50katqB7tCJfezA7VK2FGmgEu5sjR0vG51nvD0dmHQzlNWMJVcdDMVQ8VEciBDb jt4bX2pMMc1E3TYhvwEyPrhuyc6i/xKnHjz+AVz4d0wT3i+6rrF2EgpyNgGqJap3EQ+z 9BOw==
X-Received: by with SMTP id mo15mr12995189wjc.6.1411299419105; Sun, 21 Sep 2014 04:36:59 -0700 (PDT)
MIME-Version: 1.0
Sender: edulix@gmail.com
Received: by with HTTP; Sun, 21 Sep 2014 04:36:29 -0700 (PDT)
From: Eduardo Robles Elvira <edulix@agoravoting.com>
Date: Sun, 21 Sep 2014 13:36:29 +0200
X-Google-Sender-Auth: 3dLvXI5msEBj4IG05gJVCimTlVM
Message-ID: <CAHwZu3cyzO=C8dnM+=wAHVUyytc+4t8cAiH0cLBS939TtRLJhQ@mail.gmail.com>
To: trans@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/8I4zKCxesT_rQpCks4VJVzPW_RY
Subject: [Trans] pretty URIs whose integrity is associated to transparent certificates
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Sep 2014 11:37:02 -0000

Hi everyone,

I will start right away recognizing that I'm not an expert in this
field, and that I might be proposing something dumb because it's
already being taken care of in some new promising standard I don't
know of, that resolves the issue in a much better way. Or it might
well happen that this is not the correct mailing list (maybe it's more
related to X509 extensions, or maybe public-webappsec mailing-list? I
just thought that it might be of interest to discuss it here). Please,
forgive me if that's case, as I'm new here.

Investigating, I recently found out that rfc6920 [1] ("Naming Things
with Hashes") defines a scheme for naming URIs with hashes too, by
creating the ni URI scheme name for .well-known URIs (rfc5785) [2].
That allows to have URIs that define incontestably the data they point
to. In my opinion, that's a very powerful and important concept,

A problem with ni .well-known URIs is that they look like this:


That's not very user friendly, and reduces the scope of where this
kind of secure URIs can be used. Hopefully, we can find a reasonable
and secure way to solve that problem. That's the aim of this thread.
The idea is to convert that link into something like the following,
without loosing much security:


Thinking about it, I thought about Certificate Transparency. As you
know, CT logs publicly and transparently the X509 certificates
associated to web domains. And X509 has an "Extensions" field, so this
gets interesting. A first approach proposal, which might well end up
not being the best one, is the possibility of creating a new X509
extension that refers to the hash of a file that contains the list
URIs and their integrity meta-data. For example, the file might
contain a line like this:

<alias uri="https://agoravoting.org/user-friendly"

And the X509 certificate could contain something like [3]:

    Identifier: Named Information URIs aliases x.x.x.x
      Critical: No
      Aliases integrity:

Some thoughts about this solution:
* This proposal is actually not directly related to CT, but using CT
together the proposal would give it a reasonable level of security,
that's why I comment it here. Also, I comment it here because others
might also try to use certificates extensions/meta-data to take
advantage of the security features of CT. Maybe this has been
discussed already before?
* It's obviously not as secure as inserting the resource's hash in the
URI, but it provides an interesting mix of security and usability.
* Provides graceful degradation: if your web browser (or any software
accessing an URI) does not support this X509 extension, it will just
not check the integrity of the resource, but otherwise the URI will
work just fine.
* Integrate well with current Internet security architecture (CAs and such).

It has some drawbacks too, though:
* when registering the certificate you need to have the pre-generated
all the aliased URIs. And if you want to modify the aliases file, you
need a new certificate. Well, if you want this level of security and
usability with current Internet infrastructure, this could be the
price of it.
* Both browser vendors and CAs would have to add some kind of support
for this X509 extension for this to work well.

All in all, as I said I just wanted to open the debate with a
proposal. Any thoughts?

[1] http://tools.ietf.org/html/rfc6920
[2] http://tools.ietf.org/html/rfc5785
[3] I haven't added information as to where to find the integrity file
and only its integrity metadata because I think that a good way to
solve this is to find the file with its well-known ni URI, but anyway
that's an implementation detail.
Eduardo Robles Elvira     @edulix             skype: edulix2
http://agoravoting.org       @agoravoting     +34 634 571 634