5.2.3.4. Issuer
(8 octet key ID)
The OpenPGP key ID of the key issuing the signature.
MUST be present in the hashed area.
keyid can be unhashed. I'm not sure it makes sense to have a mandatory
unhashed packet, since unhased packets can have no security properties.
section 5.6 says:
Typically, this packet is found as the contents of an encrypted packet,
or following a Signature or One-Pass Signature packet, and contains
literal data packets.
does this mean that multiple contiguous literal data packets can be
compressed into a compressed data packet? if so, how is an
implementation supposed to interpret multiple literal data packets
contained in a single compressed data packet?
This is an area of ambiguity we have run into. Can you put multiple
literal data packets into compressed or encrypted data? Can they be
inside/after signature packets?
My feeling is that it should be allowed. Literal packets can have file
names associated with them and so this would be an efficient mechanism
for transferring multiple files. I don't know what the current
implementations do.
section 6.1 has:
#define CRC24_POLY 0x1864cfbL
should this not be:
#define CRC24_POLY 0x864cfbL
Not if you want the code to work... note the line where that constant
is used, the high "1" is used to clear a "1" in the crc variable.
section 11.2 says:
A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
Tag, followed by the two-octet packet length, followed by the entire
Public Key packet starting with the version field.
strictly speaking, this seems to imply that only old packet format packets
can be used. i presume that is not what is meant. how about the following
wording:
A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key
packet (i.e. the entire packet header and all of the packet body fields).
No, it has to be a two byte length. The length must be canonicalized
to two bytes. Otherwise there may be ambiguity in that the same length
can be expressed in different forms.
section 11.2 says:
a.2) high order length octet of (b)-(f) (1 octet)
a.3) low order length octet of (b)-(f) (1 octet)
what does (f) refer to here?
Should be (e).
section 12.1 says:
Note also that if an implementation does not implement the preference,
then it is implicitly a TripleDES-only implementation.
what does the phrase "the preference" refer to? does it mean if an
implementation doesn't implement a system of preferences?
More specifically, that it doesn't support the preferred algorithm
subpacket. It doesn't create them, it doesn't read them. It should
always use triple des.
Hal