[*] We should _also_ bake a public signature verification key into
the installers that can verify a signature on the sets which can
in turn be made only by TNF -- not by any of the public HTTPS
CAs. But that's a separate issue that requires more key
management and software verifier setup than we have settled now.
Once you have that, it seems to me that the use of SSL on either HTTP
or FTP becomes pointless CPU cycle wasting. This then leads me to
wonder two things: (1) is doing SSL a case of the good being the enemy
of the best (because people will fall into the trap of thinking that
SSL means "it's secure" without asking "...against what?"[%])? and (2)
is all this kerfuffle about CA trust anchors effort that would better
be put into designing and building the right answer?
Also, if you're doing public-key crypto - for anything - in the
installers, this will drastically, I am tempted to say
catastrophically, slow down installation on low-end machines, like a
MicroVAX-II or Sun-3. (Of course, NetBSD might be fine with that. I
just think it should be at least thought about.)