You are correct, I screwed up.
They were both co-hosted at:
http://www.scramdisk.clara.net/
The site was updated and is authorship is very clear.
--- David Howe <[EMAIL PROTECTED]> wrote:
> As an aside - Dave Barton? Shaun Hollingworth was the author
> of SD as far as I know. I can't remember
I strongly support your idea. Although it would even be more
useful if you added:
c) e-mail address user certs authenticated via confirmation
message sent to the e-mail address being certified
(as Lucky suggested)
d) fully enable all certificates for all purposes, thereby
allowing the certifi
I concur. The problem is that the most prevalent e-mail
program (Outlook) requires no user intervention as a default
when signing and/or encrypting a message with S/MIME. One can
override the default to "High Security" (requiring password)
only while the X.509 certificate is being installed.
I
I concur. The problem is that the most prevalent e-mail
program (Outlook) requires no user intervention as a default
when signing and/or encrypting a message with S/MIME. One can
override the default to "High Security" (requiring password)
only while the X.509 certificate is being installed.
I
I agree that the signer does not need to understand the
mathematics or underlying technology for digital signatures to
be viable. However, what good is an agreement when the parties
do not know what the terms of the agreement are? A signature
(digital or otherwise) generally indicates that the s
I agree that under-the-hood encryption is becoming more and
more prevalent, and that it generally improves security. Also,
the widespread use of encryption technology helps protect
cryptorights in general as important to the public good.
The fundamental problem with "under-the-hood" is that the
(in response to a topic mentioned in various threads)
I agree that neither CA-verification nor WoT-verification is as
useful as Key Fingerprint-verification for secure communication
between crypto-aware individuals. After all, CA's can be
subverted and WoT is probably best used as a back-up opti
The lack of e-mail detailing financial transactions is also the
reason many businesses chose not to incur the overhead of
secure communications.
If there were servers on the internet which automatically
displayed all plaintext e-mail messages which passed through
them as webpages (for the bored,
While we are on the subject of issuing your own X.509
certificates:
1. How do you create a X.509 signing hierarchy?
2. Can you add additional algorithms (ie. Twofish)?
3. Is a relavent developer reference is available for X.509?
--- Peter Gutmann <[EMAIL PROTECTED]> wrote:
> ...
> So issu
Self-signed and CA x.509 certificates cannot be used in Outlook
even when they are added to the Trusted Root CA's.
Apparently Outlook is able to distinguish between these and
CA-issued x.509 certificates.
--- "Trei, Peter" <[EMAIL PROTECTED]> wrote:
>
> I can't speak for mail-only clients, but
This is a fairly accurate description of the situation, but
neglects to emphasize that the reason [1-cypherpunk] bothers
convincing [2-coerced associate] to use encrypted e-mail is
because [1] understands its importance and is attempting to
share/spread that understanding.
Although [3-Joe Sixpac
Although I also hope for widespread e-mail encryption, I feel
that S/MIME introduces more problems than it resolves.
Certificate Authorities issue certificates complete with CA
imposed expiration dates and usage limitations.
(I prefer independent systems with unrestricted certificates)
Certifica
Disk encryption can always be augmented by physical security,
however communication encryption is dependent on available
encryption tools and legal rights. If quality tools are not
available, then individuals and businesses will not use them.
As long as communication encryption is not widespre
Perhaps there is a conflict of interest issue as well?
"NAI Labs is comprised of more than 100 dedicated scientific
and academic professionals in four locations in the Unites
States, and is entirely funded by government agencies such as:
the Department of Defense's (DoD) Defense Advanced Research
Old software/source code should always be archived.
I am also concerned when new versions of security or
cryptography programs are introduced, especially if
the source code is unavailable. This problem is very
concerning when "subscription" and "live update" services
attempt to force increme
sMIME will always be hampered by Certificate Authority issues.
PGP is large and complex. Version problems are bound to
increase as some users will remain divided between PGPdesktop,
PGPfreeware, and OpenPGP. Still others will want historic
versions or ckt builds. Older versions are limited by
16 matches
Mail list logo
