Re: [openpgp] Clarify status of subkeys with certification use

[Leo Gaspard <[e-mail]>]

On 05/25/2018 09:46 PM, Daniel Kahn Gillmor wrote:
> On Fri 2018-05-25 12:26:54 +0200, Leo Gaspard wrote:
>>
>> Another use case supporting this opinion: certification subkeys are also
>> a way to increase the security of an offline OpenPGP key, as with them
>> it becomes possible to put the master key behind a diode while still
>> being able to certify keys, and only ever move data out:
> 
> you might have made the master key "more secure", but you've done so by
> transfering the capabilities of the master key (certification) out to
> the less-controlled keys.  what's the win here?  secret keys are not in
> themselves important objects -- what's important is the capabilities
> that the network assigns to the corresponding public keys.

Well, I'd argue the master secret key *is* an important object: it has
accumulated UID signatures that may become impossible to recover were it
to have to be revoked.

Hence this idea, allowing to revoke a certification subkey, that in
itself has no value indeed.

> Also, when some certification in a chain has an expiration date on it,
> is the whole chain of certifications bound by the narrowest
> ("bottleneck") expiration date, or is there some other governing
> principle?

I'd say the narrowest expiration date would make most sense (actually, I
can't think of any other reasonable way to handle expiration dates).

> And when a leaf certifiation expires earlier than marked because some
> middle element in the chain becomes unusable (remember, subkey
> expiration dates can change; subkeys can be revoked), how would you
> present this change to the user?

Well, isn't that the same issue as when a previously-trusted master key
that had signed the end-of-chain key expires / is revoked?

> And further still: how many levels deep should such a certification
> chain go?
> 
> I think it's pretty easy to argue "0 levels" (i.e. "no
> certification-capable subkeys") for simplicity of implementation and
> usability concerns.
> 
> I'd suggest that no implementation is willing to argue for "∞ levels"
> because at some point the chain of verification becomes too expensive to
> cope.
> 
> Are you arguing for some particular limited level of depth?  if so, how
> do you justify that level?

For my use case (ie. protecting the master key), a single level is
necessary, and there is a need only for a single certification subkey

For Neal's use case, I haven't thought extensively about it, but think
one could be enough, depending on whether we want the user to have to
access his master key when adding a device (and I guess we want, as
otherwise revocation of a device-that-had-signed-another-device becomes
a UI nightmare)

So, I'd say, one ?