Re: [pkix] Unclear public-key certificate definition in X.509
"Kyle Hamilton" <aerowolf@gmail.com> Thu, 01 December 2011 02:42 UTC
Return-Path: <aerowolf@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BE511E80AD for <pkix@ietfa.amsl.com>; Wed, 30 Nov 2011 18:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMWvQNLZNo1T for <pkix@ietfa.amsl.com>; Wed, 30 Nov 2011 18:42:56 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1266511E80AC for <pkix@ietf.org>; Wed, 30 Nov 2011 18:42:56 -0800 (PST)
Received: by iaeo4 with SMTP id o4so2021911iae.31 for <pkix@ietf.org>; Wed, 30 Nov 2011 18:42:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=iDO6+rvRISwKkgMl9h5cUid77v/fQ8ABSTB/z+J+Bco=; b=I6HIb0cY0uDBCMRDLNhHeaG5W1LpMbIYNHGPhYENjuPRbEC4BxiShZLaO9QaOaKY/Q GqF5Aqb/ylT15mvSi//laqBdyh/AODYM4ed0RtjPH5pwEZrDsUWHTE4+oBueZ76zYxUE Vf7ef4eqQirFMFOogv8m9bd03Px0vEUi3oozo=
Received: by 10.42.158.132 with SMTP id h4mr6442073icx.0.1322707375754; Wed, 30 Nov 2011 18:42:55 -0800 (PST)
Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id e2sm15339051ibe.0.2011.11.30.18.42.51 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 18:42:53 -0800 (PST)
From: Kyle Hamilton <aerowolf@gmail.com>
To: Tom Gindin <tgindin@us.ibm.com>
Date: Wed, 30 Nov 2011 18:42:43 -0800
Message-ID: <gvn5t9aqedn57jl6ugjezwJv4X.penango@mail.gmail.com>
In-Reply-To: <002101cb7b73$be195da0$3a4c18e0$@eu>
References: <002101cb7b73$be195da0$3a4c18e0$@eu>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="gmsm1.9.1eqgvn5t9ggf5t20e9cbv2"
X-Mailman-Approved-At: Thu, 01 Dec 2011 14:49:31 -0800
Cc: PKIX <pkix@ietf.org>
Subject: Re: [pkix] Unclear public-key certificate definition in X.509
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2011 02:42:56 -0000
On Fri, Nov 12, 2010 at 4:38 PM, Tom Gindin <tgindin@us.ibm.com> wrote: > It no longer has the problem which it had before. Of course, it's > a little odd to describe a certificate as a function of specifically the > DN of the issuer, since the critical functional dependency is on the > issuer's key pair. The original X.509 use-case was that the Directory was everything, that everything could be Distinguishably Named, and that the Distinguished Name was the correct indexing system. The problem is that the original designers hadn't had the experience of a decade of nearly universal worldwide deployment, with the format being extended into realms it was never intended to go. Perhaps X.509 could be formally decoupled from X.500, or (much like ASN.1) the data format and semantics could be moved to a different standard while the DIT bindings remain in X.509. > The CA(A) expression just confuses me, because it suggests that the CA is > a function of the subject name. Unfortunately, the original designers appear to have not thought about what would happen if you had a DN collision with multiple certificates and keys. The key to the lock is unique, which means that it also meets the requirement to be a database key. The key is the key; the binding and all the rest is just metadata. -Kyle H
- [pkix] Unclear public-key certificate definition … Erik Andersen
- Re: [pkix] Unclear public-key certificate definit… Tom Gindin
- Re: [pkix] Unclear public-key certificate definit… Erik Andersen
- Re: [pkix] Unclear public-key certificate definit… Tom Gindin
- Re: [pkix] Unclear public-key certificate definit… Erik Andersen
- Re: [pkix] Unclear public-key certificate definit… Tom Gindin
- Re: [pkix] Unclear public-key certificate definit… Erik Andersen
- Re: [pkix] Unclear public-key certificate definit… Tom Gindin
- Re: [pkix] Unclear public-key certificate definit… Erik Andersen
- Re: [pkix] Unclear public-key certificate definit… denis.pinkas
- Re: [pkix] [x500standard] Re: Unclear public-key … Erik Andersen
- Re: [pkix] Unclear public-key certificate definit… Kyle Hamilton
- Re: [pkix] Unclear public-key certificate definit… Stefan Santesson
- Re: [pkix] Unclear public-key certificate definit… Erik Andersen