Mailing List Archive

Hey Bernhard,

As far as I'm concerned, that issue is in the past, and either way
unrelated to the question at hand here.

Cheers

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hey list,

quickly noting an observation here that was news to me just now:
Werner's rfc4880bis and the working group's crypto-refresh drafts
agree that transferable public keys no longer are required to carry
a User ID packet:

https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-00.html#section-11.1

https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-06.html#section-11.1.2

So regardless which one of those you believe in, keys.openpgp.org will
be compliant with the upcoming spec.

Cheers

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Am Mittwoch 11 Januar 2023 00:19:45 schrieb Vincent Breitmoser via
Gnupg-devel:
> So regardless which one of those you believe in,

I hope it is not a "believe", but we can find good reasons
for the best way for OpenPGP users.

> keys.openpgp.org will be compliant with the upcoming spec.

Are you considering to update the FAQ then?
Bernhard


--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

Hi!

On Wed, 11 Jan 2023 00:19, Vincent Breitmoser said:

> Werner's rfc4880bis and the working group's crypto-refresh drafts
> agree that transferable public keys no longer are required to carry
> a User ID packet:

Thanks for noting. Fix below.


Shalom-Salam,

Werner



commit 64ace7e2c10ef92269073e481c1622b522dc0c9f (HEAD -> refs/heads/master)
Author: Werner Koch <wk@gnupg.org>
Date: Thu Jan 12 09:31:19 2023 +0100

Fix composition of public key blocks.

In the course of the reformatting actions of the draft a regression
against 4880 was not fixed (Zero User ID packets). The reason for
introducing zero User ID packets might have been the idea to express
that an Attribute packet may be used instead of a User ID. However,
that should either be clarified in the comments or left to the
implementation.

The second fix is to require at least one Signature packet after a
User ID and Attribute packet. This was wrong in 2440 and 4880 but is
cryptographically required.

Modified rfc4880bis.md
diff --git a/rfc4880bis.md b/rfc4880bis.md
index 038908b..1eaa21a 100644
--- a/rfc4880bis.md
+++ b/rfc4880bis.md
@@ -4083,14 +4083,14 @@ transferable public key are as follows:

- Zero or more revocation signatures

- - Zero or more User ID packets
+ - One or more User ID packets

- - After each User ID packet, zero or more Signature packets
+ - After each User ID packet, one or more Signature packets
(certifications and attestation key signatures)

- Zero or more User Attribute packets

- - After each User Attribute packet, zero or more Signature packets
+ - After each User Attribute packet, one or more Signature packets
(certifications and attestation key signatures)

- Zero or more Subkey packets
@@ -4106,7 +4106,7 @@ may have more than one email address, and construct a User ID for each
one. A transferable public key SHOULD include at least one User ID
packet unless storage requirements prohibit this.

-Immediately following each User ID packet, there are zero or more
+Immediately following each User ID packet, there are one or more
Signature packets. Each Signature packet is calculated on the
immediately preceding User ID packet and the initial Public-Key
packet. The signature serves to certify the corresponding public key
@@ -4119,7 +4119,7 @@ certifications over the associated User ID.

Within the same section as the User ID packets, there are zero or more
User Attribute packets. Like the User ID packets, a User Attribute
-packet is followed by zero or more Signature packets calculated on the
+packet is followed by one or more Signature packets calculated on the
immediately preceding User Attribute packet and the initial Public-Key
packet.


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On 12 Jan 2023, at 08:33, Werner Koch via Gnupg-devel <gnupg-devel@gnupg.org> wrote:
>
> - Zero or more Subkey packets
> @@ -4106,7 +4106,7 @@ may have more than one email address, and construct a User ID for each
> one. A transferable public key SHOULD include at least one User ID
> packet unless storage requirements prohibit this.
>

There is another use case, not previously discussed IIRC, where distributing a TPK without any User ID is desirable. In order to implement RTBF, keyservers must be able to remove personal information from their databases. If a key owner wishes their personal information to be deleted, but this information is attached to a revoked primary key, then removing the entire key from the keyserver will also remove the revocation, which opens a security loophole.

It should be possible to still serve the revocation to those people who already have a copy of the full key, without serving the associated personal information to those who do not. Bare revocations may not be sufficent, as these will only be searchable via the primary key fingerprint, whereas keys are often searched for by a subkey fingerprint (e.g. to validate sigs).

HIP 5 [1] is an attempt to implement a distributable RTBF declaration using direct revocations, however it requires UID-less TPKs, and may also require multiple direct revocations to be distributed (e.g. a key may be RTBFed *and* compromised). This cannot (IMO) be reliably done using only UIDful TPKs or bare revocations.

A

[1] https://github.com/hockeypuck/hockeypuck/wiki/HIP-5:-Reliable-personal-data-deletion-using-self-signatures

On Thu, 12 Jan 2023 12:24, Andrew Gallagher said:

> associated personal information to those who do not. Bare revocations
> may not be sufficent, as these will only be searchable via the primary
> key fingerprint, whereas keys are often searched for by a subkey
> fingerprint (e.g. to validate sigs).

That is not a problem because you need to get the primary key anyway
before you can use a subkey (because of the subkey binding signature).


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On 12 Jan 2023, at 20:11, Werner Koch <wk@gnupg.org> wrote:
>
> On Thu, 12 Jan 2023 12:24, Andrew Gallagher said:
>
>> associated personal information to those who do not. Bare revocations
>> may not be sufficent, as these will only be searchable via the primary
>> key fingerprint, whereas keys are often searched for by a subkey
>> fingerprint (e.g. to validate sigs).
>
> That is not a problem because you need to get the primary key anyway
> before you can use a subkey (because of the subkey binding signature).

True, it’s not a security issue - but it is a usability one. “Key not found” is a temporary error, while “key revoked” is permanent. These are two quite different failure modes, and it would be best to clearly distinguish them.

A

On Fri, 13 Jan 2023 11:00, Andrew Gallagher said:

> True, it’s not a security issue - but it is a usability one. “Key not
> found” is a temporary error, while “key revoked” is permanent. These
> are two quite different failure modes, and it would be best to clearly
> distinguish them.

Sure. But the point here is on how to retrieve a revocation
certificate. To do this you first need to have access to the key -
without the key there is no need to retrieving a revocation. Without a
key you don't know anything about a signature.

In fact you could store a standalone revocation certificate on the
server and allow accessing it by the included issuer fingerprint. A
dedicated keyserver command to do just this might be useful too.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On 13 Jan 2023, at 11:50, Werner Koch <wk@gnupg.org> wrote:
>
> On Fri, 13 Jan 2023 11:00, Andrew Gallagher said:
>
>> True, it’s not a security issue - but it is a usability one. “Key not
>> found” is a temporary error, while “key revoked” is permanent. These
>> are two quite different failure modes, and it would be best to clearly
>> distinguish them.
>
> Sure. But the point here is on how to retrieve a revocation
> certificate. To do this you first need to have access to the key -
> without the key there is no need to retrieving a revocation. Without a
> key you don't know anything about a signature.

Correct. But say we’re trying to look up the key for a strange signature, and we have multiple methods to do so (several disjoint keyservers, WKD, LDAP, etc.). If we get a “key not found” error, that’s just going to encourage us (either manually or via an automated system) to keep trying the other methods. But if we get a “key revoked” error, then we have a definite answer and can stop looking. The client-side/user behaviour changes depending on the failure mode.

> In fact you could store a standalone revocation certificate on the
> server and allow accessing it by the included issuer fingerprint. A
> dedicated keyserver command to do just this might be useful too.

Yes, there are any number of alternative ways to work around it, but none of them are as straightforward and elegant as just... allowing uid-less TPKs. :-) Particularly in the case of synchronising keyservers, where the only canonical metadata is what can be stored in a self-sig, it makes sense to allow self-sigs and their primaries to be distributed regardless of whether they are “usable” in a client-side sense.

A

On Fri, 13 Jan 2023 12:15, Andrew Gallagher said:

> system) to keep trying the other methods. But if we get a “key
> revoked” error, then we have a definite answer and can stop
> looking. The client-side/user behaviour changes depending on the

You can't stop because you would trust the statement from the keyserver.
Which is not what keyservers are made for. Thus even after you get a
revoked status from a keyserver you need to fetch the public key and
verify the revocation certificate.

> a self-sig, it makes sense to allow self-sigs and their primaries to
> be distributed regardless of whether they are “usable” in a
> client-side sense.

You can do between the keyservers whatever you want. If you want to
validate the keyblock you need the user id and need to verify the
self-sig before you allow fetching that keyblock (maybe restricted to
the requested user id)


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On 13 Jan 2023, at 14:30, Werner Koch <wk@gnupg.org> wrote:
>
> On Fri, 13 Jan 2023 12:15, Andrew Gallagher said:
>
>> system) to keep trying the other methods. But if we get a “key
>> revoked” error, then we have a definite answer and can stop
>> looking. The client-side/user behaviour changes depending on the
>
> You can't stop because you would trust the statement from the keyserver.
> Which is not what keyservers are made for. Thus even after you get a
> revoked status from a keyserver you need to fetch the public key and
> verify the revocation certificate.

This is exactly my proposal. If the keyserver were able to return the key packet(s) and the relevant signature(s), then a client could verify the revocation sig immediately, and stop processing. A UserID is not necessary if the lookup was made for a fingerprint.

>> a self-sig, it makes sense to allow self-sigs and their primaries to
>> be distributed regardless of whether they are “usable” in a
>> client-side sense.
>
> You can do between the keyservers whatever you want. If you want to
> validate the keyblock you need the user id and need to verify the
> self-sig before you allow fetching that keyblock (maybe restricted to
> the requested user id)

One can validate a direct signature over a primary key without processing any UserIDs.

A