On Thu, Jul 30, 2015 at 11:15 AM, Wyllys Ingersoll
<wyllys(_at_)gmail(_dot_)com> wrote:
OK, 'at least the 512 bit fingerprint'...
Which you do probably depends on if you are using ECC or RSA. With RSA,
those 2048 bit keys start to bulk up...
For my particular implementation, I want to be able to rotate encryption
keys on a monthly basis or any time a device is added or removed from a
user's profile. so I am using fingerprints of key signing keys rather than
end-entity keys.
As a general rule, it seems that you can solve pretty much any usability
problem at the cost of an additional key. Back in 1995, this would have
ground the whole net to a halt. Today it isn't a problem. Right now on my
testbed Alice has a personal profile of 3 keys, plus a device profile of 3
keys per device, plus individual keys for each use in application (1+1 per
device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption,
1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a
tablet, a phone and a watch, that is 3 + 18 + 7 + 6 = 30 keypairs and an
additional one per month.
It might sound a bit extreme, but since I started in the business,
machines have gotten roughly a million times faster and have a million
times the memory. 30 keypairs instead of one does not seem like a big deal.
Really? It sure does to me. PGP suffers from numerous usability issues,
some of which are a result of implementation artifacts and some are
unavoidable due to the nature of security and the spec itself. Making
things more complicated or breaking compatibility with widely used existing
implementations in order to satisfy an odd niche use case does not seem to
me like its advancing the cause in a helpful way.
People today balk at managing a single PGP keypair across multiple devices
and applications, how in the world would they be expected to deal with 30+
(and growing) keys? Perhaps this is all handled automatically by whatever
scheme you are developing and the user would never know or care that there
are 30+ keys in their domain, but as described it seems way complicated.
If you have complicated use cases, trying to make the spec too simple is a
mistake. It is probably also a mistake to dismiss someone's work as 'niche'
before you bother to read it. My approach to dealing with the usability
blunders in S/MIME and OpenPGP is to design the system in such a way that
the user does not need to be aware that they are using encryption except in
the very rare situation where they want to make sure that the message is
sent encrypted or not at all.
The use case I am dealing with is precisely the problem of managing keys
across multiple devices. And it is all entirely automatic.
As far as the user is concerned, they only really have one key like thing
that they need to worry about.
Right now, there aren't many implications for OpenPGP bis. The main
difference is working with a key signing key rather than the key itself.
But that is pretty much inevitable if you want to deal with real world
problems like Alice wanting to make sure that she can encrypt her hard
drive and there is absolutely no way that it is at all possible.
But those are discussions to have on therightkey(_at_)ietf(_dot_)org.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp