Bhavishya Desai wrote:
Now I would like to know(specifically) what are some other threats,which
could effect this and any difficulties with implementation.
I imagine that the encryption and/or hash algorithms will change over time
as encryption is broken and people figure out ways to create hash
collisions. Therefore I'd imagine keys will change over time.
I'm guessing this carries some consequences:
- the list key will change over time, therefore:
- old subscribers need to be alerted to the new list key.
- MUAs need to be able to make use of the current list key (perhaps the
list accepts posts under the old key for a limited time to give subscribers
a chance to switch to using the new key).
- subscribers' keys will change over time, therefore:
- there needs to be an easy way for a subscriber to get the list to
accept posts under the subscriber's new key.
- list archives raise interesting questions:
- if the goal is to never let a list post travel unencrypted, I guess
the list archives will be encrypted too?
- each archive post will be signed+encrypted with the current list
key. Therefore each archive message will be decrypted and re-encrypted at
each list key change?
- yes: this implies a bigger and bigger decryption/re-encryption
job at each list key change as a list archive grows. Presumably this task
will become computationally intensive at some point, possibly beyond the
scale of being done at all for very large mailing lists carrying large list
posts.
- no: each archive post will be untouched after sending. Therefore
archives will feature a set of list posts signed+encrypted with whatever
list key was current at the time that post was sent out.
- thus old list public keys must be kept around and published
forever so archive readers can decrypt/verify signatures of archived posts?
- yes: this carries some questions about GPG policy (below).
- no: how will this work?
- GPG policy issues: the above raises questions about GPG:
- will GPG keep old encryption algorithms and hash algorithms around
(perhaps warning not to use them for new keys, and only using them for
decryption as needed)?
- or users going to need to retain old versions of GPG to handle
verifying archive list posts old encrypted & signed with list keys (I don't
see this working out well)?
It's possible there is something fundamental about this entire process I do
not understand and therefore I've completely missed something about this
process which led me down a path I should not have gone down. If that's the
case, please do let me know where I went wrong.
Thanks.
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
