[TLS] Questions on certificate_extensions...

Dr Stephen Henson <lists@drh-consultancy.co.uk> Tue, 14 February 2017 20:28 UTC

Return-Path: <lists@drh-consultancy.co.uk>
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 563DA129847 for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 12:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level:
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=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 Mb29CmUVNbFZ for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 12:28:40 -0800 (PST)
Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id C8D70129853 for <tls@ietf.org>; Tue, 14 Feb 2017 12:28:40 -0800 (PST)
Received: from host86-133-224-58.range86-133.btcentralplus.com ([86.133.224.58]:30260 helo=[192.168.1.64]) by relay03.mail.eu.clara.net (relay.clara.net [81.171.239.33]:10465) with esmtpa (authdaemon_plain:drh) id 1cdjiE-0000qf-Bp for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Tue, 14 Feb 2017 20:28:36 +0000
To: "tls@ietf.org list" <tls@ietf.org>
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
Message-ID: <a16de83b-a706-c631-4b75-e1cb40aeb396@drh-consultancy.co.uk>
Date: Tue, 14 Feb 2017 20:28:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xW9iBL8hihBgaXrGA2g-ZLrhxC0>
Subject: [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: Tue, 14 Feb 2017 20:28:44 -0000

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.