IETF Logo Mail Archive

Re: [TLS] Questions on certificate_extensions...

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 15 February 2017 01:08 UTC

Return-Path: <Andrei.Popov@microsoft.com>
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 04D1812994F for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 17:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level:
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 Ajh-9XdJs-ng for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 17:07:59 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0113.outbound.protection.outlook.com [104.47.41.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0F9129460 for <tls@ietf.org>; Tue, 14 Feb 2017 17:07:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Raw+RDBTu6ZACSRdjMui6qiZfRcuiEJaqiV5UaQmjqc=; b=cSUHfETPvVjmMQTDnpIYiT1QDHFJ3YaZVV1VZbQzPsn5qwNfRpwiub8/apPhtjmIWS9o+5b/IUXy043KtdMbu/E+z05mll9trEPSE+1WC4RfU+q54i9Wsh+lQJSiW2LoDfT2qDDdUx3zy+XczsfnNOgOscDJoU6hDOBqEmoxnoE=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 01:07:55 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 01:07:55 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Dr Stephen Henson <lists@drh-consultancy.co.uk>, "tls@ietf.org list" <tls@ietf.org>
Thread-Topic: [TLS] Questions on certificate_extensions...
Thread-Index: AQHShwD7dCFKEYNAVUOlHuy9Qz7XuqFpP4Ag
Date: Wed, 15 Feb 2017 01:07:55 +0000
Message-ID: <CY1PR0301MB08429D564581F26FABEC7D628C5B0@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <a16de83b-a706-c631-4b75-e1cb40aeb396@drh-consultancy.co.uk>
In-Reply-To: <a16de83b-a706-c631-4b75-e1cb40aeb396@drh-consultancy.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: 0770adaa-a414-4c41-a985-08d4553f1311
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844;
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:+EVA2nd6hkh7lx+ZWQn3rz8TJkvXNrMbqSnfrNkxckEFWES0Zjpt00lmwjNh9/rrOdI0OykWDI1Qgr7fmXxzXtfSvzdbcEF/s3b84coSFEgSix0CEkCfHZixnb8r4pj3lrrjHo6LNSYnVi1TBM38X2gUzDDL/Us/HMVHQa/8Hn+Ddw0kP6hcr8QI2M+FWo5JVogEnZWxwnvrEi3iojEz3Iy7VjPE+OvjR7ghoCcAMB7/zFMM8YPUXFyyXUB55zyt+I/WzxDeWzMOqlgbs68KMg5KNGAySh72LTxXIC18Xm9A3/obUCEYJ1Lrb5dPwo0ObKUPdaXxnev7BzJa/bsRTp4fE1YEuKJv15vly/NoCYQYgXQFwtNi3mh+zg5EXWQnzjdwgm6bcQrMJLg6/9agjZLJiL0fLzu690cjv41yCjBmmp/ojj2h6P4gzeCiShL0bMNJSZEAtYkRc4/zNKqqPrkJAr5Z+uTPJqO34XlUFHK0zZRO7JiuX2h4wkU+zAvbrDDm2ae1Ju+xxWu3l+Kpjye+fRbnQt32bbYmQypDk2Y=
x-microsoft-antispam-prvs: <CY1PR0301MB0844AF4473AD74388C6717578C5B0@CY1PR0301MB0844.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(36789356921836);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(189002)(199003)(377454003)(252514010)(13464003)(105586002)(101416001)(106116001)(8936002)(305945005)(7736002)(3660700001)(6506006)(81166006)(3280700002)(54356999)(2906002)(76176999)(81156014)(102836003)(106356001)(6116002)(97736004)(50986999)(68736007)(33656002)(8676002)(6436002)(77096006)(25786008)(2900100001)(10090500001)(966004)(55016002)(9686003)(99286003)(92566002)(229853002)(7696004)(6306002)(38730400002)(189998001)(86612001)(2950100002)(5660300001)(53936002)(10290500002)(5005710100001)(8990500004)(86362001)(122556002)(74316002)(6246003)(389900002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 01:07:55.5506 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MwIiA9iMhlqCE4vfuQ__X2gc2UE>
Subject: Re: [TLS] Questions on certificate_extensions...
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 15 Feb 2017 01:08:01 -0000

> So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF OBJECT IDENTIFIER for Extended Key Usage.
This is correct. The idea is to use the same format your PKI library already knows how to deal with.

> As regards the matching rules. How do these apply when a particular extension is absent from the certificate?
"If the server has included a
  non-empty certificate_extensions list, the client certificate MUST
  contain all of the specified extension OIDs that the client
  recognizes."

> For example an absent Key Usage is often taken to mean no Key Usage restrictions apply. If Key Usage is present in certificate_extensions does it *require* that the Key Usage extension is explicitly present in the certificate?
Based on the above, yes. However, a client that does not recognize e.g. Key Usage extension, must ignore and skip to the next CertificateExtension.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dr Stephen Henson
Sent: Tuesday, February 14, 2017 12:28 PM
To: tls@ietf.org list <tls@ietf.org>
Subject: [TLS] Questions on certificate_extensions...

A couple of questions on the format and handling of certificate_extensions.

What format is the data that appears in certificate_extension_values? I'd say that it should be in the same format as the content octets of the extnValue field of Extension (from RFC5280 et al). So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF OBJECT IDENTIFIER for Extended Key Usage.

As regards the matching rules. How do these apply when a particular extension is absent from the certificate? For example an absent Key Usage is often taken to mean no Key Usage restrictions apply. If Key Usage is present in certificate_extensions does it *require* that the Key Usage extension is explicitly present in the certificate?

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email