Subject: [TLS] Working group last call for draft-ietf-tls-subcerts-07

From: Joseph Salowey <[email-masked]>
Date: Mon, 18 May 2020 12:56:56 -0700

This is the Working Group Last Call for "Delegated Credentials for TLS"
available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/.
Please review the document and respond to the list with any comments by
June 2, 2020.

Cheers,

Chris, Joe & Sean

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 May 2020 18:40:14 -0400

> This is the Working Group Last Call for "Delegated Credentials for TLS" available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ <https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/>.  Please review the document and respond to the list with any comments by June 2, 2020.  

I just reread draft-ietf-tls-subcerts-07.  I have a few comments.

MAJOR

In section 3, the document says:

   The secret key used to sign ...

Please change "secret" to "private".  Later in the sentence, [RFC5280]
is referenced, and it talks about "private key" in this context.

MINOR

Section 1 says:

   This allows server operators to limit the exposure of keys
   in cases where they do not realize a compromise has occurred.

I suggest an alternative:

   This allows server operators to limit the exposure of keys
   in cases where it might be difficult to determine whether a
   compromise has occurred.

Section 1 also says:

   Because the above problems do not relate to the CA's inherent
   function of validating possession of names, ...

The CA is responsible for confirming that the public key in the
certificate corresponds to a private key that can be used by the
certificate subject.  This is usually done by a proof of possession
mechanism.  So, I think that the start of this sentence should be
reworded to avoid the impression that the CA only validates the
name.

QUESTION

While I have no objection to the DelegationUsage extension,
I wonder is an extended key usage would provide the same
confidence in the certificate.

ASN.1 MODULE

After assigning a place holder vale for "TBD", I compiled the
module, and it works just fine.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 21 May 2020 10:12:03 -0400

On Wed, May 20, 2020 at 6:40 PM Russ Housley <[email-masked]> wrote:

>    function of validating possession of names, ....
>

The existing framing is correct. The most widely used Internet PKI, the Web
PKI, intentionally doesn’t not require a proof of possession mechanism. It
is not used as an authentication mechanism (i.e. a binding of a key to an
identity) but an authorization mechanism (i.e. a binding of an authorized
set of identities to a key).

The “CA only validates the name” is not just an impression, it’s the
widespread running code. Due to how TLS certificates are used (online
protocol negotiation, without non-repudiation support), there’s no risk
opened nor any necessity to do a strong proof of possession binding, even
in cases of strong identity binding.

QUESTION
> confidence in the certificate.

In practice, no. As things currently are, it would unfortunately undermine
the confidence, although this an entirely fair and reasonable question.

As a recap (and more for those without the same context you have) the way
5280 and it’s predecessors were designed, the Certificate Policies
extension is the primary means of expressing or indicating compliance to a
particular policy. If a relying party explicitly attempts to validate a
certificate, for a RP-determined Certificate Policy, then they can know
whether or not that certificate complied with their expectations for
issuance and management. This is all defined within 5280, albeit quite
complex, and involves processing rules for both leaves and intermediates,
as well as the ability to map between different policies (via
policyMappings), such that an RP expecting policy A can validate a
certificate bearing only policy B, provided some trusted party in the
certification path asserted that B was equal-or-equivalent-to A

Additionally, certificates have the extendedKeyUsage, which is most
commonly used to restrict the protocol or protocols a given certificate can
be used for. In RFC 5280 and friends, this restriction only applies to lead
certificates. However, from the very earliest days of PKIX, the two main
implementations (Microsoft and Netscape) diverged from this, in unspecified
ways that ultimately PKIX declined to incorporate, to allow EKUs to be used
on intermediates to restrict the protocols that certificates can be issued
for. If a leaf EKU is not a subset of its issuing chain, then that EKU is
not permitted; much like policy OIDs.

This divergence, which has existed since the very earliest days of TLS,
resulted in a different approach to managing policy than the idealized goal
of PKIX. Rather than having every relying party application provide an
initial policy, such as a policy OID assigned by the root store vendor
(typically the OS/browser vendor), to indicate compliance with the root
store’s policy, and using policy mappings for that, implementations simply
used the EKU as a joint indicator for “uses protocol X and complies with
the issuance policies for protocol X, as defined by the root store vendor”.

This whole long preamble builds to our present day. In wide practice, and
even for those root stores/OSes/applications that do not implement EKU
chaining in the fashion mentioned above, the mere presence of an EKU is the
indicator for compliance with a set of policies, and altering EKUs, like
altering policy OIDs, requires issuing new intermediates permitted for that
EKU.

If DC certificates only bore a DC EKU, they would, in effect, be exempt
from all of the certificate policies widely practiced for the issuance of
TLS certificates, which would reduce the confidence in the certificate.
They would also typically require the CA to issue new intermediate
certificates prior to being able to issue such certificates that were
accepted. For applications, the certificate validation libraries apply
local policy to certificates based on their EKU via technical measures, to
ensure they match the expected issuance policy, such as checking for
certificate transparency information or limiting the maximum validity
period the application will accept.

Recall that the design of DC is also possible via simply nameConstrained
subCAs, but part of the reason for DC is that it does not require or
reduces dependencies on external PKIs in order to satisfy local protocol
needs. The same argument applies here against EKU: to use EKU would place
ongoing dependencies back on those external PKI, be incompatible with how
those PKIs are typically administered, and would cause significant
challenges for applications implementing on common libraries (such as those
provided by their OS).

It’s far from perfect, but the current state of the art is this approach.
If something is meant to be “like” TLS, at minimum, it needs to contain the
TLS EKU, so it is subjected to the TLS policies and usable with TLS
validation stacks. Extensions, with or without the critical bit set, serve
as the way to distinguish whether and how it should be usable with TLS and
the “something like TLS” protocol.

An EKU certainly could be pursued, and it’s by no means an unreasonable
question, but in order to provide the same confidence as currently
specified, existing root store policies would need to be rewritten and
redefined to include that EKU in scope of their “subject to TLS”, as would
their software and validation libraries similarly be updated to process
that.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 May 2020 14:16:16 +0000

*   While I have no objection to the DelegationUsage extension,
I wonder is an extended key usage would provide the same
confidence in the certificate.

FWIW, a new extendedKeyUsage value would be easier to add into OpenSSL, and I’m looking at adding this there (sic).

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 May 2020 10:51:50 -0400

> On May 21, 2020, at 10:12 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> On Wed, May 20, 2020 at 6:40 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> MINOR
> 
> Section 1 also says:
> 
> The existing framing is correct. The most widely used Internet PKI, the Web PKI, intentionally doesn’t not require a proof of possession mechanism. It is not used as an authentication mechanism (i.e. a binding of a key to an identity) but an authorization mechanism (i.e. a binding of an authorized set of identities to a key).
> 
> The “CA only validates the name” is not just an impression, it’s the widespread running code. Due to how TLS certificates are used (online protocol negotiation, without non-repudiation support), there’s no risk opened nor any necessity to do a strong proof of possession binding, even in cases of strong identity binding.

The CSR is signed with the key to be certified.  That is proof of possession.

> In practice, no. As things currently are, it would unfortunately undermine the confidence, although this an entirely fair and reasonable question.
> 
> As a recap (and more for those without the same context you have) the way 5280 and it’s predecessors were designed, the Certificate Policies extension is the primary means of expressing or indicating compliance to a particular policy. If a relying party explicitly attempts to validate a certificate, for a RP-determined Certificate Policy, then they can know whether or not that certificate complied with their expectations for issuance and management. This is all defined within 5280, albeit quite complex, and involves processing rules for both leaves and intermediates, as well as the ability to map between different policies (via policyMappings), such that an RP expecting policy A can validate a certificate bearing only policy B, provided some trusted party in the certification path asserted that B was equal-or-equivalent-to A
> 
> Additionally, certificates have the extendedKeyUsage, which is most commonly used to restrict the protocol or protocols a given certificate can be used for. In RFC 5280 and friends, this restriction only applies to lead certificates. However, from the very earliest days of PKIX, the two main implementations (Microsoft and Netscape) diverged from this, in unspecified ways that ultimately PKIX declined to incorporate, to allow EKUs to be used on intermediates to restrict the protocols that certificates can be issued for. If a leaf EKU is not a subset of its issuing chain, then that EKU is not permitted; much like policy OIDs.
> 
> This divergence, which has existed since the very earliest days of TLS, resulted in a different approach to managing policy than the idealized goal of PKIX. Rather than having every relying party application provide an initial policy, such as a policy OID assigned by the root store vendor (typically the OS/browser vendor), to indicate compliance with the root store’s policy, and using policy mappings for that, implementations simply used the EKU as a joint indicator for “uses protocol X and complies with the issuance policies for protocol X, as defined by the root store vendor”.
> 
> This whole long preamble builds to our present day. In wide practice, and even for those root stores/OSes/applications that do not implement EKU chaining in the fashion mentioned above, the mere presence of an EKU is the indicator for compliance with a set of policies, and altering EKUs, like altering policy OIDs, requires issuing new intermediates permitted for that EKU.
> 
> If DC certificates only bore a DC EKU, they would, in effect, be exempt from all of the certificate policies widely practiced for the issuance of TLS certificates, which would reduce the confidence in the certificate. They would also typically require the CA to issue new intermediate certificates prior to being able to issue such certificates that were accepted. For applications, the certificate validation libraries apply local policy to certificates based on their EKU via technical measures, to ensure they match the expected issuance policy, such as checking for certificate transparency information or limiting the maximum validity period the application will accept.
> 
> Recall that the design of DC is also possible via simply nameConstrained subCAs, but part of the reason for DC is that it does not require or reduces dependencies on external PKIs in order to satisfy local protocol needs. The same argument applies here against EKU: to use EKU would place ongoing dependencies back on those external PKI, be incompatible with how those PKIs are typically administered, and would cause significant challenges for applications implementing on common libraries (such as those provided by their OS).
> 
> It’s far from perfect, but the current state of the art is this approach. If something is meant to be “like” TLS, at minimum, it needs to contain the TLS EKU, so it is subjected to the TLS policies and usable with TLS validation stacks. Extensions, with or without the critical bit set, serve as the way to distinguish whether and how it should be usable with TLS and the “something like TLS” protocol.
> 
> An EKU certainly could be pursued, and it’s by no means an unreasonable question, but in order to provide the same confidence as currently specified, existing root store policies would need to be rewritten and redefined to include that EKU in scope of their “subject to TLS”, as would their software and validation libraries similarly be updated to process that.

I am aware of the "fight" about EKU chaining.  I have a view, but I did not really want to drag subcerts into that controversy.

I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage.

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 21 May 2020 11:23:03 -0400

On Thu, May 21, 2020 at 10:51 AM Russ Housley <[email-masked]> wrote:

> The existing framing is correct. The most widely used Internet PKI, the
> Web PKI, intentionally doesn’t not require a proof of possession mechanism.
> It is not used as an authentication mechanism (i.e. a binding of a key to
> an identity) but an authorization mechanism (i.e. a binding of an
> authorized set of identities to a key).
>

None of these CAs are required to use CSRs or validate signatures. You’re
describing ways a CA could implement POP, but as I said, proof of
possession is not required.

That’s why the current text more accurately reflects the rough consensus of
popular root programs and the running code that trusts those CAs.

It’s certainly true that implementors of DC could reach agreements with CAs
to require POPs, but it’s also not necessary for the protocol (DC or
broadly TLS), which is why it’s not done or required.

> I am aware of the "fight" about EKU chaining.  I have a view, but I did
> not really want to drag subcerts into that controversy.
>

Sure, but unfortunately, the design of DC/subcerts is a direct result of
that running code.

Certain root programs are trying to bridge those gaps (Google and
Microsoft, notably), in a way that perhaps 5-10 years from now we might see
a change to how things were imagined 20-25 years ago, but unfortunately,
that’s the reality of software today, and DC is living in those constraints.

I guess I ask the authors to add a paragraph to the rationale section that
> says something about why this extension was used instead of an extended key
> usage.
>

Sure, I think that could be useful, since if only looking at this and 5280,
the gap I mentioned previously is not at all obvious, and why I wanted to
capture some of it on the list, for those not familiar.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 22 May 2020 11:38:47 -0400

On Thu, May 21, 2020 at 11:23 AM Ryan Sleevi <[email-masked]> wrote
<snip>
> Sure, but unfortunately, the design of DC/subcerts is a direct result of that running code.

One of the hard requirements for our deployment was that the same
certificate be useable with DCs and without. A different EKU would be
more problematic then an extension for this purpose, and while it
might be more or less irritating for implementors depending on how
their stack works (sorry Rich -
https://boringssl-review.googlesource.com/c/boringssl/+/33666/1 might
serve as inspiration, but the client side got dropped for similar
issues). We know the extension doesn't bust things, I don't know an
EKU would, and the root program issues make me hesitate.

Anyway it sounds like no one really has a problem with an extension,
just a question.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 May 2020 17:00:04 +0000

certificate be useable with DCs and without. A different EKU would be
    more problematic then an extension for this purpose

That's a good point, and I accept Ryan's comments about EKU deployment.

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 31 May 2020 21:52:53 -0700

Reminder: the last call expires this week.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Jun 2020 15:57:19 +1000

I've reviewed it, it's mostly fine.

I wonder how much more needs to be said about expiration dates and allowance for clock skew.  We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment.  Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case.

Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected.  What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter.  This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew.  For a 7-day credential, you might get 5 good days of use.

A little bit of a nod in this direction might go a long way to avoiding deployment problems.

The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.

Nits:
The authors seem to use title case and sentence case interchangeably for titles.

On Mon, Jun 1, 2020, at 14:52, Joseph Salowey wrote:
> > This is the Working Group Last Call for "Delegated Credentials for TLS" available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/. Please review the document and respond to the list with any comments by June 2, 2020. 
> > 
> > Cheers,
> > 
> > Chris, Joe & Sean
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>