On Tue, 15 Sep 2020 12:16:01 +0200,
Justus Winter wrote:
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.
The sun will explode. But, I'm still making plans for the future.
Every measure is a stopgap solution. And, I think if we continue to
push the ecosystem forward, we'll find other solutions that even if
they don't supersede this one are at least complementary. So, I think
it is worth thinking about this solution, even if it is not as general
as we might like.
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.
Indeed.
I read Werner's comment that the proposed subpacket is a way to gossip
key updates around:
I disagree that keyservers are going to die. Even signal has key
servers (and, think about all of the prekeys).
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.
These days, delta.chat generates ecc keys :D.
https://delta.chat/en/2020-05-27-may-features
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?
If your policy is to encrypt to all encryption-capable subkeys, then I
say: include them all. Currently, there is neither a de jure nor de
facto standard here.
Further, I don't
think this extreme stripping was envisioned when the subpacket was
introduced.
Sure. I also said:
> I think the idea is okay, but the execution (what should and should
> not be included) could use some work.
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp