Notably these constraints are probably not enforced properly:
[ ] Implementations MUST NOT create version 3 signatures
[ ] Implementations MUST generate version 5 signatures when using a version 5 key
[ ] A version 3 signature MUST NOT be created and MUST NOT be used with EdDSA
[ ] OpenPGP implementations MUST create keys with version 4 format. V3 keys are deprecated; an implementation MUST NOT generate a V3 key
[ ] An implementation MUST NOT create Symmetrically Encrypted Data Packet (Tag 9) packet.
[ ] Any failure of the MDC indicates that the message has been modified and MUST be treated as a security problem.
[ ] V3 keys MUST NOT have subkeys.
[ ] AEAD encryption or a Modification Detection Code (MDC) MUST be used anytime the symmetric key is protected by ECDH
[ ] If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.
[ ] An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, AES-128, ensures that the intersection is not null. The implementation may use any mechanism to pick an algorithm in the intersection.
[ ] Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear. Implementations MUST NOT use plaintext in Symmetrically Encrypted Data packets; they must use Literal Data packets to encode unencrypted or literal data.
Notably these constraints are probably not enforced properly:
Symmetrically Encrypted Data Packet (Tag 9)packet.