RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 51 records.

Status: Verified (4)

RFC 4880, "OpenPGP Message Format", November 2007

Source of RFC: openpgp (sec)

Errata ID: 2270

Status: Verified
Type: Technical

Reported By: David Shaw
Date Reported: 2010-05-18
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 5.2.2 says:

       SHA224:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
                   0x00, 0x04, 0x1C

It should say:

       SHA224:     0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
                   0x00, 0x04, 0x1C

Notes:

The second byte as published in 4880 is 0x31 but should be 0x2d.

Hal Finney noted this once, but I didn't see it entered in as an errata.

Errata ID: 2271

Status: Verified
Type: Technical

Reported By: David Shaw
Date Reported: 2010-05-18
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 6.5 says:

   Input data:  0x14FB9C03D97E
   Hex:     1   4    F   B    9   C     | 0   3    D   9    7   E
   8-bit:   00010100 11111011 10011100  | 00000011 11011001 11111110
   6-bit:   000101 001111 101110 011100 | 000000 111101 100111 111110
   Decimal: 5      15     46     28       0      61     37     62
   Output:  F      P      u      c        A      9      l      +

It should say:

   Input data:  0x14FB9C03D97E
   Hex:     1   4    F   B    9   C     | 0   3    D   9    7   E
   8-bit:   00010100 11111011 10011100  | 00000011 11011001 01111110
   6-bit:   000101 001111 101110 011100 | 000000 111101 100101 111110
   Decimal: 5      15     46     28       0      61     37     62
   Output:  F      P      u      c        A      9      l      +

Notes:

This example shows the conversion of 0x14FB9C03D97E into Radix-64. The problem is in the last byte, where '7E' is shown in binary as 11111110. That of course should be 01111110. The error is carried through in the 6-bit rendering of that data where the next-to-last 6-bit group 100111 should actually be 100101. The decimal rendering as well as the output (character) line is correct.

Errata ID: 3298

Status: Verified
Type: Technical

Reported By: Daniel Kahn Gillmor
Date Reported: 2012-07-27
Verifier Name: Stephen Farrell
Date Verified: 2013-03-16

Section 5.2.4 says:

Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.

It should say:

Primary key revocation signatures (type 0x20) hash only the key being revoked.
Subkey revocation signature (type 0x28) hash first the primary key and then the
subkey being revoked.

Notes:

This amendment to subkey revocation signatures is intended to align the spec with existing implementations. (it also makes the subkey revocation signatures more symmetric with the subkey binding signatures).

GnuPG (all known versions with subkey support) hashes both keys, as does PGP (tested at version 6.5.8). I'm unaware of any other OpenPGP implementation that actually complies with the spec as written for subkey revocations.

This was apparently noticed (but apparently ignored) back in 2000 (see point 2 of [0]) and was recently discussed again on the IETF list [1].

[0] http://www.mhonarc.org/archive/html/ietf-openpgp/2000-12/msg00001.html
[1] http://www.mhonarc.org/archive/html/ietf-openpgp/2012-07/msg00003.html

Errata ID: 2242

Status: Verified
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 13.1.3. says:

   mL = intended length in octets of the encoded message, at least tLen
        + 11, where tLen is the octet length of the DER encoding T of a
        certain value computed during the encoding operation

It should say:

   emLen = intended length in octets of the encoded message, at least
        tLen + 11, where tLen is the octet length of the DER encoding T
        of a certain value computed during the encoding operation

Notes:

In the following text it is called emLen.

Changed to editorial.

Status: Held for Document Update (15)

RFC 4880, "OpenPGP Message Format", November 2007

Source of RFC: openpgp (sec)

Errata ID: 2199

Status: Held for Document Update
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.7.2.1. says:

For compatibility, when an S2K specifier is used, the special value
254 or 255 is stored in the position where the hash algorithm octet
would have been in the old data structure.  This is then followed
immediately by a one-octet algorithm identifier, and then by the S2K
specifier as encoded above.

It should say:

For compatibility, when an S2K specifier is used, the special value
254 or 255 is stored in the position where the cipher algorithm octet
would have been in the old data structure.  This is then followed
immediately by a one-octet cipher algorithm identifier, and then by
the S2K specifier as encoded above.

Notes:

The paragraph before says:
Older versions of PGP just stored a cipher algorithm octet preceding
the secret data or a zero to indicate that the secret data was
unencrypted. The MD5 hash function was always used to convert the
passphrase to a key for the specified cipher algorithm.

Errata ID: 2200

Status: Held for Document Update
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.7.2.1. says:

This last possibility, the cipher algorithm number with an implicit
use of MD5 and IDEA, is provided for backward compatibility;

It should say:

This last possibility, the cipher algorithm number with an implicit
use of MD5, is provided for backward compatibility;

Notes:

The cipher algorithm is determined by the number. There is no implicit
use of IDEA.

Errata ID: 2206

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.1. says:

A Public-Key Encrypted Session Key packet holds the session key used 
to encrypt a message.

It should say:

A Public-Key Encrypted Session Key (PKESK) packet holds the session 
key used to encrypt a message.

Notes:

The acronym PKESK is not defined.

Tweaked the suggestion to reword the 1st sentence in 5.1 to define it.

Errata ID: 2208

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.2.1. says:

   This signature is a statement by a signing subkey, indicating that
   it is owned by the primary key and subkey.

It should say:

   This signature is a statement by a signing subkey, indicating that
   it is owned by the primary key.

Notes:

The subkey does not own itself.

Errata ID: 2214

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.2.3. says:

   The concatenation of the data being signed and the signature data
   from the version number through the hashed subpacket data (inclusive)
   is hashed.  The resulting hash value is what is signed.  The left 16
   bits of the hash are included in the Signature packet to provide a
   quick test to reject some invalid signatures.

   There are two fields consisting of Signature subpackets.  The first
   field is hashed with the rest of the signature data, while the second
   is unhashed.

It should say:

   The concatenation of the data being signed and the signature data from
   the version number through the hashed subpacket data (inclusive), plus
   a six-octet trailer (see section 5.2.4) is hashed.  The resulting hash
   value is converted to the signature.  The left 16 bits of the hash are
   included in the Signature packet to provide a quick test to reject
   some invalid signatures.

   There are two fields consisting of Signature subpackets.  The first
   field (together with the preceding parts of the signature) is
   included in the hash, while the second is not.

Notes:

There are six more octets (see 5.2.4.).
The data being signed is signed. The hash value is not signed, but
converted into the signature.
The first field is not hashed (does not contain a hash), but it is
hashincluded. It is not true that the rest of the signature data is used
in the hash. (This formulation is such strange for accuracy.)
Unhashing is the reverse of hashing, which is hopefully unfeasible.

Modified text.

Errata ID: 2216

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 5.2.3.3. says:

   Subpackets that appear in a certification self-signature
   apply to the user name, and subpackets that appear in the subkey
   self-signature apply to the subkey.

It should say:

   Subpackets that appear in a certification self-signature
   apply to the User ID, and subpackets that appear in the subkey
   self-signature apply to the subkey.

Notes:

User ID, not user name

Errata ID: 2219

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.3. says:

   The message is encrypted with a session key, and the session key is
   itself encrypted and stored in the Encrypted Session Key packet or
   the Symmetric-Key Encrypted Session Key packet.

It should say:

   The message is encrypted with a session key, and the session key is
   itself encrypted and stored in the Public-Key Encrypted Session Key
   packet or the Symmetric-Key Encrypted Session Key packet.

Notes:

The word `Public-Key' is missing.

Changed to editorial

Errata ID: 2222

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.5.3. says:

   Implementations MUST use a string-to-key specifier; the simple hash
   is for backward compatibility and is deprecated, though
   implementations MAY continue to use existing private keys in the old
   format.

It should say:

   Implementations MUST generate a string-to-key specifier; the simple
   hash is for backward compatibility and is deprecated, though
   implementations MAY continue to use existing private keys in the old
   format.

Notes:

MUST use and MAY continue to use the opposite is a contradiction.

Changed to editorial.

Errata ID: 2226

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 5.9. says:

       These should be converted to native line endings by the receiving
       software.

It should say:

       These SHOULD be converted to native line endings by the receiving
       software.

Notes:

This is a SHOULD of [RFC2119].

Changed to editorial.

Errata ID: 2234

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 6.5. says:

    Examples of Radix-64

It should say:

    Examples of base64

Notes:

Radix-64 has a checksum, too.

Changed to editorial.

Errata ID: 2235

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 8. says:

   If two characters in the sequence are separated
   by '-', this is shorthand for the full list of ASCII characters
   between them (e.g., '[0-9]' matches any decimal digit).

It should say:

   If two characters in the sequence are separated by '-', this is
   shorthand for the full list of ASCII characters between them (e.g.,
   '[0-9]' matches any decimal digit).  The collation sequence is UTF-8.

Notes:

UTF-8 has the collation sequence of unicode. You probably do not want
to have the system's locale involved.

Maybe a hint on greediness of regex is nessessary, too.

Changed to editorial.

Errata ID: 2236

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 11. says:

11.  Packet Composition

(the headline)

It should say:

11.  Packet Sequence Composition

Notes:

It is about the composition of a sequence of packets, not about the
composition of a packet.

Errata ID: 2238

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 11.1. says:

   After the User ID packet or Attribute packet, there may be zero or
   more Subkey packets.

It should say:

   After the sequence with the User ID packets and User Attribute
   packets, there may be zero or more Subkey packets.

Notes:

The Subkey packets come after all User ID packets and User Attribute
packets.

Changed to editorial.

Errata ID: 2240

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 12.1. says:

   In the above diagram, if the binding signature of a subkey has been
   revoked, the revoked key may be removed, leaving only one key.

It should say:

   In the above diagram, if the binding signature of a subkey has been
   revoked, the revoked key may be removed.  Note that this bears the
   danger of importing the subkey again without the Binding Signature
   Revocation.

Notes:

If there are more than one subkeys, the removing of one leaves more
than one key. And the warning is missing.

Changed to editorial.

Errata ID: 2243

Status: Held for Document Update
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 13.9. says:

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with BS+2 octets of random data, such that
   octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   resynchronization after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the IV is 10 octets long and octets 7 and 8 of the IV are the same as
   octets 9 and 10.  For an algorithm with a block size of 16 octets
   (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
   octets 15 and 16.  Those extra two octets are an easy check for a
   correct key.

It should say:

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with BS+2 octets of random data, such that
   octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   resynchronization after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the virtual IV is 10 octets long and octets 7 and 8 of the virtual IV
   are the same as octets 9 and 10.  For an algorithm with a block size
   of 16 octets (128 bits), the virtual IV is 18 octets long, and octets
   17 and 18 replicate octets 15 and 16. Those extra two octets are an
   easy check for a correct key."

Notes:

'IV' is used in a contradicting manner.

Changed to editorial.

From Jon. C.: This is a marvelous re-wording of a confusing process. I really like the “virtual IV” mentioned. However, the suggested change omitted the final sentence, which is the whole reason for the virtual IV. I have restored that sentence.

Status: Rejected (32)

RFC 4880, "OpenPGP Message Format", November 2007

Source of RFC: openpgp (sec)

Errata ID: 2197

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 3.5. says:

A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC.

It should say:

A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC, ignoring leap
seconds.

Notes:

And I did not yet talk about relativity theory.
--VERIFIER NOTES--
The OpenPGP time is an integer denoting UTC time. An implementation is free to display with or without leap seconds just as it might display said time in a time zone.

Errata ID: 2198

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 3.7.1.3. says:

Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.
Then the salt, followed by the passphrase data, is repeatedly hashed
until the number of octets specified by the octet count has been
hashed.

It should say:

Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.
Then the concatenation of salt and passphrase data is repeated
sufficiently often and concatenated. The concatenation is truncated
to the number of octets specified by the octet count. The truncated
concatenation is hashed.

Notes:

Did I get it right? If not, clearify it.
There are a lot of interpretations of the fuzzy instruction.
E.g. it could be repeat{data:=truncate(concatenate(hash(data)))} until
the octet count is exceeded. And it is still unclear weather you have to
count for each hash context separately and weather you have to count the
preloads, too.
--VERIFIER NOTES--
Submitter does not even know if the erratum is correct.

Errata ID: 2201

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.2. says:

   The first octet of the packet header is called the "Packet Tag".  It
   determines the format of the header and denotes the packet contents.
   The remainder of the packet header is the length of the packet.
   ...
              +---------------+
         PTag |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one
         Bit 6 -- New packet format if set

It should say:

   The first octet of the packet header encodes the packet format and
   the "Packet Tag".  It determines the format of the header and denotes
   the packet contents. The remainder of the packet header is the length
   of the packet body.
   ...
              +---------------+
              |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one
         Bit 6 -- New packet format if set

Notes:

Only a part of the first octet (depending on the packet format, i.e.
depending on bit 6 of the first octet) is the Packet Tag.
The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The suggestion is incorrect. The first octet of the header is called the packet tag. The packet tag contains other information besides tag information, but it is nonetheless called (and has always been called) the packet tag.

Errata ID: 2202

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.4.1. says:

   0 - The packet has a one-octet length.  The header is 2 octets long.

   1 - The packet has a two-octet length.  The header is 3 octets long.

   2 - The packet has a four-octet length.  The header is 5 octets long.

It should say:

   0 - The packet body has a one-octet length.  The header is 2 octets
       long.

   1 - The packet body has a two-octet length.  The header is 3 octets
       long.

   2 - The packet body has a four-octet length.  The header is 5 octets
       long.

Notes:

The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The language is clear in the document. The Body Length refers to the length of the body. Colloquially, the document calls this the packet length, but OpenPGP is hardly unique in being a TLV record system in which the length is the length of the value, not of the Tag, Length, and Value.

Errata ID: 2203

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.4.2. says:

   1. A one-octet Body Length header encodes packet lengths of up to 191
      octets.

   2. A two-octet Body Length header encodes packet lengths of 192 to
      8383 octets.

   3. A five-octet Body Length header encodes packet lengths of up to
      4,294,967,295 (0xFFFFFFFF) octets in length.  (This actually
      encodes a four-octet scalar number.)

   4. When the length of the packet body is not known in advance by the
      issuer, Partial Body Length headers encode a packet of
      indeterminate length, effectively making it a stream.

It should say:

   1. A one-octet Body Length header encodes packet body lengths of up
      to 191 octets.

   2. A two-octet Body Length header encodes packet body lengths of 192
      to 8383 octets.

   3. A five-octet Body Length header encodes packet body lengths of up
      to 4,294,967,295 (0xFFFFFFFF) octets in length.  (This actually
      encodes a four-octet scalar number.)

   4. When the length of the packet body is not known in advance by the
      issuer, Partial Body Length headers encode a packet of
      indeterminate length, effectively making it a stream.

Notes:

The packet consists of header and body. The encoded length is the length
of the packet body.
--VERIFIER NOTES--
The language is clear in the document. The Body Length refers to the length of the body. Colloquially, the document calls this the packet length, but OpenPGP is hardly unique in being a TLV record system in which the length is the length of the value, not of the Tag, Length, and Value.

Errata ID: 2205

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.1. says:

   The value "m" in the above formulas is derived from the session key
   as follows.  First, the session key is prefixed with a one-octet
   algorithm identifier that specifies the symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended, which is equal to the
   sum of the preceding session key octets, not including the algorithm
   identifier, modulo 65536.  This value is then encoded as described in
   PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to
   form the "m" value used in the formulas above.  See Section 13.1 of
   this document for notes on OpenPGP's use of PKCS#1.

It should say:

?

Notes:

That is how to derive m from the session key and the algorithm
identifier.
But how to derive the session key and the algorithm identifier from m?
--VERIFIER NOTES--
Not actionable. No actual erratum.

Errata ID: 2225

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.9. says:

   If the special name "_CONSOLE" is used, the message is considered to
   be "for your eyes only".

It should say:

   If the special name "_CONSOLE_" is used, the message is considered to
   be "for your eyes only".

Notes:

If the name is actually "_CONSOLE", you should explicitly mention it.
--VERIFIER NOTES--
Erratum is wrong.

Errata ID: 2228

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.13. says:

   The plaintext of the data to be encrypted is passed through the SHA-1
   hash function, and the result of the hash is appended to the
   plaintext in a Modification Detection Code packet.  The input to the
   hash function includes the prefix data described above; it includes
   all of the plaintext, and then also includes two octets of values
   0xD3, 0x14.  These represent the encoding of a Modification Detection
   Code packet tag and length field of 20 octets.

It should say:

   The concatination of the prefix data descibed above, the plaintext to
   be encrypted and two octets of values 0xD3, 0x14 (These represent the
   encoding of a Modification Detection Code packet tag and length field
   of 20 octets) is passed through the SHA-1 hash function.

Notes:

The text is misleading and contradicting.
--VERIFIER NOTES--
Erratum is incorrect.

Errata ID: 2232

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 6.3. says:

   The encoded output stream must be represented in lines of no more
   than 76 characters each.

It should say:

   The encoded output stream MUST be represented in lines in according
   to the following algorithm.
   Choose a maximal line width w not greater than 76.  Insert after each
   w characters a line break.  If the last = (the beginning of the
   encoded checksum) is not at the beginning of a line, one line break
   MAY be inserted before the last =.

Notes:

The old formulation allows lines of different length and even empty
lines.
--VERIFIER NOTES--
The submitter describes legal, correct behavior, and amends the text to disallow it.

Errata ID: 2237

Status: Rejected
Type: Technical

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 11.1. says:

   User Attribute packets and User ID packets may be freely intermixed
   in this section, so long as the signatures that follow them are
   maintained on the proper User Attribute or User ID packet.

It should say:

   User Attribute packets and User ID packets may be freely intermixed
   in this section, so long as the signatures that follow them are
   maintained on the proper User Attribute or User ID packet, and as
   long the first one is a User ID packet.

Notes:

The first one must be a User ID packet and must not be a User Attribute
packet.
--VERIFIER NOTES--
The RFC is correct. It says that they may be freely intermixed, to denote that they may be freely intermixed.

Errata ID: 3725

Status: Rejected
Type: Technical

Reported By: Kwadronaut
Date Reported: 2013-09-14
Rejected by: Sean Turner
Date Rejected: 2014-01-14

Section 5.2.3.11. says:

Some implementations do not represent the interest of a single user
(for example, a key server).  Such implementations always trim local
certifications from any key they handle.


It should say:

Some implementations do not represent the interest of a single user
(for example, a key server).  Such implementations MUST always trim 
local certifications from any key they handle.


Notes:

Inspiration taken from a thread on sks-devel: http://lists.nongnu.org/archive/html/sks-devel/2013-09/msg00022.html

--VERIFIER NOTES--
As agreed by the authors, MUST is unnecessary here.

Errata ID: 2204

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.1. says:

   The recipient of the message finds a session key that is encrypted
   to their public key, decrypts the session key, and then uses the
   session key to decrypt the message.

It should say:

   The recipient of the message finds a Public-Key Encrypted Session Key
   packet that contains the session key encrypted with the recipient's
   public key, decrypts the session key, and then uses the session key
   to decrypt the message.

Notes:

There is only one session key, the session key, not a session key.
The recipient is singular.
Encrypted with public key, will be decrypted with secret key. Encrypted
(with the public key) to some cipher.
--VERIFIER NOTES--
The suggestion is more precise, but harder to read.

Errata ID: 2207

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2. says:

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted to a V3 key, it is reasonable to create a
   V3 signature.

It should say:

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted with a V3 key, it is reasonable to create a
   V3 signature.

Notes:

Encrypted with a key to some cipher.
--VERIFIER NOTES--
I think we can accept that encrypting implicitly means there’s a cipher involved.

Errata ID: 2209

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.2. says:

     - One-octet length of following hashed material.  MUST be 5.

         - One-octet signature type.

         - Four-octet creation time.

It should say:

     - Six-octet with the following three items.

         - One-octet length of the remaining two items which are
           included in the hash.  MUST be 5.

         - One-octet signature type.

         - Four-octet creation time.

Notes:

It is not the lenght of hashed material, but it is the length of the
next two items, which are included in the hash. And these three items
belong together and have six-octet length.
--VERIFIER NOTES--
Erratum is incorrect.

Errata ID: 2210

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.2. says:

        - Two-octet field holding left 16 bits of signed hash value.

It should say:

        - Two-octet field holding the first 16 bits of signed hash
          value.

Notes:

left is misleading. It could be remaining (from leave). And there are
cultures where the last letters of a line are on the left side.
The convention is high digit before (not left of) low digit (which may
be odd for Arabs).
--VERIFIER NOTES--
The erratum makes good point that “left” is used where “first” or “high-order” might have been a better term. However, given that we know that we use Network Byte Order, “left” is a reasonable synonym for “first.” The IETF works in English and NBO; the comments about Arabs are well-taken, but pedantic and add no value.

Additionally, a search of other RFCs shows that we are not alone in using “left” to mean “high-order.” While this may be idiomatic rather than well-defined, our research shows it’s an IETF idiom as much as an OpenPGP idiom.

Errata ID: 2211

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.2. says:

   The details of the calculation are different for DSA signatures than
   for RSA signatures.

It should say:

   The details of the calculation are different for DSA signatures from
   that for RSA signatures.

Notes:

different from, not different than
--VERIFIER NOTES--
Our research shows that this is a matter of opinion -- in US English grammar, the “different than” is acceptable this way. Jon prefers “different from” (the suggested erratum) and David “different than.” Thus our agreed resolution is to reject, as this is debate over usage, not an actual erratum.

Errata ID: 2212

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3. says:

     - Two-octet field holding the left 16 bits of the signed hash
       value.
   ...
   The left 16 bits of the hash are included in the Signature packet to
   provide a quick test to reject some invalid signatures.

It should say:

     - Two-octet field holding the high 16 bits of the signed hash
       value.
   ...
   The high 16 bits (first two octets) of the hash are included in the
   Signature packet to provide a quick test to reject some invalid
   signatures.

Notes:

Use exactly the sentence from 5.2.2.

left is misleading. It could be remaining (from leave). And there are
cultures where the last letters of a line are on the left side.
The convention is high digit before (not left of) low digit (which may
be odd for Arabs).
--VERIFIER NOTES--
Like errata 2210, but here Constantin corrects to “high” rather than “first.” I don’t believe either is so misleading as to warrant a change.

Errata ID: 2213

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3. says:

     - Two-octet scalar octet count for following hashed subpacket data.
     - Hashed subpacket data set (zero or more subpackets).
     - Two-octet scalar octet count for the following unhashed subpacket
       data. 
     - Unhashed subpacket data set (zero or more subpackets).

It should say:

     - Two-octet scalar octet count for following hashincluded subpacket
       data.
     - Hashincluded subpacket data set (zero or more subpackets).
     - Two-octet scalar octet count for the following not hashincluded
       subpacket data. 
     - Not hashincluded subpacket data set (zero or more subpackets).

Notes:

The first field does not contain a hash. But it is included in the hash.
Unhashing is the reverse of hashing, which is hopefully unfeasible.
--VERIFIER NOTES--
This is incorrect.

Errata ID: 2215

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3.1. says:

   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

It should say:

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.

Notes:

The explanation for recognizing should come before recognizing is used.
--VERIFIER NOTES--
The existing text explains the rule of thumb, and then the exception. The suggestion would be more confusing than the original.

Errata ID: 2217

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.3.18. says:

   Note also that since this is a URI, the key server can actually be a
   copy of the key retrieved by ftp, http, finger, etc.

It should say:

?

Notes:

Nonsense. The key server is not a copy of a key.
I do not get the point. What should be noted?

Modified to editorial.
--VERIFIER NOTES--
Not actionable. No actual erratum. To answer the question, this text reminds the reader that a URI can refer to a static entity, as well as a query to a server. Yes, this is arguably superfluous, but it is there because of the WG’s rough consensus.

Errata ID: 2218

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.2.4. says:

   All signatures are formed by producing a hash over the signature
   data, and then using the resulting hash in the signature algorithm.

   For binary document signatures (type 0x00), the document data is
   hashed directly.  For text document signatures (type 0x01), the
   document is canonicalized by converting line endings to <CR><LF>,
   and the resulting data is hashed.

   When a signature is made over a key, the hash data starts with the
   octet 0x99, followed by a two-octet length of the key, and then body
   of the key packet.  (Note that this is an old-style packet header for
   a key packet with two-octet length.)  A subkey binding signature
   (type 0x18) or primary key binding signature (type 0x19) then hashes
   the subkey using the same format as the main key (also using 0x99 as
   the first octet).  Key revocation signatures (types 0x20 and 0x28)
   hash only the key being revoked.

   A certification signature (type 0x10 through 0x13) hashes the User
   ID being bound to the key into the hash context after the above
   data.  A V3 certification hashes the contents of the User ID or
   attribute packet packet, without any header.  A V4 certification
   hashes the constant 0xB4 for User ID certifications or the constant
   0xD1 for User Attribute certifications, followed by a four-octet
   number giving the length of the User ID or User Attribute data, and
   then the User ID or User Attribute data.

   When a signature is made over a Signature packet (type 0x50), the
   hash data starts with the octet 0x88, followed by the four-octet
   length of the signature, and then the body of the Signature packet.
   (Note that this is an old-style packet header for a Signature packet
   with the length-of-length set to zero.)  The unhashed subpacket data
   of the Signature packet being hashed is not included in the hash, and
   the unhashed subpacket data length value is set to zero.

   Once the data body is hashed, then a trailer is hashed.  A V3
   signature hashes five octets of the packet body, starting from the
   signature type field.  This data is the signature type, followed by
   the four-octet signature time.  A V4 signature hashes the packet body
   starting from its first field, the version number, through the end
   of the hashed subpacket data.  Thus, the fields hashed are the
   signature version, the signature type, the public-key algorithm, the
   hash algorithm, the hashed subpacket length, and the hashed
   subpacket body.

   V4 signatures also hash in a final trailer of six octets: the
   version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet,
   big-endian number that is the length of the hashed data from the
   Signature packet (note that this number does not include these final
   six octets).

   After all this has been hashed in a single hash context, the
   resulting hash field is used in the signature algorithm and placed
   at the end of the Signature packet.

It should say:

   All signatures are formed by producing a hash over the signature
   data, and then using the resulting hash in the signature algorithm.

   The signature data is the concatenation of a body and a trailer.

   For binary document signatures (type 0x00), the document data is
   is the sinature data body.  For text document signatures (type 0x01),
   the document is canonicalized by converting line endings to <CR><LF>,
   and the resulting data is the sinature data body.

   When a signature is made over one key, the signature data body is a
   Public-Key packet (see 5.5.) in the old packet format with two-octet
   body length (octet 0x99, followed by the two-octet body length,
   followed by the Public-Key packet body).  The signature data body of
   a subkey binding signature (type 0x18) or of a primary key binding
   signature (type 0x19) is the concatination of the Public-Key packet
   of the main key and a Public-Key (not a Public-Subkey packet) packet
   of the subkey in the format discribed above.  The signature data body
   of a Key Revocation signatures (type 0x20 or 0x28) is the Public-Key
   packet of the key being revoked in the format described above.

   The signature data body for a V3 certification signature (type 0x10
   through 0x13) is the concatination of the key packet in the format
   described above and the body of a User ID packet (see 5.11.).  The
   signature data body for a V4 certification signature (type 0x10
   through 0x13) is the concatenation of the key packet in the format
   descibed above, either the constant 0xB4 for User ID certification or
   the constant 0xD1 for User Attribute certification (User Attribute
   packets are not a required part of the OpenPGP standard.  Except as
   noted, a User Attribute packet may be used anywhere that a User ID
   packet may be used. (see 5.12.)),  a four-octet number giving the
   length of the User ID Packet body, and the User ID Packet body.
   (0xB4 starts an old-style packet header of a User ID packet with
   one-octet body length and 0xD1 starts the new-style packet header of
   a User Attribute packet.  But the body length is encoded
   differently.)

   When a signature is made over a Signature packet (type 0x50), the to
   signed Signature packet is trimmed by leaving out the not
   hashincluded subpacket data and setting the not hashincluded
   subpacket data length to zero.  The body of the signature data is the
   octet 0x88, followed by the four-octet-length of the to be signed
   Signature packet body, followed by the to be signed Signature packet
   body.  (0x88 starts an old-style packet header of a Signature packet
   with one-octet body length.  But the body length is encoded
   differently.)

   The signature data trailer for a V3 signature are five octets of the
   signature packet body, starting from the signature type field. This
   data is the signature type followed by the four-octet signature time.
   The signature data trailer for a V4 signature is the concatenation
   of a part of the signature packet body starting from the first field,
   the version number, through the end of the hashincluded subpacket
   data, one more time the version number (0x04), 0xFF, and a four-octet
   number of the length of the part included from the signature packet.

Notes:

The original is nearly unintelligible. Key, key packet, key packet body,
etc are confused until a signature hashes the User ID into a hash
context (sic!).

The 0x99 for all public-keys and the differently encoded body lenght for
User ID packets and User Attribute packets is really odd.
Proposal:
A Flag and a Feature for a new encoding of the signature body. Usage of
a the actual new-style packet headers with 0xFF and four-octet body
length.

Changed to editorial.
--VERIFIER NOTES--
As complex as the RFC’s text may be, it’s been through the IETF process including people actually coding to it. I don’t find the change any less complex and might contain errors.

Errata ID: 2220

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

     - A Public-Key or Public-Subkey packet, as described above.

It should say:

     - A Public-Key or Public-Subkey packet body, as described above.

Notes:

There is no Public-Key packet header in the Secret-Key packet body.

Changed to editorial.
--VERIFIER NOTES--
Similar to Errata 2202 and 2203, it is an idiom of the document to say “packet” when it might be more precise to say “packet body.” It is, however, clear. If there are inconsistencies in this idiom, they’d make reasonable errata.

Errata ID: 2221

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

     - If the string-to-key usage octet is zero or 255, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536).

It should say:

     - If the string-to-key usage octet is not 254, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536).

Notes:

Without the values values of 1 to 253 the following
Note that for all other values, a two-octet checksum is required.
is not just a note.

Changed to editorial.
--VERIFIER NOTES--
The RFC is correct.

Errata ID: 2223

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

       This checksum or hash is encrypted together with the
       algorithm-specific fields (if string-to-key usage octet is not
       zero).

It should say:

       For V4 keys this checksum or hash is encrypted together with the
       algorithm-specific fields (if string-to-key usage octet is not
       zero).

Notes:

The following text says:
With V3 keys, the checksum is stored in the clear. With V4 keys,
the checksum is encrypted like the algorithm-specific data.

Changed to editorial.
--VERIFIER NOTES--
Text describing V3 keys precedes this text.

Errata ID: 2224

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.5.3. says:

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet.  A different mode is used with V3 keys (which are only RSA)
   than with other key formats.  With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix.

It should say:

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet.

   A different mode is used with V3 keys (which are only RSA)
   than with other key formats.  With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix.

Notes:

It is unclear if the Furthermore belongs only to V3 keys.

Changed to editorial.
--VERIFIER NOTES--
Text is in a paragraph describing V3 keys.

Errata ID: 2227

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.12. says:

   A User ID packet consists of UTF-8 text that is intended to represent
   the name and email address of the key holder.

It should say:

   A User ID packet body consists of UTF-8 text that is intended to
   represent the name and email address of the key holder.
or
   A User ID packet contains UTF-8 text that is intended to represent
   the name and email address of the key holder.

Notes:

Yes, it is pedantic. But the packet consists of header and body.
--VERIFIER NOTES--
Similar to errata 2220 etc. It is indeed pedantic as submitter notes.

Errata ID: 2229

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.13. says:

      Suffice it to say that many people consider properties such as
      deniability to be as valuable as integrity.

It should say:

      It is sufficient to say that many people consider properties such
      as deniability to be as valuable as integrity.

Notes:

Is that an imperative?
--VERIFIER NOTES--
Suggestion isn’t grammatical.

Errata ID: 2230

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.14. says:

   The Modification Detection Code packet MUST be the last
   packet in the plaintext data that is encrypted in the Symmetrically
   Encrypted Integrity Protected Data packet, and MUST appear in no
   other place.

It should say:

   The Modification Detection Code packet MUST be the last
   packet in the plaintext data that is encrypted in the Symmetrically
   Encrypted Integrity Protected Data packet, and MUST NOT appear in any
   other place.

Notes:

'MUST appear in no other place' postulates an existence in the nowhere.
--VERIFIER NOTES--
On its surface, a good suggestion, but lacks the force of the original.

Errata ID: 2231

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 5.14. says:

   A Modification Detection Code packet MUST have a length of 20 octets.

It should say:

   A Modification Detection Code packet MUST have a body length of 20
   octets.

Notes:

The packet consists of header and body.
--VERIFIER NOTES--
Similar to errata 2220 etc. It is indeed pedantic as submitter notes.

Errata ID: 2233

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 6.4. says:

   In Radix-64 data, characters other than those in the table, line
   breaks, and other white space probably indicate a transmission error,
   about which a warning message or even a message rejection might be
   appropriate under some circumstances.  Decoding software must ignore
   all white space.

   Because it is used only for padding at the end of the data, the
   occurrence of any "=" characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit).  No
   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three and no "=" characters are
   present.

It should say:

   In Radix-64 data, characters other than those in the table, line
   breaks earlier than defined by the first line's length without
   following '=' or '-', line breaks at the beginning of a line, and
   other white space probably indicate a transmission error, about which
   a warning message or even a message rejection might be appropriate
   under some circumstances.  After that check, decoding software must
   ignore all white space.

   The boundary between encoded data and encoded checksum is before the
   last '=' of a sequence of one, two or three '='.

Notes:

Might reject and must ignore is a contradiction.
There is always at least one '=', i.e. the beginning of the encoded
checksum.

Changed to editorial.
--VERIFIER NOTES--
There is no contradiction. The implementation must ignore all whitespace, and must reject all bogus ‘=’ characters.

Errata ID: 2239

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 12.1. says:

   Entries in square brackets are optional and ellipses indicate
   repetition.
   ...
           Primary-Key
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [User Attribute [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

It should say:

   Entries in square brackets are optional, vertical bar separates
   alternatives, and ellipses indicate repetition.
   ...
           Primary-Key
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [[User ID [Signature ...] |
                      [User Attribute [Signature ...]]...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

Notes:

11.1. says:
User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet, and as
long the first one is a User ID packet.

Changed to editorial.
--VERIFIER NOTES--
The RFC is correct. It says that they may be freely intermixed, to denote that they may be freely intermixed.

Errata ID: 2241

Status: Rejected
Type: Editorial

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 12.2. says:

   The fingerprint of a V3 key is formed by hashing the body (but not
   the two-octet length) of the MPIs that form the key material (public
   modulus n, followed by exponent e) with MD5.

It should say:

   The fingerprint of a V3 key is formed by hashing the concatenation
   of the bodies of the MPIs (MPI without two-octet length) that form
   the key material (public modulus n, followed by exponent e) with MD5.

Notes:

There are two bodies and one hash.

Changed to editorial.
--VERIFIER NOTES--
It could have been:

... by hashing the body (but not the two-octet length) of the two MPIs
^^^

But, it's clear from the parenthetical that there are two MPIs.

Report New Errata



Search RFCs
Advanced Search
×