Re: [TLS] CertficateRequest extension encoding

David Benjamin <> Tue, 06 September 2016 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F4DD12B0FD for <>; Mon, 5 Sep 2016 18:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cr4ZD-uuhusG for <>; Mon, 5 Sep 2016 18:04:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38D4512B492 for <>; Mon, 5 Sep 2016 18:04:45 -0700 (PDT)
Received: by with SMTP id c198so169158384ith.1 for <>; Mon, 05 Sep 2016 18:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NDCWPwW+2gC0S9ychDMUdb/A8jYQcQR137eWeVTzgqI=; b=nfEp60bTBm028xuxud4riwyVlNbNY/wvqF4t/HezckCBbg7ZtKwu1wL6eOfOtvYjjM HZIYAAiT+POQlv3IrgHG9Pb8/q0f1MvZ2//aV8tq0hmGqLjJ4XRa1on0vT7Akc+E3fsr miiE5GpqZruR7sZh6CQNxo4QxlLM7VZtJLUPA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NDCWPwW+2gC0S9ychDMUdb/A8jYQcQR137eWeVTzgqI=; b=HEhHfDaU1GoowJwkBpbjhseZjj7QGav1Gcl9JIFcCLgiUxfJAY/XvjH4Gb04x/tUcb u1lM/ekPgn5Cmh72oJaqy2pP3iz0Zfjg7KFJX7L1/FWxZhohgUnol02atGoKpd+pIMTC eLdGlr7nZw6wjpmWhPtL1yaYFIphgUWwDNvwe/3iflpADMt7gsqpwDQljqBoSpOCR3GP gTPvGYQvosiNTqgOGyDlY7WCfFKkFzlq6sf6UD9XNwhs7pWX+4/g/uEWsDiBsxg0m86G M8tvoVRFHIYepqv3OnMmBts+QOYZsI2JBpbFLorzFONAYYXI1GP3X4wXuukVNPBuYG1q DWTg==
X-Gm-Message-State: AE9vXwNVW1x4znqZqzhTYmGI+7EuI/h29MFOc1rQ0U1nkRTzCeHimdiItq5sjOQuKxe4Gd3DK0p7/JT7YY4Akvwe
X-Received: by with SMTP id o18mr2180825ioo.110.1473123884468; Mon, 05 Sep 2016 18:04:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 06 Sep 2016 01:04:33 +0000
Message-ID: <>
To: Andrei Popov <>, Ilari Liusvaara <>, "" <>
Content-Type: multipart/alternative; boundary="001a1141fa94d863c9053bcc6115"
Archived-At: <>
Subject: Re: [TLS] CertficateRequest extension encoding
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2016 01:04:46 -0000

On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov <>

> Ø  A CertificateExtension is a hint to the client about what kind of
> certificates are acceptable. We have a registry of u16s for them. Clients
> ignore extensions they don't understand, so it is ultimately on the server
> to check the certificate is acceptable (as it always is). If we wish to
> filter on OIDs, we define, e.g., a key_usage value whose contents have some
> KeyUsage-specific meaning.
> Do we need to make it this flexible? The idea was to avoid adding
> complexity to the certificate filtering code in the TLS stack, and instead
> filter by OIDs in the PKI library. PKI libraries already inspect and match
> OID values, so this should be a relatively small change for them.
But it's OID-specific how the matching works, isn't it? Or are you
envisioning that everything but the two exceptions listed here is just
going to be an exact contents match? That there were exceptions was what
seemed off to me.

My gut feeling is exceptions would be the norm and we actually want to be
very precise here or we'll just implicitly standardize whatever one PKI
library does. (I haven't heard of X.509 extension specs defining matchers.)
Doing something TLS-style means we have much clearer semantics. We'd need
to do a bit more work defining a bunch of code points for each OID matcher
we want, but it's something that ought to be written down anyway.

Or is my gut feeling wrong and most of them just an exact match? What is
your PKI library's filter interface?

(Either way I imagine our stack will just keep on ignoring it, so I don't
feel about this all too strongly. But the topic came up so I thought I'd
suggest this.)