Took a while to plough through!
It's a pretty good document overall - please don't take the following
comments as quibbling in any way, I'm just trying to contribute ;-)
Sec Comments
2.4 - Like the description of armour
- If ithe checksum is remaining, I think jdcc's idea to put a sample
implementation in C in the appendix is good - we don't want people to
have to dig out (possibly out of print) books.
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."
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?
3.5 - Are the S2K functions really necessary? Are dictionary attacks on
passphrases in an (at least) 128-bit keyspace likely to be successful?
If so, I still agree with jdcc that the Iterated-Salted algorithm should
be dropped.
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?
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"?
5.1 + 5.2.1 - You mention ASN.1 and PKCS-1. While it's good to have
everything properly attributed, do we need to get simple implementations
involved in these horrors ;-)
5.2.2.2
"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...
"Additional request recipients" - as this is still such a controversial
topic, I don't think it should be included in this first version of the
standard.
5.2.3 - Signature types
{{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.
{{Editor's note: It would be nice to have a signature that applied to
the key alone, rather than a key plus a user name... --jdcc}}
What would it mean to have just key material signed by someone else?
{{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?
5.4 - Is the one-pass signature packet *really* necessary?
5.10 - I think you're right about there being so many problems with
Trust packets, we should forget them. Your idea about them being
implementation dependent is good, except that different OP
implementations may want to use the same keyring. For example, I use PGP
2.6.3i and my mail encrypting program with the same keyring. If they
implement trust packets differently, it would be very confusing. I think
we should just specify that they should be ignored.
6.2 - I know the inclusion of ROT-n started as a joke - but it's in
there! Eeeek! Also, excuse my ignorance, but what is DES/SK?
8.1 - Why not use the BNF-like notation from section 7.2 to describe
keyring structure also?
Ian :D