[certid] Redesigning security card house?
ArkanoiD <ark@eltex.net> Sat, 20 November 2010 21:26 UTC
Return-Path: <ark@eltex.net>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 64F8F28C114 for <certid@core3.amsl.com>;
Sat, 20 Nov 2010 13:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.105
X-Spam-Level: **
X-Spam-Status: No,
score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001,
FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 MOIgioM2Z2dZ for
<certid@core3.amsl.com>; Sat, 20 Nov 2010 13:26:15 -0800 (PST)
Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by
core3.amsl.com (Postfix) with ESMTP id 471CB28C10D for <certid@ietf.org>;
Sat, 20 Nov 2010 13:26:14 -0800 (PST)
Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by
lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id oAKLR4sE011415 for
<certid@ietf.org>; Sun, 21 Nov 2010 00:27:04 +0300 (MSK)
Received: (from ark@localhost) by lebedev-225.itcwin.com
(8.14.3/8.14.3/Submit) id oAKLR4l8022352 for certid@ietf.org;
Sun, 21 Nov 2010 00:27:04 +0300 (MSK)
X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to
ark@eltex.net using -f
Date: Sun, 21 Nov 2010 00:27:04 +0300
From: ArkanoiD <ark@eltex.net>
To: certid@ietf.org
Message-ID: <20101120212703.GA31462@eltex.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [certid] Redesigning security card house?
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates
<certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Nov 2010 21:26:16 -0000
Being quite offtopic here, i still do not know a more appropriate discussion group. We are all aware that SSL does *not* actually use full x503v3 capabilities to build sane trust hierarchy. We have a "cardhouse" instead, while one flawed CA may ruin the whole system. Well, i did not consider that to be a fatal treat until i got aware of these things, just a matter of close future, despite the fact we have CAs closely affiliated with domestic and foreign ;-) (wherever point of view we take) government organizations, just some random privately owned companies, known malicious entities (like Etisalat), etc etc. There was a way to fix it: once a CA shows any malicious activity, it gets kicked out, revoked and forgotten. Now let's face it: http://www.narus.com/index.php/news/industry-news/article/209 old news, 2005, but the partnership is scary. What if not only Narus offers services to Versign, but vice versa as well? We cannot just "kick Verisign out", "all our base belong to them". There is *no place* for "lawfully intercepted SSL" in any resonably secure design. And if Versign + Narus + government decides to implement that, we have no protection at all. (expected commonplace "packet forensics" rant skipped, no need to) I think clear and visible warning on *ANY* certificate change should be mandatory requirement, even if the issuer keeps being the same and there is nothing suspicious from any point of view. Moreover, we probably need to design two things: 1) "ad hoc" cross certification web of trust (there already some efforts to bring pgp-like "cross-sign" functionality to the web) and 2) true hierarchy limiting each CA functions (say, you cannot sign "outside" certificates with corporate CA, national CA etc etc)