Hi!
Thanks for your comments. I am fine using the bug tracker to track the
status of a suggestion/bug/feature. For discussion I still believe that
the ML list is a better place. So I took the freedom to copy the
content of your five reports below. It refer to the lates git HEAD and
proabbly not to the last I-D. In fact, we should soon turn to an I-D
based discussion again.
Shalom-Salam,
Werner
Here we go:
#32 An inconsistency between the number of stated optional fields (4)
and actual optional fields (3).
Only for a version 5 packet, a one-octet scalar octet count of the
next 4 optional fields.
There are only 3 optional fields listed below is line about the next 4
optional fields. Is it 3 or is the composite s2k two fields? Example
correct values for different situations would be very helpful since it
seems like it might be an all-or-nothing thing where the count is used
in anticipation of more fields in the future?
Also, I found it unclear what optional means here. They are optional
because they MAY be included under the stated conditions, or because
they MUST be included under those conditions.
#33 Ambiguity about whether checksums are included in a v5 length packet
- Only for a version 5 packet, a four-octet scalar octet count for
the following secret key material. This includes the encrypted
SHA-1 hash or AEAD tag if the string-to-key usage octet is 254 or
253.
Does it include the two-byte checksum if the material is not encrypted?
Also, there's no references to "AEAD tag" elsewhere in the spec, and it
wasn't immediately clear that the other references to AEAD were related
to this, so I would appreciate clarification.
#34 Challenges for the reader to identify which fields changed in v5
packets
Help implementers identify changes between packet versions
It would be much easier to update code handling V4 packets for V5 if:
1. All uses of "version 4" were followed by (V4) and all uses of
"version 5" were followed by "V5". As is, an implementer has to
search for both "V5" and "version 5" to try to identify differences.
2. When listing out the contents of V5 packets that are similar to V4
packets, identify those contents that have changed with Only for a
version 5 packet or Only for a version 4 packet as is done for the
secret-key packet but not other packets. For example, in 5.2.4
(computing signatures), I missed that the length field has been
changed from 4 octets to 8 octets because it's buried pages into that
section, nine items down on the second of two long unordered lists.
#35 Ambiguity about whether packet headers are included when a
secret-key packet starts with the contents of the
corresponding public-key packet.
Clarify whether Secret-Key packets contain Public-Key packets, or just
their bodies
The packet contains:
- A Public-Key or Public-Subkey packet, as described above.
In the reference implementation I'm using in trying to create packets,
the Secret-Key packet starts off with content mirroring the Public-Key
packet, but it is only the packet body. The public-key packet header is
not embedded within the Secret-Key packet following the Secret-Key
packets header, as would be the case if a packet (not just the packet
body) were to embedded within the Secret-Key packet.
#36 Confusion about if/how one SHOULD self-sign secret keys that
cannot themselves be used to create signatures (e.g., EC DH keys)
Clarify self signatures in the context of private keys that can't be
used for signing
Implementations SHOULD include self-signatures on any User IDs and
subkeys
Self signatures are defined as follows: A self-signature is a binding
signature made by the key to which the signature refers.
There is a category of secret keys that can be used for encryption but
not for digital signatures (e.g., EC DH keys) and so, by definition,
they cannot be self-signed.
If I using PGP keys for on-device encryption, and want to store an EC DH
key to a file as a transferable secret key, what would I sign the key
with any why should I sign it? What would I sign it with?
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp