[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] SC/TC equivalence
David Hopwood wrote:
> Erik Nordmark wrote:
> > If the client asks for A and gets a response with QNAME A' and answer X
> > then ...
>
> It won't - it will get a response with QNAME A.
>
> For DNSSEC, all responses for names that are actually used will have to be
> signed. This is an inevitable consequence of wanting TC/SC equivalence
> without putting TC/SC folding in nameprep (that is, the client-side
> canonicalization function). The decision that WG has to make is whether
> TC/SC folding is in nameprep or not. If that answer is "yes", it also has to
> define the folding, and require that all clients implement it.
If it gets a response with QNAME A then there must be a separate SIG for
QNAME A' and QNAME A for each RRset. Since DNSsec should be capable of
operating with offline private keys this means that the signature couldn't
have been created when the server received the query.
Thus I think you are pointing at the same type of solution to this as
Keith was: the server maintains the same responses (all RRsets) for
queries on A and A'.
That is quite different than what I've heard discribed as the DNS server
doing a mapping on the fly.
The former might have result in combinatorial explosion but works
with DNS including DNSsec.
The latter can avoid the combinatorial explosion but doesn't work with the
DNS as I pointed out.
> Personally I don't think nameprep should include any folding that depends
> on the semantics of particular languages - even if that causes inefficiencies
> for DNSSEC.
Agreed. IDN is about identifiers and not words and languages.
(And just like in the current non-IDN world folks will try to overload
words and phrases on IDN but that should really be a separate problem.)
Erik