Subject: [openpgp] Issues from a novice reader

From: Stuart Schechter <[email-masked]>
Date: Sat, 26 Jun 2021 11:57:32 +0900

Hi everyone.

I've been combing through the working spec as I try to add support for
transferring keys into PGP format into a crypto library (the DiceKeys
seeded cryptography library) and an app that generates keys from physical
randomness (DiceKeys).  This is my first time working with PGP keys and
with the spec so I have been trying to understand it with a fresh set of
eyes.

I've filed five issues based on points where I'm genuinely confused.  I
haven't engaged with an IETF group for over a decade so I hope you'll
excuse me if I'm doing so incorrectly.

The issues are:
   #32 <https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/32>: an
inconsistency between the number of stated optional fields (4) and actual
optional fields (3).

   #33 <https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/33>: ambiguity
about whether checksums are included in a v5 length packet

   #34 <https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/34>: challenges
for the reader to identify which fields changed in v5 packets

   #35 <https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/35>: ambiguity
about whether packet headers are included when a secret-key packet starts
with the contents of the corresponding public-key packet.

   #36 <https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/36>: confusion
about if/how one SHOULD self-sign secret keys that cannot themselves be
used to create signatures (e.g., EC DH keys)

Thanks so much,

Stuart Schechter
DiceKeys / UC Berkeley

---

From: Werner Koch <[email-masked]>
Date: Sat, 26 Jun 2021 16:37:03 +0200

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.