-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(with no hats)
On 16/03/15 04:05, Daniel Kahn Gillmor wrote:
I'm happy to see a high bar personally, but this is likely to
invalidate many 2048-bit keys
My experience is that it's far far easier to deprecate
things that only have an effect in-line compared to wanting
to invalidate long term things like key values, esp.
public key values that are distributed around the Internet.
So even if one would like to do the latter then I think
it'd be a really good plan to separate that part of the
argument as it's likely to be much trickier. We had a
similar set of issues as we transitioned from DomainKeys
to DKIM - in that case the proponents of DomainKeys
were (correctly) extremely reluctant to break the few
deployments that were then-current. And I think we got
that right in that the WG changed the wire-formats and
signature algorithm requirements but in such a way that
already-deployed public keys continued to work.
I'd also note that we ought be cognizant that the fall
back here is e2e plaintext. If one considers RFC7435
then I think there's an argument to be considered for
allowing crypto that is perhaps approaching it's
sell-by date but that is clearly not yet past it's
use-by date. (And of course one can have fine arguments
about both dates;-) And if we wanted to invalidate
current keys, then I think that also puts an onus on
us to consider how to figure out the migration path
from working->broken->working-again.
Lastly, I'd note that e2e email security is a thing
where we (IETF and the broader tech community) have
failed pretty consistently because we made it too hard.
By failed, I mean e2e security is not something that is
commonly used by billions of folks. Part of that is UI,
but some of it is IMO also because we chose to try to
gold-plate security which made usability even worse. I
think the classic example with smime was requiring a
certificate before anything works - while such decisions
may have made sense for the 1990's enterprise, they
do not make sense in today's environment. So I think we
should be very wary of failing again through attempting
to gold-plate by mandating less commonly supported (by
dev. environments) algorithms or keys.
If there's a real need to invalidate old keys then let's
see that technically justified and if we must, then try
do that in a way that brings along the few million current
users rather than in a way that locks those out.
But I'm not yet convinced that there really is such a
need.
S.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVBrSTAAoJEC88hzaAX42i7+AH/ilxL3Yc9qnNRMEejGaAva+l
JXBuR9yig1xipFeN3nB+5tI6MOjGkgsfv0HC6OmdaACfF3PZIlLQT9B2B0DUCALD
EkmVUWCNGpiwduv3qMVnNb11Ryf/vr8KJMkAzAOqGwGHd1LjBOuMpIoOtDgcLnqq
iWOXBwkCl+RIuGp3afXQKtcb6K329WnwewaC6rEA1rueVx25bbfQLAVpN8o92eGH
sbroL7Ih4Wp3EM6oqoJTRvAUiKNEQ1mN/YaH0vRsmccbu1ekN+qvR13PW2GpOFj/
8H4tWF52MxXxF7pOIP9nfZicBgPcrUwQ3MD4fxu7Rih3UbR8SDJM4p+xC5rge6s=
=IDUt
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp