Re: [openpgp] primary key binding signature requirement

[Aron Wussler <[e-mail]>]

Hi Neal,

> 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).

> 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?

Cheers,
Aron

------- Original Message -------
On Sunday, December 4th, 2022 at 13:27, Neal H. Walfield <[e-mail]> wrote:


> On Sat, 03 Dec 2022 17:09:17 +0100,
> Aron Wussler wrote:
> 

> > The very reason why I tried to make a certification-capable subkey is for ProtonCA - our take at OpenPGP-ca.
> > I think an offline primary key would be much better than what we're doing now, creating sorta a certificate chain, and making subkey rotation easy.
> > We can also pre-distribute and pre-generate all the subkeys for some years to come.
> > 

> > After trying out different software and realising none understood my certification, I gave up and we decided to use the primary key.
> > With the current setup this we're stuck at using the primary key, and when we'll have done some 2^30 signatures rotate it.
> 

> 

> Did you consider using an offline primary that tsigns the intermediate
> keys? Users would need to use a depth of >1 instead of 1 when
> 

> tsigning the proton CA as a (partially) trusted root, but that's not a
> much bigger ask, I think. That is, you'd have something like this:
> 

> Alice
> | tsigns (domain=protonmail.com)
> v
> proton offline CA
> | tsigns
> v
> proton intermediate CA 2022
> | certifies
> v
> proton user
> 

> > > The protocol is complex enough as it is today. I believe there are no use-cases that require subkeys of subkeys which cannot be solved in other ways.
> > > I also sadly agree with this sentence, the OpenPGP RFC is already complex enough, and I am not trying to argue that there is no way around (as we found one) but it would be nice to know whether it's officially possible or not.
> > 

> > Slightly edge-case uses are possible and this could be useful, but nothing really mainstream IMO.
> > 

> > > But, I believe that discussion is out of scope for the crypto refresh.
> > > Hmm, not sure about this, probably this is the best place to define it univocally. Or should this be in another informational RFC?
> 

> 

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

> Neal