Re: [openpgp] [[e-mail]] New Version Notification for draft-ietf-openpgp-rfc4880bis-10.txt

["Neal H. Walfield" <[e-mail]>]

On Tue, 15 Sep 2020 10:33:19 +0200,
Justus Winter wrote:
> "Neal H. Walfield" <[e-mail]> writes:
> >   30d8397 Introduce the Key Block subpacket to align OpenPGP with CMS.
> >
> > I think the idea is okay, but the execution (what should and should
> > not be included) could use some work.
>
> Even though I initially proposed it, I now have my doubts about the
> design and would have appreciated a discussion on this list first.

I agree with you Justus, but I don't see the situation quite as dire
as you.

> The problem I see is that the size of a subpacket area is limited to
> 1<<16 bytes.  This severely limits the number of certificates that can
> be communicated with this mechanism.

PQ keys are still a ways off.  One approach to workaround this
limitation would be to raise the maximum size of the subpacket areas
for v5 signatures *now*.  This is relatively straightforward.

> For example, the Bob sample key (D1A6 6E1A 23B1 82C9 980F 788C FBFC C82A
> 015E 7330) measures 1741 bytes, meaning we could fit 37 of those into a
> subpacket area.  On the other hand, my cert weighs in at 9148 bytes,
> bringing this number down to 7.
>
> Now, these are both certificates with RSA keys and signatures, and the
> numbers are way better with ECC.  But, we don't know how large PQ keys
> and signatures will be.  Notably, if the cryptographic community settles
> on McEliece, we will not be able to fit a single key, let alone a
> certificate, into a subpacket area.

These certificates can be minimized.  Using gpg's export minimal
option, I get 6521 bytes for your key:

  $ sq keyserver get 0x9B7DD433F254904A | gpg --import; gpg --export-options export-minimal --export 0x9B7DD433F254904A | wc -c

Inspecting the minimal key, I see that there is still a fair amount
that can be stripped:

  $ gpg --export-options export-minimal --export 0x9B7DD433F254904A | sq inspect
  -: OpenPGP Certificate.

      Fingerprint: CBCD 8F03 0588 653E EDD7  E265 9B7D D433 F254 904A
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 4064 bits
    Creation time: 2017-07-19 16:28:55 UTC
  Expiration time: 2022-07-18 16:28:55 UTC (creation time + P1825D)
        Key flags: certification

           Subkey: A7E0 0611 1566 B481 A1FE  04CF C471 3E5A A93F 9D68
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 2048 bits
    Creation time: 2017-07-19 16:36:26 UTC
  Expiration time: 2022-07-25 15:31:26 UTC (creation time + P1831DT82500S)
        Key flags: authentication

           Subkey: 256A 4E55 E4A7 2D97 AD24  68E7 88DC 7E33 385F 791D
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 2048 bits
    Creation time: 2017-07-19 16:32:31 UTC
  Expiration time: 2022-07-25 15:31:26 UTC (creation time + P1831DT82735S)
        Key flags: signing

           Subkey: 0628 A563 C5F2 D310 7D6C  9574 08CC 70F8 D8CC 765A
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 2048 bits
    Creation time: 2017-07-19 16:34:06 UTC
  Expiration time: 2022-07-25 15:31:26 UTC (creation time + P1831DT82640S)
        Key flags: transport encryption, data-at-rest encryption

           UserID: Justus Winter <[e-mail]>

           UserID: Justus Winter <[e-mail]>

           UserID: Justus Winter <[e-mail]>

           UserID: Justus Winter <[e-mail]>

           UserID: Justus Winter <[e-mail]>

Clearly, the authentication subkey can go, as can all but one of the
user ids and their self-signatures.

But, let's think about what we *really* need.  Let's say I send you
and Alice a message and Alice wants to reply to all.  In that case,
Alice only needs our encryption subkeys.  Really.  In the context of
the thread, it is reasonable for Alice to use the same keys as I use;
my signature (this subpacket is in the hashed area!) is a de facto
certification that the keys should be used for this group
conversation.  (My signature binds the thread and the set of keys.)

So all Alice really needs is a list of the encryption subkeys.  Alice
doesn't need your signing subkey, because she is not verifying a
signature from you; she only needs my signing subkey.  In fact, she
doesn't need your signing key until you send a message, which you, as
the sender, can include!

(Admittedly, it is useful to include the primary key so that when
Alice replies, you can verify that it was signed with a key that I
authenticated for the purpose of this thread.)

What about the certificate's preferences?  Well, Alice can infer a
reasonable set of preferences by simply copying the preferences that I
used.  (Neal encrypted the message using AES-128 and the signature
used SHA-256, ok, I'll do the same.)

What she might need is the expiration time, but my implementation
compute the minimum over all keys and store that in the Key Expiration
Time subpacket of my signature.

What happens if Alice wants to remove someone from cc?  Well, we could
include a User ID.  If we don't add the self-signature this normally
only adds a few dozen bytes.  (Note: if not including the primary key
is too extreme, because you really want something that looks like a
TPK, 4880 doesn't require that a User ID in a TPK have a self
signature [1].)

  [1] https://tools.ietf.org/html/rfc4880#section-11.1


Let's do a bit of math.  A 4k RSA key, which is the worst case right
now, requires:

  Key: ~272 bytes
  Signature: ~571 bytes

So, for a minimal valid TPK, we have:

  [ Primary ] [ Direct Sig ] [ User ID ] [ Subkey ] [ Self sig ]

  272 + 571 + 24 + 272 + 571 = 1710 bytes

or:

  [ Primary ] [ User ID ] [ Self sig ] [ Subkey ] [ Self sig ]

  272 + 24 + 571 + 272 + 571 = 1710 bytes

This allows for 38 recipients in cc.  For most group chats, 38
participants is probably enough.  If you have more, then it is
probably a broadcast.  That is, replies are not expected, and then you
can just elide most of this.

But, using the more extreme variant that I proposed above, we only
need:

  [ User ID ] [ Subkey ]

  20 + 272 = 292 bytes

which allows for about 292 recipients.


Neal