Re: [TLS] CertficateRequest extension encoding

David Benjamin <> Sun, 04 September 2016 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6911312B0A1 for <>; Sun, 4 Sep 2016 10:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 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, RCVD_IN_DNSWL_LOW=-0.7, 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 yGFczMNiHmBv for <>; Sun, 4 Sep 2016 10:41:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7435012B0A0 for <>; Sun, 4 Sep 2016 10:41:59 -0700 (PDT)
Received: by with SMTP id i184so116268228itf.1 for <>; Sun, 04 Sep 2016 10:41:59 -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=s5WNUWcyWPLvO/85j82yP5FIAyoLWjsWzFJp2OBdHEc=; b=XK7ol608+S/DQD+faW3OP+F6hgtBP+6OBWBQX+QywEcvrzHDvdtlZgKk7FQD8GlvZp M+INNn/395VJgqUOxI0/pvPOrfsehKVwu+v/HSTnnUL11IzH0KhlTQwL3vEmmLo1nY1A B34TToKDSVvE04+Mm4oC/3nab9ObUr/o9v4sU=
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=s5WNUWcyWPLvO/85j82yP5FIAyoLWjsWzFJp2OBdHEc=; b=bW29MNhLAEwc2D/7GeKAbrvigA3ZMbHINOhEuFX8Dp5f6gWH9IHm+Lay9fnXfmEiMM AV+xLrXYLg8eXDkOi4azjDsZ17pdnoLdPREo6ooca0q2AOdEY0+b1H1/qsENyoKFh9FY DgAUKhkj0JkUNu4SBFtJPNeQmJ9KtxhJPUhl6sgCKfNE3RlpDhUlH1qDt4S04a3i9vTN vQWFC19eBogLpFx2hFep8RsanKA4nht5RQP+fgon77pKbviAOu6yl3Ii6IxtXHvL2ZAg 0aVHDhjK8pQv3vOElqNU2U9USHIC3nAQmfKdorgKuGpDg7RvogAvYwF7Njap75UcKtT3 gYZw==
X-Gm-Message-State: AE9vXwOzddjwB5ELjTXzpSrIp3DYLSdhtWOjOSE46FeMjTON40Qmz+2GsxhNTkC7C3LMH8S47TSoumou2Fvf3lZP
X-Received: by with SMTP id u203mr17940737ita.7.1473010918612; Sun, 04 Sep 2016 10:41:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Sun, 04 Sep 2016 17:41:47 +0000
Message-ID: <>
To: Ilari Liusvaara <>,
Content-Type: multipart/alternative; boundary="001a1143ad4e8e33b5053bb21484"
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: Sun, 04 Sep 2016 17:42:01 -0000

I have no involvement in systems that would want this (our implementation
just ignores it), but it seems a TLS-style registry would be better than
using OIDs anyway. Concretely:

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.

That would buy us:

- More consistency with other TLS fields.

- More compact encoding. (At the cost of going getting to define 2^16 rule
types, but this seems to have been everywhere else.)

- It is easy to look up what a CertificateExtension means and avoid
conflicts. I can go to the registry and see that type 43 means "match
KeyUsage in this way". For OIDs, it's not obvious whether

- Relatedly, we can define multiple kinds of matching rules on the same
OID. Suppose we define it one way and we realize we got it wrong. The OID
scheme means we're stuck with it. The TLS-style scheme allows us to define
key_usage_v2 if needed.

- Less confusion about known OIDs with unknown matching rules. The text is
a little funny right now. There are plenty of known extension OIDs right
now with unknown matching rules. Do we fallback to exact match (which means
we can never change this) or should clients ignore those? That enforcing
known OIDs is a MUST-level requirement makes this messier.

- More flexibility in defining future rule types. Perhaps we want to say
some extension is not present. Or some rule is really a combination of two
OIDs. Or not an OID at all like "your RSA key must be at least 2048 bits".

What do folks think?


On Sun, Sep 4, 2016 at 6:56 AM Ilari Liusvaara <>

> How are the OIDs and values in CertificateRequest extensions encoded
> exactly (I can't make it out from the text)?
> Does the OID part have the ASN.1 OID TLV tag and length (e.g.
> is EKU 0x55 0x1D 0x25 or 0x06 0x03 0x55 0x1D 0x25)?
> And how is the value encoded? Using the same encoding as
> extnValue payload of respective extension in X.509 certifcates?
> Or is it OID-specific (and if it is, what exactly goes to it
> for EKU and KU? RFC 5280 ExtKeyUsageSyntax and KeyUsage?)
> (Currently the text just refers to DER encoding, and in a
> way that could be read to apply to just to values).
> -Ilari
> _______________________________________________
> TLS mailing list