GnuPG and OpenPGP
=================
- See RFC2440 for a description of OpenPGP. I have an annotated version
- of this RFC online: http://www.d.shuttle.de/isil/gnupg/rfc2440.html
+ See RFC2440 for a description of OpenPGP. We have an annotated version
+ of this RFC online: http://www.gnupg.org/rfc2440.html
Compatibility Notes
===================
- GnuPG (>=0.4.1) is in compliance with RFC2440 despite these exeptions:
-
- ===> Please can someone check this <=========
-
- * (5.1) The critical bit in signature subpackets is currently
- ignored. This will be fixed soon.
-
-
- * (5.2) GnuPG generates V4 signatures for all V4 keys. The option
- --force-v3-sigs allows to override.
-
- * (5.3) GnuPG has an option to use simple S2K for "Symmetric-Key
- Encrypted Session-Key Packets"; however a warning message is
- issued if this option is active.
-
- * (5.5.2) states that an implementaion MUST NOT create a v3 key
- with an algorithm other than RSA. GnuPG has an option to
- create an ElGamal key in a v3 packet; the properties of such
- a key are as good as a v4 key. RFC1991 does not specifiy how
- to create fingerprints for algorithms other than RSA and so it
- is okay to choose a special format for ElGamal.
-
- * (9.1) states that RSA SHOULD be implemented. This is not done
- (except with an extension, usable outside the U.S.) due to
- patent problems.
+ GnuPG (>=1.0.3) is in compliance with RFC2440 despite these exceptions:
* (9.2) states that IDEA SHOULD be implemented. This is not done
due to patent problems.
- * (12.1) states that an implementaion MUST NOT use a symmetric
- algorithm which is not in the preference list. GnuPG has an
- option to override this.
-
- * A special format of partial packet length exists for v3 packets
- which can be considered to be in compliance with RFC1991; this
- format is only created if a special option is active.
All MAY features are implemented with this exception:
* multi-part armored messages are not supported.
- MIME should be used instead.
+ MIME (rfc2015) should be used instead.
Most of the OPTIONAL stuff is implemented.
+ There are a couple of options which can be used to override some
+ RFC requirements. This is always mentioned with the description
+ of that options.
+
+ A special format of partial packet length exists for v3 packets
+ which can be considered to be in compliance with RFC1991; this
+ format is only created if a special option is active.
+
+ GnuPG uses a S2K mode of 101 for GNU extensions to the secret key
+ protection algorithms. This number is not defined in OpenPGP, but
+ given the fact that this number is in a range which used at many
+ other places in OpenPGP for private/experimenat algorithm identifiers,
+ this should be not a so bad choice. The 3 bytes "GNU" are used
+ to identify this as a GNU extension - see the file DETAILS for a
+ definition of the used data formats.
==========================================
* PGP 5.x does not accept V4 signatures for anything other than
- key material.
+ key material. The GnuPG option --force-v3-sigs mimics this
+ behavior.
* PGP 5.x does not recognize the "five-octet" lengths in
new-format headers or in signature subpacket lengths.
it with a V3 keyid, and can properly use only a V3 format RSA
key.
- * Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign
- keys. They only handle Elgamal Encrypt-only keys.
+ * Neither PGP 5.x nor PGP 6.0 recognize ElGamal Encrypt and Sign
+ keys. They only handle ElGamal Encrypt-only keys.
Parts of this document are taken from:
projects / gnupg.git / blobdiff