In message <20030729145326.GB25682@rek.tjls.com>, Thor Lancelot Simon writes:
>On Tue, Jul 29, 2003 at 08:09:55AM -0400, Steven M. Bellovin wrote:
>> In message <20030729061636.GA29270@rek.tjls.com>, Thor Lancelot Simon writes
>:
>> >On Tue, Jul 29, 2003 at 02:30:02PM +0900, YAMAMOTO Shigeru wrote:
>> >> 
>> >> Hi, all,
>> >> 
>> >> I make a patch to support HTTPS for /usr/bin/ftp.
>> >> It is quick hack.
>> >> 
>> >> Please try and test it.
>> >
>> >This raises an important issue (which, amusingly, most Linux
>> >distributions seem to botch): if we're going to ship binaries
>> >with the system that support SSL or other certificate-authenticated
>> >protocols, we need to try to do some kind of certificate validation,
>> >and we need to ship a reasonable default bundle of trusted root
>> >certificate authorities.
>> 
>> I think that this is a very dangerous path to go down.  It means that 
>> NetBSD sites will trust these roots, whether they know it or not.  Do 
>> we really want to be in that business?  (With one exception, of course: 
>> a NetBSD CA for NetBSD-related certificates, such as those used for 
>> distributing patches and the like.)
>
>Well, it's an interesting question, but the thing to bear in mind is
>that without a bundle to validate against, most commonplace Unix
>speakers of SSL (e.g. stunnel, lynx) do *no* certificate validation.
>Whatever you think of Mozilla's root CA policies (I don't think they
>are as bad now as it sounds like they once were) trusting the same
>people as just about everyone else on the Net can't be as bad as
>trusting everyone, everywhere.

Trust for what?  What privileges am I supposed to grant to someone who 
has a NetBSD-signed certificate that I wouldn't grant to any random 
person on the net?  Remote login?  Obviously not.  Email?  I don't send 
a lot of sensitive email that's best protected by SMTP/TLS, as opposed 
to PGP.  The only answer I can think of is distributions -- but that 
applies to https contact to the NetBSD web servers.  Beside, what I 
want there is a signature on the distribution itself, not on the 
transmission.

In short, I don't see what problem is being solved.

		--Steve Bellovin, http://www.research.att.com/~smb