IETF Logo Mail Archive

Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 24 February 2011 03:56 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 9EA2C3A67E4 for <keyassure@core3.amsl.com>; Wed, 23 Feb 2011 19:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.442
X-Spam-Level:
X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 kXRWnSY0vi8F for <keyassure@core3.amsl.com>; Wed, 23 Feb 2011 19:56:07 -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 23C673A67D6 for <keyassure@ietf.org>; Wed, 23 Feb 2011 19:56:04 -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=1298519816; x=1330055816; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |Subject:=20Re:=20[keyassure]=20I-D=20Action:draft-ietf-d ane-protocol-05.txt|In-Reply-To:=20<4D65303D.5040704@vpnc .org>|Message-Id:=20<E1PsSJq-00051V-An@login01.fos.auckla nd.ac.nz>|Date:=20Thu,=2024=20Feb=202011=2016:56:46=20+13 00; bh=9uhYRVuBQjJXQ+zvOnHidsWv8jV/V5MIO1sVEb9eJ2Y=; b=EbmLlIyIj5sOOM7XX8XwRon6r1Lb9oFaQGL+4DgY7MiTt/kuvCTrM3K7 K8PPYQqE3HSIhxRF1kOC+oKXYBPFMEgPgv6RkjdyJzMatnagKB0AJ/QYk 3aTl3s3F+x4jHU+ybtZ0Sjalg6uF491jmEBoOLAOh00jOhHfI3mGdK8bu Y=;
X-IronPort-AV: E=Sophos;i="4.62,214,1296990000"; d="scan'208";a="47623866"
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; 24 Feb 2011 16:56:46 +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 1PsSJq-0004JJ-HM; Thu, 24 Feb 2011 16:56:46 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PsSJq-00051V-An; Thu, 24 Feb 2011 16:56:46 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: keyassure@ietf.org, paul.hoffman@vpnc.org
In-Reply-To: <4D65303D.5040704@vpnc.org>
Message-Id: <E1PsSJq-00051V-An@login01.fos.auckland.ac.nz>
Date: Thu, 24 Feb 2011 16:56:46 +1300
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt
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: Thu, 24 Feb 2011 03:56:08 -0000

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

>X.509 is a standard that does not contain all of the extensions created by 
>the PKIX Working Group in the IETF. Using "PKIX" makes it clear that we are 
>talking about certificates with the IETF extensions, not certificates missing 
>them.

This is just getting excessively pedantic. Everyone knows what an "X.509 
certificate" is, standards have been specifying this for years and 
implementers have been able to work with them without having to say "An X.509 
certificate conformant to the PKIX profile encoded using X.690 ASN.1 DER 
encoding". In any case since conformance to X.509, PKIX, and DER is more or 
less arbitrary, if you truly required strict X.509 + PKIX + DER, hundreds of 
thousands/millions of certs out there would fail to meet the spec. All you 
need to say is "a vaguely certificate-shaped object", which "X.509 cert" does 
admirably.

Peter.

v2.23.0 | Report a Bug | By Email