[therightkey] Principle of least privilege...

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 02 April 2015 17:46 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716081B2DA5 for <therightkey@ietfa.amsl.com>; Thu, 2 Apr 2015 10:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.422
X-Spam-Level: *
X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JmznAVmcF2A for <therightkey@ietfa.amsl.com>; Thu, 2 Apr 2015 10:46:51 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F4E1B2D94 for <therightkey@ietf.org>; Thu, 2 Apr 2015 10:46:50 -0700 (PDT)
Received: by lbbug6 with SMTP id ug6so64739455lbb.3 for <therightkey@ietf.org>; Thu, 02 Apr 2015 10:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=vxm3m+xC9+QDFpaMG7+/53I5DvpeiQnHSCSZeBBre4g=; b=kvw23RA+uys9LrwWmurlxKaurYAZbMRnzaUAN5/3hiZU/iN1gMS3+mm7RtO5V1tQCH Ec6YPcYzPwFbIEmgmq3QAZ1v/1gGCfbcWh6kVA1U69/c248mk7u9rg0qd+5mTSStyT0/ zWVcKOX96rM3YB/hFFpQbrAMjDPsaWht+zKamCMrR7/zlCb/4r+SjsnhRngDa8BWwSjx oL+GVYmKv3htjBclM0cuZjFsi7wLtJyJkzuB+YfeN9b1tgrLlMc0oQwQFmSzFaixuepE hi074UoI1iamj2gH+BH9P67Wg6ZFAIBGgtLnZtW1FAtPHpreS4UPH7U3uGzPIyTwYiZC XOZQ==
MIME-Version: 1.0
X-Received: by 10.152.171.5 with SMTP id aq5mr18804067lac.91.1427996808511; Thu, 02 Apr 2015 10:46:48 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.147.165 with HTTP; Thu, 2 Apr 2015 10:46:48 -0700 (PDT)
Date: Thu, 02 Apr 2015 13:46:48 -0400
X-Google-Sender-Auth: 83th_buq2rOQyTLlxIjXBCJyN_g
Message-ID: <CAMm+Lwjc+_VubsJ+Yfx_356YV+1bB3tChLU1HdAc8cekbnX=xQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "therightkey@ietf.org" <therightkey@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/therightkey/ubXo3t_jhz3ONzVA0mdEEl9mrb4>
Subject: [therightkey] Principle of least privilege...
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2015 17:46:53 -0000

CNNIC is an opportunity to learn from mistakes.

One conclusion I draw is that PKIX and OpenPGP have very different
expectations of trust providers. We could express OpenPGP key signings
as PKIX certificates but this would be a mistake. They are better
understood to be 'endorsements' rather than 'certificates'.

Another conclusion is that there is a lot of infrastructure in the
PKIX world that should not be abandoned or ignored lightly. Mistakes
are not evidence of a flawed system unless there is no adaptation. In
the wake of DigiNotar the Web PKI has changed significantly and we are
also in the process of adding TRANS.

A possible model for future PKI is to think in terms of a victorian
skyscraper. There is a steel structure and a brick exterior. Both are
necessary for the structure to stand up.


I think we need to rethink how the principle of least privilege
applies here and make sure we are doing everything we can to minimize
risk.

As a matter of policy, no cert should ever issue for a private key
that is not under the direct control of a CA unless one of the
following apply to the corresponding cert:

1) The other party has CP, CPS and full audit for operating a CA.
2) There is a name constraint.
3) It is an end entity certificate.

Further no private key should ever be in a network accessible device
unless the following apply:

1) There is a path length constraint that limits issue to EE certs.
2) It is an end entity certificate.