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.
- [keyassure] End entity certificate matching, trus… Paul Hoffman
- Re: [keyassure] End entity certificate matching, … Peter Gutmann
- Re: [keyassure] End entity certificate matching, … Peter Gutmann
- Re: [keyassure] CN/SAN matching (was: End entity … Paul Hoffman
- [keyassure] CN/SAN matching (was: End entity cert… Peter Palfrader
- Re: [keyassure] CN/SAN matching (was: End entity … Jakob Schlyter
- Re: [keyassure] CN/SAN matching (was: End entity … Peter Palfrader
- Re: [keyassure] CN/SAN matching (was: End entity … Paul Wouters
- Re: [keyassure] CN/SAN matching (was: End entity … Peter Palfrader
- Re: [keyassure] CN/SAN matching (was: End entity … Stephen Kent
- Re: [keyassure] CN/SAN matching (was: End entity … Richard L. Barnes
- Re: [keyassure] CN/SAN matching (was: End entity … Jay Daley
- Re: [keyassure] CN/SAN matching (was: End entity … Richard L. Barnes
- Re: [keyassure] CN/SAN matching (was: End entity … Jay Daley
- Re: [keyassure] CN/SAN matching (was: End entity … Eric Rescorla
- Re: [keyassure] CN/SAN matching (was: End entity … Richard L. Barnes
- Re: [keyassure] CN/SAN matching (was: End entity … Martin Rex