On Sun, May 01, 2016 at 09:40:30PM +0200, Daniel Margolis wrote:
> > If the two names in the cert aren't in the same tree, how will you
> > get a CA to sign it? For example, I have a customer philiphazan.com
> > whose mail is at Tucows' hostedemail.com. Who's going to get the
> > cert, me or Tucows, and either way, how do I or they persuade a CA to
> > sign a cert with two unrelated names?
> >
>
> My suggestion wasn't to have two names, but merely to have a cert valid for
> philiphazan.com (in your example). Tucows can serve the policy with the
> cert you upload to them via SNI, or you can serve the policy yourself on a
> host you control.
Have the expected certificate be different from the authority is
going to make it much more difficult to use "off-the-shelf" HTTPS
libraries to access the underlying HTTPS resource.
> > With typical https libraries, I don't know how hard it'd be to check
> > the second name in the certificate. If we decide to do that, it'd be
> > a good idea to check how deep into openssl or whatever you have to go.
Yes, if one wants to write code directly against OpenSSL, it can
certainly make it possible to support a variety of matching
strategies, but I rather expect that people will just want to use
some existing HTTPS library. (GET an HTTPS URI, and the details
are hidden from the layer than wants the content).
> I think it's worth requiring the CN/SAN to match "example.com" to avoid
> someone.tumblr.com being able to serve a policy for tumblr.com, even if CAs
> are sometimes silly about this, no?
Yes, which is why I strongly suggested a fixed URI whose authority
is the exact next-hop domain, with no sub-domains, and a fixed
well-known path. The parent domain should not depend on the security
of all possible sub-domains.
While that might make it necessary for the email folks to coordinate
with the HTTPS folks, I'm sure they are quite capable of doing so.
> I don't mean to be indecisive about this one, but I think the functional
> difference between those three options is (as far as I can see) small, so
> I'm fairly happy to defer here to someone with stronger feelings on the
> aesthetics (and, obviously, more familiarity with the RFC 3986 ABNF!).
STS is kludgey enough already, let's keep the kludges down to a
minimum. So no dragging in of SRV records or requiring new forms
of certificate matching for HTTPS. Reserving a hostname prefix is
kind of ugly also. Domain owners who delegate sub-domains will
need to avoid delegating this prefix, and we have no registry for
such prefixes.
So using the domain as-is and dealing with any provisioning politics
looks to be the only sensible option.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
