Hash: RIPEMD160

To All-

PGP 6... series introduced support for x509 digital certificates, treating
them as RSA v3 keys with the certificates attached. The PKI trust chain
could be imported, authenticating all imported certificates signed by the
Trusted Root, or an Intermediary. A very useful feature. This ability and
steps are mentioned in the PGP v 6.5.Windows manual.

While PGP would import x509 keypairs as .asc files, (if exported from PGP)
, it would not import a .pem formatted secret key from another application.
It would import, from other applications, a .p12/pfx formatted keypair
protected by a password/phrase. The .pfx format is a "wrapper" to protect
the secret key with a password during transport.

When imported, the protecting password/phrase was asked for and if given,
the certificate's keys are placed in the PGP Secret and Public key rings.
The x509's secret key was also protected by symmetric encryption keyed to
that same .pfx password; done automatically; treating the keys of the x509
like other RSA v3 key pair importation.

This changed with v7 and continues with v8. Under these newer versions,
PGP will import the .pfx key pair wrapper and ask for the protecting
passphrase. Once given and installed, no password/phrase is set. All
decryption and signature operations using the private key of that
certificate are done just by clicking. A warning window appears saying no
passphrase is set, then proceeds. Essentially leaving the secret key and
its operations wide open for any who can open the PGP program. Since the
logic of a x509 in a PKI system is to impart an organization's trust to
that key's use, one can hijack that trust.

This has been confirmed by several experienced users.

Obviously, this is a major change in the software but no mention of it was
found in the Win User's manual for v 7 or v8. Nor was a mention found in
the official PGP Corp.white paper on x509 integration and PGP v8.-
"Using an X.509 PKI with PGP® 8.0:Protecting existing investments."

A software engineer for PGP was contacted earlier this week and this
behavior was pointed out. His reply was that this is normal ; the .pfx
password has NO relationship with the PGP password and that x509s have no
"concept" of passphrases. A passphrase can be applied if one wishes
through the Key Properties window.

However, PGP does not warn or prompt one to do this.

While perhaps technically correct, he had no response when it was observed-
That PGP 6.5...did not do this , opting for more secure behavior. Or that
X509s secret keys are protected objects in Microsoft, Mozilla, and OpenSSL

None of these systems leave the secret key of a x509 laying around for
anyone to use who can start a program.. Either they are protected
physically, through account security measures, can placed within an
encrypted container with a master PW, or the secret key itself is
protected by encryption and a PW. None of which happens by
default with PGP 7 or 8.

The next question that has come up, "Is the secret key of a x509 encrypted
at all in v7 / v8 when imported, or is it encrypted with no password? Is
it written to the hard drive in the clear? If a password is applied later
after importation, is the secret key copied and encrypted with the new
password/phrase ? What happens to the original that was written to the HD?
Is PGP's "memory locking " feature engaged when the secret key is written
to the HD or can a copy of the key, perhaps in the clear, be recovered from
various swap and Temp files requiring no passphrase?

All these are important questions. As is, "Is this a purposeful change in
PGP's behavior or is it an oversight when the code for RSA key handling was
rewritten to accommodate the inclusion of RSA v4?" (introduced with v7.).

Certainly users of the current software should be aware of the change in
key handling if they want to use x509 certificates.

So, if PGP is to continue x509 support, it would be best if it had a
warning window when importing a x.509 telling users of this fact and
directing them to apply a passphrase immediately or return to the feature
in v6.5... and retain the passphrase protecting the .p12/pfx for protecting
the secret key.

Ridge Cook