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. > > This has several salient changes from the previous version: > > * 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. > * 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. [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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
