Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Nov 2020 17:10:09 -0800

Hi Ran,

In short: I agree with what you write.

On Tue, Oct 27, 2020 at 10:42:31AM -0400, R. Atkinson wrote:
> 
> 
> > On Oct 26, 2020, at 23:49, Brian Sipos <[email-masked]> wrote:
> 
> > It's also inconsistent with a desire
> > to make TLS support mandatory to implement (but not mandatory to use),
> > since mandatory to implement implies mandatory to be "capable of
> > exchanging messages with TLS", thus mandatory to use.
> 
> The quote above is a confusion, I think. 
> 
> Please bear with me while I try to explain why that claim about “mandatory
> to use" is only a confusion, not what “mandatory to implement” actually means.
> 
> The key distinction is that “mandatory to implement” means something must
> be fully implemented and supported in the code (or logic if one were to have a
> a Verilog implementation), but it does NOT mean that it have a default run-time 
> configuration of “security is enabled”.

Exactly.  I am (I think) complaining about the specific connotations of the
words used in the description of setting CAN_TLS, and am not trying to say
that the code always will have a default run-time configuration of
"security is enabled".

Specifically, the -23 has:

   If an entity is capable of exchanging messages according to TLS 1.3
   [RFC8446] or any successors which are compatible with that TLS
   ClientHello, the the CAN_TLS flag within its Contact Header SHALL be
   set to 1.  [...]

If we say that TLS support is "mandatory to implement" (do we?  I couldn't
find such text in a quick search, but thought we had talked about it), it
would require some very convoluted reasoning to come up with a scenario
where an entity is "not capable of exchanging messages according to TLS
1.3" -- it would be right in the spec that your implementation needs to
have the capability to do so!  Yes, we could come up with some explanation
about local policy clamping the implementation's capabilities, but it seems
like it would be simpler to use a slightly different wording here, like "if
the entity is configured to enable exchanging messages according to TLS
1.3" that does not set up an apparent conflict between "capable" and
"implements".

Thanks,

Ben

> As a trivial example, possibly unrealistic in life but still useful for understanding...
> 
>  Some implementation (which I will call “X”) of DTN implements support for BPsec
>  and TLS, but it also has a *user* (or maybe system administrator) configurable 
>  switch which allows TLS to be enabled or disabled for a given system which has
>  that implementation X installed on it.
> 
>  Such a switch might have various degrees of granularity,  It could be set
>  to default to respond to TLS but not initiate TLS.  It could be set to try to
>  initiate TLS but continue without TLS if the other end is not willing to do TLS.
>  Ideally, it would enable security to be invoked on a per DTN-session basis,
>  perhaps through some API.
>  
>  As an example from another protocol family, one’s smart phone handset almost
>  certainly _implements_ AH, ESP, and IKE.  That doesn’t mean that the handset
>  will respond to an unsolicited IKE initiation packet from an unknown remote IP
>  address.  Many IPsec deployments have been _configured_ to ignore unsolicited
>  IKE packets, for example.  One’s smart phone likely drops unsolicited / unexpected
>  incoming IKE initiation packets, unless it has been configured otherwise in some
>  manner.  
> 
>  (Example: For an iPhone, the “managed deployment” software generally provides
>  ways for a corporate IT department to automatically bring up an IPsec VPN, an
>  SSL/TLS VPN, or to have some security-protocol policies configured a certain way
>  inside the smart phone handset.)
> 
>  Common UNIX implementations of AH, ESP, and IKE use setsockopt() to enable
>  and/or configure the use of AH or ESP for a given IP session.  On my Mac, the
>  most immediately relevant man pages (man pages are only accessible if one has 
>  developer tools installed on MacOS, AFAIK) are:
>      setsockopt(2)
>      sysctl(8)
>      ipsec(4)
> 
>  On other flavours of UNIX, the relevant set of man pages might vary.
> 
>  So to use IPsec for a given IP session, one probably has a line of code which
>  invokes setsockopt() with the applicable socket option to enable IPsec.  This
>  might manifest in an application as a command-line switch or flag, for example.
> 
> So, to be very clear, the IETF meaning of “mandatory to implement” is that ALL
> implementations must support the feature/capability.  It does NOT mean that a
> given _deployment_ of that implementation on a _particular system_ is required 
> to configure that capability to be on by default.
> 
> Yours,
> 
> Ran
> 
>     
>  
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Nov 2020 17:39:25 -0800

Hi Brian,

Thanks for the updates in the -22 (and -23 that landed more recently).

On Tue, Oct 27, 2020 at 03:49:24AM +0000, Brian Sipos wrote:
> Ben et al.,
> I've posted an updated draft which includes changes to address all but one of the latest SECDIR comments. The one remaining comment relates to when TLS is supposed to be negotiated for use:

I think we need to continue the conversation about
naming/certificate-validation; more below.

> I think we can also wordsmith the setting of CAN_TLS a little more;
> previous discussion indicated a desire to (e.g.) not require TLS when
> operating over IPsec, but that's a different criterion than "capable of
> exchanging messages [with TLS]".  It's also inconsistent with a desire
> For my own purposes and for public network use TLS would be expected, so I don't have a full idea of when TLS would be desirable to negotiate away. Would a more generic statement, inverting the current logic, such as the following work?
> 
> When sufficient security is not supplied by network layers under TCPCL, the the CAN_TLS flag within its Contact Header SHALL be set to 1.
> When CAN_TLS flag is set to 1, the peer SHALL be capable of exchanging messages according to TLS 1.3 [RFC8446] or any successors which are compatible with that TLS ClientHello.

This phrasing would address my concerns (I gave a different alternative in
my response to Ran a few minutes ago).

Back to the topic of naming and the authentication/certificate-validation
procedures.  Instead of just looking at diffs, I went and re-read all of
§4.4 of the -23 to try to look at a coherent picture of the current draft.
I'll put some specific comments later on, but will try to stick to a
high-level picture here since I'm still not sure that we're understanding
each other very well.

In a typical PKI setup, such as the Web PKI, a CA issuing a certificate
only is making claims about the specific bits in the certificate: for
Subject information like a DNS-ID, the CA verifies that the entity
requesting the certificate controls the domain name in question, and
specific X.509 extensions or extendedKeyUsage values may have additional
semantics (and require additional CA verification of the entity requesting
the certificate).  In particular, it does not say anything about the
general trustworthiness of the holder of the certified private key -- one
example of this is how ACME/Let's Encrypt makes it easy for
spammers/phishers to get valid Web PKI certificates for their malicious
domains.  So in this document when we set up a scenario where an entity
authenticated only with DNS-ID or IPADDR-ID is then somehow trusted to
provide a valid/correct Node ID in the SESS_INIT, this is a huge leap of
faith, in the general case.  Now, if we limited our trust anchors to only
CAs that do additional validation (such as only issuing certificates to
trusted end-entities), or if we required a DTN-specific extendedKeyUsage
value and assign semantics to that EKU value that requires the CA to be
careful about who it issues certificates for, then this leap of faith can
become more controlled and limited, but with only the procedures we
describe in the -23, it's a rather unbounded risk.

Accordingly, if a given entity is willing to accept DNS-ID authentication
of a peer and any claimed Node ID from that peer, then the provable
security of the entire network of nodes that includes that entity degrades
accordingly (in the internet threat model), since the attacker can claim
any Node ID.  A more subtle security policy can improve the situation, if
we could know a priori that (for example) certain Node IDs will always be
able to provide a certificate for that NODE-ID -- then we could only fall
back to allowing DNS-ID validation plus peer-claimed Node ID when we're
initiating connections to other nodes, and we could additionaly apply some
sort of filter to which received Node IDs we allow in the SESS_INIT.  But
that requires having policy in place before we start a connection, based on
the Node ID we're trying to reach -- a reactive behavior where we wait for
what the peer gives us and try to validate that leaves us open to an
attacker manipulating us into using the weakest validation procedures.

I'd like to have a better understanding of how you picture the case with no
NODE-ID in the cert being used, and what kind of limitations can be placed
on the peer's ability to claim arbitrary Node IDs in that case.  I feel
like I'm still assuming or inferring a lot, so I don't know how well my
understanding maps to the intended usage.  I'm happy to get on a call to
chat about this (and I plan to be in the IETF 109 gather.town space a lot
this week as well).

I also have a note in my specific comments about the apparent case when
just authenticating the peer's NODE-ID is not sufficient, and we would also
insiste on DNS-ID (or IPADDR-ID) validation.  In my intuition, the Node ID
is the application-layer identity that we're trying to authenticate, and
even if the DNS-ID authentication fails we still would believe that we're
talking to the intended Node.  As I say below, "what's the motivation for
failing the connection if the NODE-ID authenticates but the DNS-ID
doesn't?"  I could imagine that there's some desire to have an initial
authentication occur during the TLS handshake, in accordance with the
typical TLS implementation behavior, and then have a separate check for the
Node ID after the TLS handshake has completed; this would keep the
components separate and have a clean abstraction barrier, but the current
description in the -23 doesn't really give me the impression that that was
the intent.

The rest of my specific comments appear below.

Thanks again,

Ben

Section 4.4.1

   Node ID:  The ideal certificate identity is the Node ID of the entity
      using the NODE-ID definition below.  When the Node ID is
      identified, there is no need for any lower-level identification to
      be present (though it can still be present, and if so it is also
      validated).

It's pretty weird to say "if [lower-level identification is present] it
is also validated".  Part of why it is weird is because it's another
example of letting the as-yet-untrusted peer affect what validation
procedure is used for authenticating it, but it also feels like the
NODE-ID is the actual identifier we care about, and even if there's (for
example) DNS hijacking or NAT going on, if we have authenticated the
NODE-ID we know it's the entity we are trying to talk to.  What's the
motivation for failing the connection if the NODE-ID authenticates but
the DNS-ID doesn't?

   When only a DNS-ID or IPADDR-ID can be identified by a certificate,
   it is implied that an entity which authenticates using that
   certificate is trusted to provide a valid Node ID in its SESS_INIT;
   the certificate itself does not actually authenticate that Node ID.

Perhaps a bit meta, but trusting the end-entity with such a cert to
identify itself transitively implies trusting the CA to only issue
certificates to entries that are trusted to provide the correct Node ID.
So I'd consider adding another sentence here along the lines of
"Such trust is in general not guaranteed by PKI name certification,
though a specific set of trusted CAs may apply more stringent
certificate issuance criteria."

   The RECOMMENDED security policy of an entity is to validate a NODE-ID
   when present, and only require DNS-ID/IPADDR-ID authentication in the
   absence of a NODE-ID.

(This is still leeting the as-yet-untrusted entity affect its own
validation procedure.)

Section 4.4.3

   SHALL perform the certification path validation of [RFC5280] up to
   one of the entity's trusted CA certificates.  If certificate
   validation fails or if security policy disallows a certificate for
   any reason, the entity SHALL fail the TLS handshake with a bad
   certificate error.  Leaving out part of the certification chain can

nit: it's conventionally phrased as 'with a "bad_certificate" alert'.

   Either during or immediately after the TLS handshake if the active
   entity resolved a DNS name (of the passive entity) in order to
   initiate the TCP connection, the active entity SHALL authenticate
   that DNS name using any DNS-ID of the peer certificate.  If the DNS
   name authentication result is Failure or if the result is Absent and
   security policy requires an authenticated DNS name, the entity SHALL
   terminate the session (with a reason code of "Contact Failure").

(editorial) the actual behavior here is okay, but the way it is written
with "SHALL authenticate that DNS name" seems to strongly imply that the
entity has to go through the motions of doing that work, even if the
local security policy isn't going to care about the result.  My
preference (which you have no obligation to heed) would be to flip the
order around to say that if security policy requires the result, then it
SHALL do the DNS name authentication.
(Similarly for the IPADDR-ID and NODE-ID text, of course.)

---

From: Brian Sipos <[email-masked]>
Date: Tue, 17 Nov 2020 04:56:11 +0000

Ben,
I really appreciate the critical eye for security implications and know that small oversights can lead to big problems.
Part of the reason for this somewhat slow drag toward a solid set of TLS requirements is the starting point of web-PKI-focused tools and TCPCLv3 statement that "Nothing in TCPCL prevents the use of the TLS protocol to secure a connection" leaves gaps to fill.

Related to your earlier reply, I think that allocating a EKU OID for DTN will help to turn some of these assumptions about CA behavior into actual encoded claims of purpose. Do you think that these two can be treated as equivalent for the goal of recommended security policy?

  1.  A certificate with an exact NODE-ID (and EKU either absent or including DTN). This leaves no doubt about the claim.
  2.  A certificate with a DNS-ID or IPADDR-ID and with a EKU including DTN. Indicates that the CA is aware that the host is intended as a DTN node.

Should #2 be explicitly related to the use of opportunistic security? Only if an entity has enabled opp. sec. does the DNS-ID or IPADDR-ID matter. Otherwise, only the NODE-ID matters.
Do other protocols make a hard separation between "enabled or disabled" in relation to opportunistic security?

For background on how this would be used in DTN: Because DTN is an overlay network, bundle routing always requires a node to have logic related to "when a bundle needs to go to endpoint X, it's next hop should be node Y over convergence layer Z" where "Y" is the next-hop Node ID and "Z" is the transport which (for internet transports) includes either a DNS name or IP address (i.e. some way to contact the node). The idea is that a peer already has an idea of "what node am I looking to send this to" and uses that DNS name or IP address to contact that node.
I think that this means that the in-band Node ID is superfluous for this use, and is more useful as a diagnostic "oops, I was trying to contact Z but you claim to be W" warning mode. This is how some existing DTN stacks behave.
The benefit to having a certificate claim on a Node ID directly is that there is added agility to use multiple DNS names or IP addresses over time as network topology or access change (as a DTN is wont to do).

One last topic of the authentication logic: I did originally look at requiring it that way, but the current text has a behavior which that type of logic does not; if a certificate does contain an IPADDR-ID then the current text requires it to match the connection. The different claim types are ANDed together. If a cert has a NODE-ID and an IPADDR-ID they both must authenticate the peer, regardless of policy. Policy may only allow the absence of a claim type it may not allow a failed claim type.

________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Monday, November 16, 2020 20:39
To: Brian Sipos <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi Brian,

Thanks again,

Ben

Section 4.4.1

Section 4.4.3

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Nov 2020 18:21:13 -0800

Hi Brian,

> Part of the reason for this somewhat slow drag toward a solid set of TLS requirements is the starting point of web-PKI-focused tools and TCPCLv3 statement that "Nothing in TCPCL prevents the use of…

Understood.

> Related to your earlier reply, I think that allocating a EKU OID for DTN will help to turn some of these assumptions about CA behavior into actual encoded claims of purpose. Do you think that these…

It will help to some extent, though in practice it might not help very much
-- existing Web PKI CAs are pretty unlikely to start signing new EKUs
without a fair bit of work.  (Mostly on non-technical aspects of things, as I
understand it, though I am sure I will learn a lot at tomorrow's SAAG
presentation on what is needed to set up a PKI.)

>   2.  A certificate with a DNS-ID or IPADDR-ID and with a EKU including DTN. Indicates that the CA is aware that the host is intended as a DTN node.

The two are of course not exactly equivalent, but for the purposes of a
default security policy it will probably be fine to accept either of them.
(We will want to be clear in the definition of the EKU that the semantics
include the holder of the certificate being trusted to provide a Node ID if
one is not in the certificate, though.)

> Do other protocols make a hard separation between "enabled or disabled" in relation to opportunistic security?

In my mind #2 is a variation on non-opportunistic (or "full") security,
rather than a form of opportunistic security, though in some sense there is
a hierarchy or continuum and this is just one point on that ladder.
Usually I see "opportunistic security" used to refer to just not attempting
to authenticate the peer at all, ignoring failure to validate the expected
hostname against the presented certificate, etc., but the #2 is still doing
some partial validation, just at a different level of naming than #1.  So
I'm not entirely sure that I understand the question about a hard
separation for enabled/disabled.

> The benefit to having a certificate claim on a Node ID directly is that there is added agility to use multiple DNS names or IP addresses over time as network topology or access change (as a DTN is…

Thank you for this background; it is very reassuring to hear.  (It matches
my intuition on how things should work, but I don't have much confidence
that my intuition will always be correct, since this area is pretty far
from my normal areas of expertise.)  I heartily agree about the benefits of
having a Node ID directly in the certificate.

> One last topic of the authentication logic: I did originally look at requiring it that way, but the current text has a behavior which that type of logic does not; if a certificate does contain an I…

I think this is actually a bad property to have, leading the system to
become unnecessarily "fragile".  In particular, the semantics of a
certificate are "the holder of the private key corresponding to this
certificate can act as the various entities named in the Subject fields",
but not "this is an exhaustive list of the names for the holder of the
private key corresponding to the certificate".  So, we might end up in a
scenario where the same entity can be named by any/all of Node-IDs A and B,
and IP addresses X and Y.  But if those identities are bundled to gether
into one certificate with A and X, and a second certificate with B and Y,
then no single certificate could satisfy a peer that is trying to talk to
node A on address Y -- with the current validation policy in the -23 the
peer would have to fail the connection no matter what certificate is
presented.

To put it more pithily: just because I have one IP address in my
certificate does not mean that all of my IP addresses are in my
certificate.

Does that help clarify my thinking?

Thanks again,

Ben

---

From: Brian Sipos <[email-masked]>
Date: Wed, 18 Nov 2020 22:20:54 +0000

Ben,
I see your concerns and I'm looking along a couple of different axes: what other specifications using TLS say to do (relative to RFC6125) and how some implementations behave relative to multiple identifiers and identifier types in PKIX certs.

My current thinking is that there really are two separate "Verifying Service Identity" (Section 6 of RFC6125) searches:

  1.  Search based on both DNS-ID (if a name was used/relevant) and IPADDR-ID reference identifier. This verification succeeds if either identifier matches the cert.
  2.  Search based on NODE-ID reference identifier.

Unfortunately, there is a catch-22 about ordering because #1 is the typical peer authentication which is "built in" in many cases to existing tools (though TLS client address verification seems to be sporadic) while #2 is the new behavior based on post-handshake exchanged data, but the recommended policy is to do #2 unconditionally and only do #1 as a fallback. This means that #1 cannot occur until after the completion of #2 and evaluation by security policy.

So massaging this recommended policy becomes that either one of the following must succeed (no order):

  *   Verification #1 along with requiring an EKU for DTN security, or
  *   Verification #2

This avoids an order or time dependence but does prohibit an implementation from failing early if #1 does not succeed. There's already a security threat for Node Impersonation and a user of the recommended policy just needs to be aware of this threat.

Does any of this sound reasonable?
________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Tuesday, November 17, 2020 21:21
To: Brian Sipos <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi Brian,

Understood.

Thanks again,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Nov 2020 17:51:17 -0800

Hi Brian,

> I see your concerns and I'm looking along a couple of different axes: what other specifications using TLS say to do (relative to RFC6125) and how some implementations behave relative to multiple id…

I'm very grateful that you are willing to dig into the topic to this
extent; thank you!

>   2.  Search based on NODE-ID reference identifier.

I think in some sense that's correct, yes.  (A fairly strong sense, though
it's not quite something that I would say is "universally the correct way
to think about it" or something like that.)  <tangent>In a different
universe we might have attempted to separate them further, with #1 always
happening, at the TLS layer, and #2 also always happening but using some
different (application-layer, possibly CMS or something over a channel
binding value) mechanism and possibly different credentials type as well.
I say "in a different universe" because the path from where we are to such
a scenario is not very clear and there are no fundamental flaws with the
general structure we already have, so it doesn't seem worth just throwing
it all away to start over.</tangent>

> Unfortunately, there is a catch-22 about ordering because #1 is the typical peer authentication which is "built in" in many cases to existing tools (though TLS client address verification seems to…

Yes.

> Does any of this sound reasonable?

I think it all sounds reasonable :)

We will recognize, of course, that this recommended policy will not apply
in all scenarios, and that when verification #1 is used without the EKU for
DTN security, the threat of node impersonation is more prominent (IIUC this
is basically what your last sentence about the "security threat" is
saying); in some scenarios that can be an acceptable risk.

Thanks again,

Ben

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 18 Nov 2020 22:38:57 -0500

> On Nov 16, 2020, at 20:10, Benjamin Kaduk <[email-masked]> wrote:
> 
> find such text in a quick search, but thought we had talked about it),

Hi,

I don’t see any text saying that TLS is “mandatory to implement” in the TCPCL I-D.  

I believe the TCPCL I-D should have text, probably in Security Considerations, saying that:

"TLS is mandatory to implement for all TCPCL implementations, but TLS is optional to use for a given TCPCL session."

I imagine the WG would be comfortable with words generally along those lines, but I am not sure whether a formal WG decision has been made. (DTN Chairs ?)

> it would require some very convoluted reasoning to come up with a scenario
> have the capability to do so!  

Agreed.

> Yes, we could come up with some explanation about local policy clamping the implementation's capabilities, but it seems like it would be simpler to use a slightly different wording here, like
> “if the entity is configured to enable exchanging messages according to TLS
> "implements”.

That text edit would work for me.  

Effectively those edits would mean that all TCPCL implementations would need to implement TLS (which implementation really is easy since OpenSSL exists and could be used) but that local configuration might mean TCPCL is not in use for some TCPCL sessions.

As an aside, many commercial vendors use OpenSSL as the basis for their TLS implementations, in part because OpenSSL already has a FIPS-140 approval from US NIST.  This makes compliance with both US and non-US buyer requirements easier for vendors.  FIPS-140 is commonly required by non-US financial institutions and a range of countries other than the US, so it is not really a US-specific sales/acquisition issue.

Yours,

Ran

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Nov 2020 02:56:51 -0800

> I imagine the WG would be comfortable with words generally along those lines, but I am not sure whether a formal WG decision has been made. (DTN Chairs ?)

I would be very happy if something like that could be added.

Agreed.

> As an aside, many commercial vendors use OpenSSL as the basis for their TLS implementations, in part because OpenSSL already has a FIPS-140 approval from US NIST.  This makes compliance with both U…

Stepping aside even further, for my day job I work on OpenSSL, and the
existing FIPS-140 certificate is for a module that only works with an
OpenSSL version that is no longer officially supported.  We (mostly not me
personally) are making a bit push to get a new one along with the 3.0 major
release (currently in alpha), and the people doing most of the work are in
Australia, the UK, and Sweden -- not the US!

-Ben

---

From: Brian Sipos <[email-masked]>
Date: Thu, 19 Nov 2020 23:01:10 +0000

Ben,
I have some restructuring pending a -24 draft which should make all of these changes (including your and Ran's request) and hopefully bring some more consistency to the spec and behaviors. I'm waiting for some additional consensus for a couple of changes.

I am going to be assigning an EKU for "DTN Security" and I'll bring up during the WG meeting tomorrow whether a single EKU makes sense or splitting "DTN transport security" from "DTN bundle security" purposes. The S/MIME uses a single purpose for several use cases, so seems like that is a reasonable path to take. Some "DTN Security" certs could be for CL transport, some for BPSec signing, some for encryption, etc.

I'm also doing some experimenting and discovering lots of "interesting" TLS/PKIX library behavior when presented with some of these new use cases, specifically custom EKU...
________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Wednesday, November 18, 2020 20:51
To: Brian Sipos <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi Brian,

Yes.

Thanks again,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Nov 2020 16:58:01 -0800

Hi Brian,

I believe that the expert for the SMI Security for PKIX Extended Key
Purpose registry (Russ Housley <[email-masked]>) would be happy to
get advance questions about 1 vs 2 EKU values, and probably also to prepare
an ASN.1 module that can be included in the draft to facilitate people
using them.  S/MIME is pretty old and may predate the current thinking on
best practices.

It will be interesting to see what you report from the survey of
implementations w.r.t. these things ... I have some suspicions but no hard
data at hand.

-Ben