Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

[Niall O'Reilly <[e-mail]>]

On 1 Mar 2011, at 09:28, Alex Bligh wrote:

> For that indirection to be applied to http (e.g. use SRV records) you'd
> need a change at the client end (to use SRV records or whatever) but also
> at the server end, so if a.example.com = b.example.com, and both have SRV
> records to c.example.com, then server c must use the cert for a or b as
> appropriate.

	I'm thinking of a different way, which appears to avoid this problem.

	SRV maps a domain name (OK, a service,transport,name triple) to
	a (set of) host name(s).  If this mapping is provably legitimate
	(DNSSEC), then the browser need only verify that the cert matches
	the final host name.  Matching what I've chosen to call the
	'domain-part' of the http URL is no longer useful.  Used in this way,
	SRV gives us aggregation of certificates: one per target host rather
	than one per secure hosted web site.

	I may be missing something, but I think this needs only client-side
	code changes.  Service-side, certificate administration becomes
	different, but not code.

	ATB
	Niall