On Fri, 25 May 2018 21:46:42 +0200,
Daniel Kahn Gillmor wrote:
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.
The difference between a primary key and a certification subkey is
that the primary key is the user's globally unique, long-term
identity. If the certification subkey is somehow compromised, it can
be revoked without requiring the user to get a new cryptographic
identity, which is a pain to distribute.
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'm not sure what you mean here. It seems obvious to me that if any
edge in a trust path is broken, then the path becomes invalid just
like in the WoT.
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?
Why do you think it is necessary to present this information to the
use? Right now, signatures and keys can be revoked and this breaks
trust paths in the WoT in a similar way, but there is no UI to show
what happened.
But, if you wanted to, sure, you could create some UI to prompt the
user to either extend the expiration of the middle certification
subkey or to hoist up the leaf certification subkey, but signing it
with a still-valid certification key.
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.
Unless it is possible to create a quine, the chain can't be infinite.
(But, it is worth pointing out that we do need to detect cycles.)
Because I think auditable delegation of authority is useful, I'd argue
for something like 32 levels as a recommended limit. 32 levels is
probably more than enough for most uses without requiring too much
acrobatics from the implementations.
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp