Re: [xri] Designating DNS discovery for non-HTTP URIs

[John Bradley <jbradley@mac.com>]

<Snip>
>> Given the relative insecurity of DNS (leaving dnssec aside for this  
>> conversation)  I would rather trust site-meta if it has been signed  
>> by the domain cert indicating it is authoritative for mailto and or  
>> xmpp rather than looking to DNS.
>
> This does not resolve the raised issue with an HTTP resource laying  
> claim to the attributes of an XMPP resource (or any other scheme),  
> does it?  Using this method, aren't we simply moving the problem  
> from 'those who make HTTP resources' to 'those who have access to a  
> private key', which in the HTTP world, at least, is often the same  
> entities.
>
> Using this approach would also require some thoughts be given to  
> wild-card certs (i've forgotten if we;ve address this elsewhere, but  
> wild-card certs may require special attention to whatever we do here).

Wild cards and subjectAltNames are all going to require thought when  
it comes to signing site-meta.

Moving the delegation of authority from http: to PKI perhaps solves  
the philosophical problem more than the practical administrative  
problem.

If it were me I would probably use a separate cert for signing site- 
meta and XRDs rather than the normal SSL one so that the private key  
is not laying around the server,  but unless we develop a new class of  
certs people will probably use there SSL certs for signing.

So will the webmaster be able to mess with site-meta as they want?   
Yes, but that becomes an administrative problem for the site and not  
one we have a technical fix for.  If the site gets a cert for its  
domain and signs site meta that it is authoritative for mapping meta- 
data for xmpp: URI then I think that is as good from an authority  
point of view as saying it via DNS.

If the web master etc violates there company policy then fire them  
that is the solution to the admin problem.

=jbradley

smime.p7s