Subject: [TLS] New version of delegated credentials draft

From: Subodh Iyengar <[email-masked]>
Date: Thu, 9 Mar 2017 16:50:24 +0000

Based on the comments during the last TLS WG meeting and the comments on the list, we've revised and submitted a new version of delegated credentials  https://www.ietf.org/id/draft-rescorla-tls-subcerts-01.txt.

This has several salient changes from the previous version:

* We trimmed the fat in the custom structure. The only fields that remain are a time and a public key, the necessities.

* We changed the signature algorithm to sign not only the delegated structure, but also signs the EE certificate that issued it as well the TLS version that was negotiated. This has some advantages over proxy certificates and we describe these.

* In the previous draft we described several alternatives. At the last WG meeting no one seemed particularly thrilled about using Name constrained certs directly, but there was some enthusiasm around either the custom structure or proxy certificates. With the changes to signing in this draft, the custom structure has some clear advantages, so we cleaned up the draft to remove all the alternatives except the custom structure.

* Required the presence of an extension in the EE certificate to allow the use of delegated credentials.

* Clarified the behavior of TLS 1.3 and TLS 1.2 clients and servers.

I hope that the cleanup in this draft should make it much easier to discuss going forward.

Subodh

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 9 Mar 2017 21:08:28 +0200

On Thu, Mar 09, 2017 at 04:50:24PM +0000, Subodh Iyengar wrote:
> Based on the comments during the last TLS WG meeting and the
> comments on the list, we've revised and submitted a new version
> of delegated credentials  https://www.ietf.org/id/draft-rescorla-tls-subcerts-01.txt.
> 
> * In the previous draft we described several alternatives.
> At the last WG meeting no one seemed particularly thrilled
> about using Name constrained certs directly, but there was
> some enthusiasm around either the custom structure or proxy
> certificates. With the changes to signing in this draft, the
> custom structure has some clear advantages, so we cleaned up
> the draft to remove all the alternatives except the custom
> structure.

On name constraints, name-constraining a wildcard certificate (e.g.
to "redact" data from CT) could be useful to avoid default-vhost
attacks against HTTP servers (there are lots of servers that
are misconfigured). Especially in HTTP/2.
 
> * Required the presence of an extension in the EE certificate
> to allow the use of delegated credentials.

I think this is going to be a major deployment problem. Basically,
CAs move pretty much glacially.

It is going to be much easier getting ECDSA certs (which are infamous
for being difficult to get[1]).

It seems that the only problematic SPKI OID is the general-purpose
RSA one: 1.2.840.113549.1.1.1.

One idea would be to restrict the extension OID to just those. Would
likely make those wanting delegated certs to reach out for ECDSA, but
it seems that most of the use of RSA when operator is actually able
to make "choice" is because of "compatiblity"[2]. And compatiblity
with ECDSA is of course no concern once subcerts are involved.

> easier to discuss going forward.

[1] Might not be actually true, but certainly ECDSA certs are more
difficult to get than ECDSA ones.

[2] The client support for ECDSA should be good enough already,
unless you explicitly need to (and this is extremely rare) support
very old clients.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 9 Mar 2017 14:45:10 -0500

> are misconfigured). Especially in HTTP/2.

Of course, no CT supporting clients support that method, and it's been
migrated to a (currently non-WG adopted) document in 6962-bis while things
are sorted. So if the argument is name-constraining is expected to
prevalent for case X (where X == redaction), I don't think that's the case.

> CAs move pretty much glacially.

I'm going to push back on this assertion, because it came up during
previous discussions. The CA/Browser Forum's Baseline Requirements already
permit CAs to include additional X.509v3 extensions - specifically, Section
7.1.2.4 of the Baseline Requirements - provided that the semantics that, if
included, will not mislead a relying party about the certificate
information verified by the CA.

As proposed, this (and the previous discussion) meet this definition, and
so without any change to policies, CAs can adopt this.

As a site operator with a business relationship with a given CA, you can
use that business relationship to request these extensions. Plenty of CAs
can and do respond to their customers' needs in a timely fashion, and/or
actively work to standardize them prior to immediately implementing. I
could name off examples for you, but I don't know if they need the free
advertising. The point being is that this doesn't require _all_ CAs to
change, it just requires "your" CA to change, and "your" CA is not going to
be constrained by any policies that prevent them from doing this.

If this were adopted, it might take time for the CA/Browser Forum to
normalize the policies around saying "Yes, this is OK" - and on that, I
agree, it's glacially slow (but about as quick as the full IETF process,
from chartering to publication, all things considered) - but again, you
don't need that.

> for being difficult to get[1]).

It's not actually true anymore and hasn't been for some time, but I also
appreciate this is a subjective statement, so I understand that in the
absence of concrete data, your impressions may differ from my impressions.