-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>My suggestion would be thus to *specify that the certificate used to serve
>the policy be valid for the TLD ("example.com <http://example.com>") *and
>that we *retain the ability to serve policies from a different endpoint
>than the TLD* (via either a magic hostname in DNS or, I guess as a slightly
>crude hack, sticking a URI in the policy-version TXT record).
>
>Does this make sense? I think the security issues do not rely in any event
>on the DNS scheme we choose (but instead on what we require of the policy
>serving cert), so the only issue here is really one of convenience.
Pretty much. Here's the issues I can think of:
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?
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.
It's not clear to me how much extra security the second name in the
certificate actually gives you if they're in the same tree. In my
experience, if you ask a CA to sign foo.bar.example.com, as often as
not they'll throw in example.com for free. The extra example.com name
doesn't tell you anything about the relationship between the two names
since CAs assume they're under the same control anyway.
Finally, there's the question of how you find the other endpoint. I
suppose you could stick it in a TXT record but that's really no better
than SRV. If you want to use a magic hostname, people will get
extreme heartburn since as far as I can tell, nobody's ever reserved a
hostname component (as opposed to a non-host component with an
underscore) before. My xn--sts0 kludge is probably as good as you're
going to get, but it's still a total kludge.
R's,
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlcmIJEACgkQkEiFRdeC/kWIjgCcDvCsOAQBxCYqTt7TdA5NPUI/
jeUAn323Q7Cu6JISIg6sUFrEFT0jpMGq
=fTeb
-----END PGP SIGNATURE-----
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
