All, I'm replying to a non-specific message in this chain just to mention that, similar to what Lorenzo brought up, any translation of identifiers (names or addresses) will be fraught with problems related to security and should not be done. There can be translation or mapping that happens in a way not visible to users/clients, but whatever identifiers are visible to the user/client need to have stable meaning across any network.
Naming authorities, such as PKIX CAs, need to rely on the fact that once a user proves ownership of a specific identifier that same identifier will not be used by other users (at least not simultaneously over a short time interval). Part of the reason why public CAs such as Let's Encrypt will not issue certificates for IP addresses is the prevalence of IP NATs, even though IP identifiers are allowed by the CA/Browser TLS baseline [1]. [1] https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.5.pdf > -----Original Message----- > From: Scott Johnson <[email protected]> > Sent: Wednesday, July 24, 2024 4:44 PM > To: Marc Blanchet <[email protected]> > Cc: Lorenzo Breda <[email protected]>; DTN WG <[email protected]>; dnsop > <[email protected]> > Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model > > APL external email warning: Verify sender [email protected] before > clicking links or attachments > > Hi Marc, > > On Wed, 24 Jul 2024, Marc Blanchet wrote: > > > > > > > Le 24 juill. 2024 à 11:42, Lorenzo Breda > > <[email protected]> a écrit : > > > > > > Why are you against leaving the current TLDs implicitly on Earth by > > default? > > > > > > Right. One do not need a special TLD for space. We can use what we > > have and it just works fine. > > I do not disagree with this notion as respects my proposed architecture. > 3rd level domains mapped to off-world domains works just fine, for the low low > price of annual domain renewal. a tld representing each remote world is > preferable, however, because it is just "cooler;" easier to use and more > memorable than a much longer domain. This, however, assumes we are talking > about the same proposal, which we are not. > > > One has just to be careful on remote resolution so that it contains > > what is needed: trust chain, local names, ... > > > > Lets be clear here, Marc. You are talking about a completely different > solution > than I am; one predicated on IP only. Your comment on this thread, without > context, only serves to confuse the other participants. > > For example, you are talking about using F-root, right? That is a very > different > thing than the functionality which I am describing, with significantly more > network resource usage requirements. My solution uses BP in some network > segments. Personally, I don't think your method will ever fly, primarily due > to > security reasons, but I don't troll your threads about it in a manner which > would > muddy the waters of those considering your proposal. I don't mind healthy > competition of ideas, but I do expect fair play. If you wish to contrast the > two > methods, thats fine, yet unproductive, IMHO. Just make sure the reader knows > you are talking about your proposal, and not mine. > > ScottJ > > > > > This is discussed in: > > - running IP in deep space (noBP<->IP): > > https://www.ietf.org/archive/id/draft-many-deepspace-ip-asse > > ssment-01.txt > > - running DNS in remote places: > > https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-network > > s-01.txt > > > > > > Regards, Marc. > > > > > > > > -- > > Lorenzo Breda > > _______________________________________________ > > dtn mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
