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 ?
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp