Should I PGP encrypt using a publickey intended only for Certify? I'm working with a publickey that does not include EncryptStorage or EncryptCommunication flags (see RFC4880 for flag reference). 

My question is, is it safe/appropriate to encrypt using this key?

$ curl https://members.exacttarget.com/Content/Subscribers/SubsLists/publickey.txt &gt; salesforce_publickey.txt
$ pgpdump salesforce_publickey.txt | grep Flag
 # Notice: The encrypt message and encrypt storage flags are not set


GPG has no problem encrypting with this key, I'm forced to use PGPy a pure-python implementation that is apparently more circumspect and fails to encrypt using the root and any subkeys:

import pgpy
publickey = pgpy.PGPKey.from_blob(bytearray(open('salesforce_publickey.txt').read(), 'utf-8'))[0]

publickey.encrypt('secret message', user=publickey.userids[0].email)
&gt;&gt;&gt; PGPError: Key 64C4D5362A88CF19 does not have the required usage flag EncryptStorage, EncryptCommunications


since the root is only able to Certify and no flags are set on the subkeys AFAICT. 

The full pgpdump output is as follows:

$ pgpdump salesforce_publickey.txt 
Old: Public Key Packet(tag 6)(418 bytes)
    Ver 4 - new
    Public key creation time - Tue Jul 22 08:08:31 MST 2003
    Pub alg - DSA Digital Signature Algorithm(pub 17)
    DSA p(1024 bits) - ...
    DSA q(160 bits) - ...
    DSA g(1022 bits) - ...
    DSA y(1023 bits) - ...
Old: User ID Packet(tag 13)(54 bytes)
    User ID - ExactTarget, LLC. (We mail it.) &lt;info@exacttarget.com&gt;
Old: Signature Packet(tag 2)(91 bytes)
    Ver 4 - new
    Sig type - Positive certification of a User ID and Public Key packet(0x13).
    Pub alg - DSA Digital Signature Algorithm(pub 17)
    Hash alg - SHA1(hash 2)
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Tue Jul 22 08:08:31 MST 2003
    Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
        Sym alg - AES with 256-bit key(sym 9)
        Sym alg - AES with 192-bit key(sym 8)
        Sym alg - AES with 128-bit key(sym 7)
        Sym alg - CAST5(sym 3)
        Sym alg - Triple-DES(sym 2)
    Hashed Sub: preferred hash algorithms(sub 21)(2 bytes)
        Hash alg - SHA1(hash 2)
        Hash alg - RIPEMD160(hash 3)
    Hashed Sub: preferred compression algorithms(sub 22)(2 bytes)
        Comp alg - ZLIB &lt;RFC1950&gt;(comp 2)
        Comp alg - ZIP &lt;RFC1951&gt;(comp 1)
    Hashed Sub: features(sub 30)(1 bytes)
        Flag - Modification detection (packets 18 and 19)
    Hashed Sub: key server preferences(sub 23)(1 bytes)
        Flag - No-modify
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0x64C4D5362A88CF19
    Hash left 2 bytes - c6 d4 
    DSA r(159 bits) - ...
    DSA s(159 bits) - ...
        -&gt; hash(DSA q bits)
Old: Public Subkey Packet(tag 14)(525 bytes)
    Ver 4 - new
    Public key creation time - Tue Jul 22 08:08:42 MST 2003
    Pub alg - ElGamal Encrypt-Only(pub 16)
    ElGamal p(2048 bits) - ...
    ElGamal g(3 bits) - ...
    ElGamal y(2047 bits) - ...
Old: Signature Packet(tag 2)(70 bytes)
    Ver 4 - new
    Sig type - Subkey Binding Signature(0x18).
    Pub alg - DSA Digital Signature Algorithm(pub 17)
    Hash alg - SHA1(hash 2)
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Tue Jul 22 08:08:42 MST 2003
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0x64C4D5362A88CF19
    Hash left 2 bytes - e4 a9 
    DSA r(157 bits) - ...
    DSA s(159 bits) - ...
        -&gt; hash(DSA q bits)
Encrypting with a DSA key—as the master key is—doesn't make sense.  It appears that someone neglected to put the encryption usage flags on the Elgamal encryption subkey, which would be the obvious one to use.