* Ian Brown wrote:
2.4.1 - Just one quibble. Since Armour is largely for backward
compatibility with the 4 million users of PGP 2.6, do we *really* need
to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could
Message-ID also go? It does say in PGP/MIME that "When the amount of
data to be transmitted requires that it be sent in many parts, the MIME
message/partial mechanism should be used rather than the multipart ASCII
armor PGP format."
Good Idea.
2.6 - I'm not sure what jdcc means by "Should the armor header line stay
or go... I think anything that reduces parsing complexity is a Good
Thing." I agree, but by this do you mean it saves implementations
parsing the algorithm fields in the actual signature itself?
No. The new line is completely sensless IMHO, because directly after this
header line the armor header follows. There the Hash codes are already
present.
5.1 - "An implementation should accept, but not generate a version of 2,
which is equivalent to V3 in all other respects." Is this purely for
legal (RSAREF) reasons? The international version of PGP 2.6 can
generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is
there any *technical* reason why OP implementations should not generate
version 2 packets?
Public key encrypted session keys are stored in a completely other padding
format. Same goes for hash paddings in signatures. So there es a major
difference between v2 and v3. For backward compatibility you may refer to
1991 or describe it.
5.2. - Ditto, "Implementations SHOULD generate V4 signatures, unless
there is a need to generate a signature that can be verified by PGP
2.6.x.". Could this not be "Implementations SHOULD generate V3/2
signatures if possible, for backwards compatibility. Only packets that
would not be understood by PGP 2.6.x should have a version number of 4"?
Keeping the technical difference above in mind, you have to use exactly the
same format version the public key of the recipient is stored in.
"Preferred hash algorithms" - you mention "If this subpacket is not
included, ZIP is preferred." Would it be useful to put a sentence of
this type in the preferred symmetric and hash algorithms also? We have
3DES and SHA-1 as MUSTs, so they could be used...
ZIP is not MUST, so: 'If this subpacket is not included, uncompressed is
preferred." Only use MUST values as defaults.
{{Editor's note: While there is a scale of identification signatures
in the range 0x10 to 0x13, most of them have never been implemented or
used. Current implementations only use 0x10, the "generic
certification." Should the others be removed? RFC 1991 went to some
trouble to explain which ones were defined but not implemented, or read
but not generated. I think we should not do that. If we define them,
they should be MAY features at the very least. If we're not going to
use them, they shouldn't be in the spec. --jdcc}}
They were a good idea, but seem to be obseleted by the trust subpackets.
In which case, you're right - get rid of them.
Trust packets are not transferable. There are several implementations known
to use these signatures heavily.
{{Editor's note: There is presently no way for a key-signer (a.k.a.
certifier) to sign a main key along with a subkey. There are a number
of useful situations for a set of keys (main plus subkeys) to all be
signed together... --jdcc}}
Could you give a few examples?
If you try to exchange a whole packet on a keyserver, you must sign all key
material incl. subkeys at once.
5.4 - Is the one-pass signature packet *really* necessary?
Yes, software knows in advance which hashs are used in the signature below.
This is necessary for one pass implementations. I choosed to calculate all
hashs in my one pass implementation. But this can be messy.
8.1 - Why not use the BNF-like notation from section 7.2 to describe
keyring structure also?
Not enough time ;-)