[dtn] PKIX Extended Key Purpose recommendations

[Brian Sipos <[e-mail]>]

Russ,
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.

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.

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?

Thanks for any help or guidance,
Brian S.

[1] https://tools.ietf.org/html/rfc3207
[2] https://tools.ietf.org/html/rfc8550#section-4.4.4
[3] https://tools.ietf.org/html/rfc8461
[4] https://github.com/openssl/openssl/blob/master/ssl/ssl_cert.c#L418
[5] https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-10