Re: [dtn] PKIX Extended Key Purpose recommendations

Russ Housley <> Sat, 21 November 2020 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 931643A0ADE for <>; Sat, 21 Nov 2020 10:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZc1q60AA_UO for <>; Sat, 21 Nov 2020 10:15:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42EE63A0AD3 for <>; Sat, 21 Nov 2020 10:15:53 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A83EA300BC1 for <>; Sat, 21 Nov 2020 13:15:50 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id U3FhBVWuM7Tm for <>; Sat, 21 Nov 2020 13:15:48 -0500 (EST)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id 796E5300A87; Sat, 21 Nov 2020 13:15:48 -0500 (EST)
From: Russ Housley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6B7640EA-11D1-46B0-9A52-2194F1DF34DB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Sat, 21 Nov 2020 13:15:49 -0500
In-Reply-To: <>
Cc: "" <>, Ben Kaduk <>
To: Brian Sipos <>
References: <>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <>
Subject: Re: [dtn] PKIX Extended Key Purpose recommendations
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Nov 2020 18:15:56 -0000


> I was referred to you from Ben Kaduk regarding the design and use of a new PKIX Extended Key Purpose. The use cases for this new purpose are for the IETF DTN WG (CCd on this email) and currently fall under three categories: bundle transport security (using TLS), bundle integrity (signing), and bundle confidentiality (encryption).
> The idea is that a new OID is allocated for "DTN Security" and this would be present in the EKU to indicate that a CA has verified the key holder to be trusted to run a DTN node. There is an open question as to whether there is enough distinction between a purpose of "generating or accepting security blocks" and the purpose of "transporting a whole bundle untouched".
> The good news for rationale and understanding of these uses are that they are very similar to SMTP/TLS [1] and S/MIME [2] respectively. Although it appears that the id-kp-emailProtection OID was only ever specified for S/MIME and not for email transport between MTAs. I don't know what kinds of policies SMTP MTAs have with regard to PKIX certificates, even recent MTA-STS spec [3] doesn't define or reference a more detailed PKIX profile and doesn't mention any X.509 extensions at all.

id-kp-emailProtection is for use with S/MIME.  It should only appear in certificates that also contain an email address for the subject.

> The bad news is that in some very simple testing of adding a new purpose OID I see that OpenSSL, which is used by both of my reference libraries Qt5 and python "ssl" package, appears to assume [4] that when I want "TLS on a socket" what I mean is "TLS for Web client/server purposes" and requires either id-kp-serverAuth or id-kp-clientAuth. There also appear to be quite a number of other implicit uses of the Web purposes in OpenSSL and no real access via higher-level APIs to affect this. The other key purposes seem to be usable only through different APIs unrelated to TLS.

id-kp-serverAuth or id-kp-clientAuth are for use with TLS.  id-kp-serverAuth usually contains a domain name in the for the subject.  In the MTA example, the client also contains a domain name in the for the subject, but that is not the only situation where client authentication is used.

> Ben originally referred me to [5] as an example of allocating new OIDs for another recent use of TLS for RPC. That draft doesn't really have a PKIX profile for how the new purposes inter-relate with existing purposes or how validation should treat the new purposes relative to pre-existing purposes.
> All that said, the short question is: is there value in allocating an extended key purpose for DTN security?
> If so, how much detail for a certificate profile and/or validation logic is either necessary or useful relative to any new purpose?

I do not know enough about DTN to know.  How would a CA know whether a particular certificate out to include the DTN-related EKU value or not?  What would be the harm if it was incorrectly included?  What would be the harm if it was incorrectly omitted?