Subject: Authority name (was: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-04.txt)

From: "Robert Martin-Legene" <[email-masked]>
Date: Tue, 25 Jul 2006 13:39:32 +0200

Dear all.

I have been having some troubles with the authority that the client
has to specify in queries in XPC.

The XPC spec says that first you connect and the server will greet you
with a connection response block (CRB). Subsequently the client will
sent a request block RQB. The format of the RQB is:

<1-octet auth-len><auth-len-octets authority><xml>

with the idea being that the client must specify against which
authority he will be doing a query. But how does the client know this
authority name?

If I as a TLD registry puts in the relevant _iris-xpc._tcp.dk (or
whatever) record, it is not sufficient information for the client to
know that the authority of the .dk TLD is actually dk-hostmaster.dk.
Especially not if I chose to make the naptr/srv point to xpc.nic.dk
which might be the scenario. So how can the client deduce this
authority name?

And why is it there anyway?

Clues?

-- Robert Martin-Legène, .dk

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Andrew Newton <[email-masked]>
Date: Tue, 25 Jul 2006 09:03:35 -0400

> And why is it there anyway?

It's purpose is to signal the server about which registry it intends  
to address the query.  And the client knows it based on the query.   
For example, if the client is looking up domain name example.dk at  
the dk registry, the authority is dk since the query is the intended  
target of the dk registry.

What the server does with the information is up to the server.  For a  
server serving only one registry, it might very well ignore this  
information.

There is one more aspect to a client knowing its target authority,  
and that has to do with server authentication and TLS.  If the server  
knows it is supposed to be connecting to dk but gets back a  
certificate for sitefinder.com, then it can pretty well assume that  
something went wrong even if the certificate is valid.  And this type  
of check is not done for you by the TLS stack.

-andy