[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: Update keys.gnupg.net?
From:       Jeffrey Walton via Gnupg-devel <gnupg-devel () gnupg ! org>
Date:       2021-07-31 15:14:25
Message-ID: CAH8yC8mXFb_ujn5jvVBVn-LND4COv+=cgb+3+oSuReYxGppG2w () mail ! gmail ! com
[Download RAW message or body]

On Sat, Jul 31, 2021 at 6:05 AM Werner Koch via Gnupg-devel
<gnupg-devel@gnupg.org> wrote:
>
> On Thu, 29 Jul 2021 12:52, Phil Pennock said:
>
> > I have both an RSA key and an Ed25519 key.  Every time I think I can
> > just use the Ed25519 key, I encounter a new system where that assumption
> > fails, so even for $work I ended up having to create an RSA key too.
>
> So what you are saying is that there are implementations with Web Key
> Directory support but no support for Ed25519?
>
> > ecosystems.  Client implementations will end up having tiered preference
> > systems, with quantum-resistant first tier, Ed25519 second tier, etc.
>
> I don't think so.  This would soon get two complicated.  My current idea
> for PQC is to have a single algorithm id describing the first and
> second tier with just one identifier (e.g. NTRU, RSA).

How about something like X.509 basic constraints?

You would have a structure with a blob in it. The blob could be a RSA
key, Ed25519 key, etc. However, the blob would also have a bit that
could be set as critical. A client can ignore a blob not marked as
critical. A client must fail if a blob is marked as critical but the
client does not understand it.

X.509's basic constraints have the benefit of being forward
compatible. You can keep adding stuff without worry about breaking
down-level clients.  The client can skip things it does not understand
that are non-critical. The client will fail if it encounters something
it does not understand that is marked critical.

The client is also free to implement its own set of client side
policies, like rejecting a RSA key and requiring an Ed25519 signing
key. Or a client can choose to ignore something marked as critical
(probably a bad idea, but that's choice for you). I would not worry
too much about client side policies. That's up to the user/client to
choose.

Jeff

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
[prev in list] [next in list] [prev in thread] [next in thread]