Re: [TLS] New version of delegated credentials draft

[Ryan Sleevi <[e-mail]>]

On Thu, Mar 9, 2017 at 2:08 PM, Ilari Liusvaara <[e-mail]>
wrote:

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

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.


> > * 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.
>

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.


> It is going to be much easier getting ECDSA certs (which are infamous
> 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.