Re: [openpgp] primary key binding signature requirement

[Aron Wussler <[e-mail]>]

Hi Neal,

As far as I understand WKD returns only one unrevoked certificate by design.

   The HTTP GET method MUST return the binary representation of the
   OpenPGP key for the given mail address.  The key needs to carry a
   User ID packet ([RFC4880]) with that mail address.  Note that the key
   may be revoked or expired - it is up to the client to handle such
   conditions.  To ease distribution of revoked keys, a server may
   return revoked keys in addition to a new key.  The keys are returned
   by a single request as concatenated key blocks.

This is another change that I would like to pursue with the superseded signature (other thread), to change WKD to return at most one non-revoked or non-supersed certificate.

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



------- Original Message -------
On Monday, December 5th, 2022 at 08:48, Neal H. Walfield <[e-mail]> wrote:


> On Sun, 04 Dec 2022 23:13:35 +0100,
> Aron Wussler wrote:
> 

> > > Did you consider using an offline primary that tsigns the intermediate
> > > keys?
> > 

> > Doesn't this require users to download both keys? It would probably save us some effort with trusting the offline key, but they must be individually fetched, and AFAIK this would be a change with how OpenPGP-CA works. Not against this model, but in general I agree with Heiko that there is insufficient support from the verifying side here, to allow for a seamless UX like TLS (or even close to that).
> 

> 

> How do you currently get the top-level CA certificate? WKD? If so,
> you can store all of the certificates there. And since they all use
> the same email address, getting the top-level certificate gets all of
> the intermediate certificates.
> 

> > > I suspect that having this discussion now will further delay the
> > > crypto refresh (in addition to thinking that it is out of scope).
> > 

> > True. So in your opinion we should not specify here whether certification subkeys are acceptable behaviour?
> > Or shall we standardize the "status quo": certification subkeys are not allowed?
> 

> 

> I'm for leaving it as it is, for now.
> 

> Neal