Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage)

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 12 October 2013 04:15 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713EB11E810F for <tls@ietfa.amsl.com>; Fri, 11 Oct 2013 21:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uP6quv4RPBGv for <tls@ietfa.amsl.com>; Fri, 11 Oct 2013 21:15:50 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8B23E11E810E for <tls@ietf.org>; Fri, 11 Oct 2013 21:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381551347; x=1413087347; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=V6dgqOX4wp/ncLBN/IGk9ltIhgS/oYDj8DyZ8BEU5Mg=; b=iVjPnaaSu8wP1LcygpEI4PyEkM+XwxFaonoSNTTJY4BP+PQUam5gL2TK tg0Xk6ymD/HxEWmBvnPvyua5p3Xy060xr8bVmLDAp6Cld0MFELHQdgxy2 T0VE4Yz72+RPsovQ2mBAwAXjMJG6B6yCAIiuNeFXZM6cpwtBTLBpGML9J A=;
X-IronPort-AV: E=Sophos;i="4.93,479,1378814400"; d="scan'208";a="217132135"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Oct 2013 17:15:45 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Sat, 12 Oct 2013 17:15:44 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: Enforcing keyUsage restrictions (was Re: [TLS] Safe ECC usage)
Thread-Index: Ac7HAbhOe9qFEnASTrW7mk5sjsiEiQ==
Date: Sat, 12 Oct 2013 04:15:44 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568ACD2@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Oct 2013 04:15:55 -0000

Brian Smith <brian@briansmith.org> writes:

>If you have any more specific information you could share regarding your
>experience with attempting strict(er) KU enforcement, it would be great if
>you could share it. (Not just Peter, but everybdoy.)

What were you after in general?  I've just encountered lots of certs with
keyUsage bits that either prevented them from being used in the manner that
they were intended for (e.g. DS for an encryption key), or were illogical (the
aforementioned keyAgreement for an RSA key), or contradictory (kU said one
thing, eKU said another).  Here's one example, from an intermediate CA using
RSA, directly signed by a trusted root CA:

 624   14:         SEQUENCE {
 626    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
 631    1:           BOOLEAN TRUE
 634    4:           OCTET STRING, encapsulates {
 636    2:             BIT STRING 1 unused bit
         :               '1111111'B
         :             }
         :           }

Peter.