Re: [openpgp] How to re-launch the OpenPGP WG

Christoph Anton Mitterer <calestyo@scientia.net> Wed, 18 March 2015 23:05 UTC

Return-Path: <calestyo@scientia.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD31A8931 for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 16:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhNP5mz5aIUL for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 16:05:05 -0700 (PDT)
Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845661A892A for <openpgp@ietf.org>; Wed, 18 Mar 2015 16:05:05 -0700 (PDT)
Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 648505FC33 for <openpgp@ietf.org>; Wed, 18 Mar 2015 23:05:04 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net
Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id 3__dj_W1Dwot for <openpgp@ietf.org>; Wed, 18 Mar 2015 23:05:02 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for <openpgp@ietf.org>; Wed, 18 Mar 2015 23:05:02 +0000 (UTC)
Message-ID: <1426719900.4249.40.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: openpgp@ietf.org
Date: Thu, 19 Mar 2015 00:05:00 +0100
In-Reply-To: <5507E916.4040307@sumptuouscapital.com>
References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <sjm3859nhe1.fsf@securerf.ihtfp.org> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-QL3GyvDkKB/jyPvXqi1I"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/sZ94C9w07MvEmNG79sn5trmbNQk>
Subject: Re: [openpgp] How to re-launch the OpenPGP WG
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2015 23:05:07 -0000

On Tue, 2015-03-17 at 09:43 +0100, Kristian Fiskerstrand wrote: 
> I fail to see how this behaviour is either dangerous,
Take 0x10 as example:
>       The issuer of this certification does not make any particular 
>       assertion as to how well the certifier has checked that the owner
>       of the key is in fact the person described by the User ID.

Implementation A: may interpret this as "can also include signatures,
                  where NO check has been made at all" and thus it might
                  use it to sign other keys (for whatever reason, e.g. a
                  key-pinning-like method), since it expects that no
                  other implementation would use such sigs anyway
Implementation B: may interpret this as "the certifier has checked the
                  identity, but simply doesn't want to tell, how well he
                  has done so"
                  Such implementation might then use the untrustworthy
                  sigs from A.

Well a bit made up,... but I guess you can see what I mean.


> The
> signatures (except for 0x11) are treated the same by the
> implementations, which is fine.
Which also shows that they're basically useless.


> The information is still useful as
> metadata when performing manual analysis of a certification network
> and depends on a published certification policy by the issuer.
I disagree, if a user wants to tell under which circumstances he
certified another user/key, hey can do so via the policy URL and in fact
this is the only way for analysis to find out what the certification
means to the certifier.

Using the different signature levels as metadata for certification
network analysis would only produce meaningful results, if all would
have agreed upon the same meaning for these different levels - which is
not the case.


>  The
> uses not being explicit in the RFC does not mean they are vague and
> ambiguous, just that they are defined on a per-context / per-CA basis
Which again is the Policy URL, but then you don't need different levels
of user sigs (at least not all of them), just do something like:
http://me.com/pgp-policy?keyfp=<the key's fingerprint> and you can give
back per signature policy information.


Cheers,
Chris.