Regarding the 128 bit vs 1024 bit thing, what they are likely talking about
is that the symmetric cipher they use is 128 bit strength (probably RC2
which is pretty common).  SSL always uses a combination of certificate-based
asymmetric encryption with symmetric encryption.  The symmetric encryption
encrypts the actual stream of data, whereas the asymmetric encryption is
used to negotiate the session key that will be used for the symmetric
encryption.  128 bit is probably fine for symmetric encryption.

I would be shocked if someone was actually recommending using a cert with a
128 bit RSA key.  That isn't really done.

Regarding the CA approach for the site, it really depends on who will be
accessing the site.  If the public will be accessing the site, then you
really want to use a certificate that chains to a publicly trusted root.
Otherwise, normal browsers will not trust it and they'll get a warning.
This is the primary reason why people buy certs from public providers.
Their CA cert will chain to a standard publicly trusted root.

If you can control all of the machines that will be accessing the site and
can install your root CA cert in their trusted roots cert store, then it is
feasible to issue the certificate from your own CA as trust can be
established that way.

Actual self-signed certs really have no place outside of test labs.  By
default, no one trusts them, so they are very hard to make work in any kind
of deployment scenario.

Joe K.