To:
"Paul Vixie" <paul@vix.com>, <dnssec@cafax.se>
From:
"Sal Mangiapane" <salm@servanttechnology.com>
Date:
Tue, 22 Jun 2004 09:41:11 -0400
Importance:
Normal
In-Reply-To:
<20040622003134.95D9713E1B@sa.vix.com>
Reply-To:
<salm@servanttechnology.com>
Sender:
owner-dnssec@cafax.se
Subject:
RE: continued: rrsig(qtype) (CAS server)
> there are however ways in which "authenticated and reachable" can be made > a prerequisite for inbound e-mail, such that attack #1 would cause delay but > no leaks or losses. in this sense, some form of DNSSEC could be wildly > helpful in deploying certain imaginable anti-spam solutions. I may be confused.....but.... IMHO, this is best served by PKI servers. If DNS continues to move toward providing public key services it will change from it's original goal which is to resolve names to IP addresses. DNS is very good at what it does. Is extending DNS this way in the best interest of the Internet community? Providing public key services may (most likely will) require private information. I don't mean private keys. I mean there would be servers (network devices) that would want to benefit by using PKI without creating a DNS entry. I envision an independent network service providing Certificate Authority Services (CAS). This service must model the DNS to be readily usable on the Internet. This service would be optimized to validate digital signatures and certificates. It should be based upon the work of the PKIX WG. I support DNSSEC as defined today. I have read the draft working documents from May of this year. DNSSEC is protecting the data within DNS. The CAS servers would provide reliable host authentication. Even DNSSEC refers to "trust anchors via some secure or trusted means outside the DNS protocol". CAS could fulfill that starting point for DNS. PKIX could continue to improve and extend the CAS servers. Actually, any application could more easily implement digital signatures without the overhead of maintaining the PKI infrastructure. Then E-mail, VoIP, others would benefit. I would propose that each group, using the IETF standards process, would define their own specific requirements (if any) within the X.509v3 certificate framework. I am preparing a draft and need to see if there is any interest for this type of solution. Your input is greatly appreciated. I am probably confused :) Best Regards, Sal Salvatore Mangiapane