Re: [openpgp] [internet-drafts(_at_)ietf(_dot_)org] New Version Notifica

"Neal H. Walfield" <neal(_at_)walfield(_dot_)org> writes:

> On Tue, 15 Sep 2020 10:33:19 +0200,
> Justus Winter wrote:
> > "Neal H. Walfield" <neal(_at_)walfield(_dot_)org> 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.
PQ keys being way off doesn't mean it is a good idea to come up with
features now that may stop working when PQ gets here.

Raising the maximum subpacket area size may help, but brings its own
problems, like increasing the size of signatures that need to be kept in
memory.  Also, fundamentally, the problem is trying to stuff an object
with a fixed upper size into an object of the same kind.  Think my
binding signature carries an embedded certificate for a third-party
revoker, which may have a third-party revoker, etc.

> > 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:
Indeed, I missed some old subkey binding signatures when calculating the
size.

> Inspecting the minimal key, I see that there is still a fair amount
> that can be stripped:
That seems to help for the very narrow use case of replying to all
recipients, but then it is no longer a replacement for keyservers.
I read Werner's comment that the proposed subpacket is a way to gossip
key updates around:

> Meanwhile, afterh the meltdown of the keyserver network we should bite
> the bullet an do it like it has always been done in CMS.
Neal wrote:

> 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.
Me and my 44 delta.chat friends in one group like to disagree.

> 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.
Extreme :) but what if I have more than one encryption subkey for
different purposes or to support different algorithms?  Further, I don't
think this extreme stripping was envisioned when the subpacket was
introduced.

Justus

signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp