Subject: bis-08 notes

From: David Shaw <[email-masked]>
Date: Fri, 4 Jul 2003 15:02:14 -0400

Here are the rest of my notes on bis-08.  There shouldn't be anything
terribly controversial here.  This is mostly just language and
phrasing stuff.

David

========================================

In the IESG Note at the head of the document, there is the phrase
"(say for new encryption algorithms for example)".  I suggest removing
the "for example", as using both "say..." and "...for example" is
redundant.

========================================

Section 1.1 (Terms) refers to GnuPG once as "GNUpg".

========================================

Section 3.7.1.3 (Iterated and Salted S2K) contains an extra space
before the sentence beginning "Then the salt, followed..."

========================================

Section 5.1 (Public-Key Encrypted Session Key Packet) contains the
sentence "An implementation should accept, but not generate a version
of 2, which is equivalent to V3 in all other respects.".  I suggest
rephrasing with RFC-2119 keywords as "An implementation SHOULD accept,
but MUST NOT generate a version of 2....".

Actually, this whole sentence may be better in the Implementation Nits
section where there already is an item for V2 public keys.

========================================

Section 5.2.3.2 (Signature Subpacket Type) contains the sentence
"Subpackets that are found on a self-signature are placed on a User ID
certification made by the key itself."  I suggest removing the words
"User ID" as there are other types of self-signatures than User ID
certifications (i.e. 1F signatures).

========================================

Section 5.2.3.3 (Notes on Self-Signatures) contains the sentence "If
the key is located by key id, then algorithm of the default User ID of
the key provides the default symmetric algorithm."

"then algorithm" should be "the algorithm".  Also, what is a "default
User ID"?  Is this intended to be an implementation defined default,
or was this supposed to say "primary User ID"?

========================================

Section 5.2.3.23 (Reason for Revocation) ends with "A revoked
certification no longer is a part of validity calculations."  That's a
little odd grammar-wise.  I suggest "A revoked certification is no
longer a part of validity calculations."

========================================

Section 5.2.4 (Computing Signatures) says "A V3 certification hashes
the contents of the name packet, without any header."  "name packet"
should probably be "User ID or attribute packet".

========================================

Section 5.10 (Trust Packet) should probably have some text noting that
the format of trust packets are implementation defined.

========================================

Section 6 (Radix-64 Conversions) discusses Radix-64 (and calls it
Radix-64) throughout, and then adds "An OpenPGP implementation MAY use
ASCII Armor to protect the raw binary data".  This statement comes
before the format of ASCII Armor is introduced in section 6.2, and
Radix-64 isn't equivalent to ASCII Armor anyway (it is a *part* of
ASCII Armor, but armor includes the headers and tail as well).  I
suggest moving that sentence to section 6.2.

========================================

Section 7 (Cleartext signature framework) implies that the only armor
header line that may be used in clear signatures is "Hash", which
isn't true in practice (Version and Comment are common).  Adding an
item for "zero or more lines of armor headers" would help.

========================================

Section 7 (Cleartext signature framework) says "If the "Hash" armor
header is given, the specified message digest algorithm is used for
the signature."  "algorithm is" should be "algorithm(s) are" as more
than one hash algorithm can be provided on a given Hash line, and more
than one Hash line can be given.

========================================

Section 9 (Constants) says "Note that these tables are not exhaustive
lists; an implementation MAY implement an algorithm not on these
lists."  I suggest adding "so long as the algorithm number is chosen
from the private or experimental algorithm range."

========================================

Section 10.1 (Transferable Public Keys) says "After the User ID
packets there may be one or more Subkey packets."  I suggest changing
"User ID packets" to "User ID or Attribute packets".

========================================