Re: [keyassure] End entity certificate matching, trust anchors, and protocol-06

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 13 March 2011 02:50 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FA43A6A85 for <keyassure@core3.amsl.com>; Sat, 12 Mar 2011 18:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.556
X-Spam-Level:
X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jzOdQnxyZgC for <keyassure@core3.amsl.com>; Sat, 12 Mar 2011 18:50:38 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 7A54A3A6A75 for <keyassure@ietf.org>; Sat, 12 Mar 2011 18:50:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1299984720; x=1331520720; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20keyassure@ietf.org|Subject:=20Re:=20[keyassure]=20 End=20entity=20certificate=20matching,=20trust=20anchors, =20and=20protocol-06|Message-Id:=20<E1PybPT-0002mJ-Iw@log in01.fos.auckland.ac.nz>|Date:=20Sun,=2013=20Mar=202011 =2015:51:59=20+1300; bh=edtITiSHMNMiUA8VxTBmdKypeERUwY5IOl03SpNMN+A=; b=cwuRkIDI+5SK6Ffq+EHqjss2RDrXkm7S/FaiMOjPd3KA3pBHze4Uy3SB a6GV1Ey7MP8QS6wpc5BykeAeO8nJoHaFbtwhJCdwWa6HkN02dvmMGOoA9 qu/d5vlFAlXNDh/5ihuLqIZSPZTCcWL98cbEw+cygeC/KyeSHN+rHzMoP w=;
X-IronPort-AV: E=Sophos;i="4.62,309,1296990000"; d="scan'208";a="50661164"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Mar 2011 15:51:59 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PybPT-0003zT-IA for keyassure@ietf.org; Sun, 13 Mar 2011 15:51:59 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PybPT-0002mJ-Iw for keyassure@ietf.org; Sun, 13 Mar 2011 15:51:59 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: keyassure@ietf.org
Message-Id: <E1PybPT-0002mJ-Iw@login01.fos.auckland.ac.nz>
Date: Sun, 13 Mar 2011 15:51:59 +1300
Subject: Re: [keyassure] End entity certificate matching, trust anchors, and protocol-06
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Mar 2011 02:50:40 -0000

Paul Hoffman <paul.hoffman@vpnc.org> writes:

>You may be surprised both by the restrictions that PKIX puts on us (namely
>that self-signed certificates are always CA certificates) and by the measures
>suggested in -06 (format validation on end entity certificates is relaxed to
>allow self-signed certificates for end entities).

This particular issue has been an ongoing problem for years.  More than a
decade ago I proposed the ability to create straightforward self-issued
certificates:

http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

but it was nixed by the PKIX chair with the comment "we're not going to turn
X.509 into PGP".  The need for this is as real as it was ten years ago, but
I'm not sure how to progress it (I was told at the time that it would be seen
by the IETF as falling within PKIX' purview, and they'd never allow it to be
published, which is why I abandoned work on it).

On a more general note, it's not surprising then that the current draft has to 
incorporate wording to say that you have to ignore the PKIX requirements.

Peter.