Re: [dtn] PKIX Extended Key Purpose recommendations

[Russ Housley <[e-mail]>]

Brian:

> 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?

Russ