XPost: alt.fan.usenet   
   From: invalid@invalid.invalid   
      
   Johanne Fairchild writes:   
   > Richard Kettlewell writes:   
   >>> Just a thought experiment:   
   >>> if you could/had to make something like a NNTP 2.0 (with no need for   
   >>> backwards compatibility) and server and client software for it today, what   
   >>> would it be like?   
   >>> In terms of specifications, technologies used, user interface, etc.   
   >   
   > [...]   
   >   
   >> * All messages signed by author and originating server (supporting   
   >> reputation management)   
   >   
   > Can you elaborate on this? You'd like to bind each message to the   
   > author-public-key and his NNTP server? So that everyone who he is and   
   > which server he used? (Can you give an example of how you'd do that?)   
      
   User signatures:   
      
   The client software automatically generates a key pair; signs every   
   message under it; and distributes the public key with each message.   
      
   The high-level effect is to create the option for users to maintain a   
   persistent identity (denoted by their public key) between their   
   postings.   
      
   It’s useful several things:   
   - forgery prevention   
   - reputation management (up-scoring, filtering, etc)   
   - access control (groups with restricted posting rules of some sort)   
   - canceling/superseding their their own posts (comparable to   
    existing cancel lock functionality)   
   - authentication of destination public keys for encrypted messages   
    across netnews, allowing encrypted groups (necessarily with limited   
    membership) or secure user-to-user messaging   
      
   A hypothetical netnews replacement might not include all these things,   
   but it does mean they are options.   
      
   It doesn’t _force_ a persistent identity; there’s nothing stopping a   
   user from generating a fresh key for every posting, for example in an   
   attempt to frustrate filtering. But no matter: you can filter out   
   previously unattested identities, if you’re trying to defend yourself   
   against a troll problem.   
      
   In a wider context, it also creates the option of cryptographically   
   relating users to other cryptographically managed identities, for   
   example PKIX, OpenPGP, or national identity schemes.   
      
   Originating server signatures:   
      
   The situation is similar but here there is a key pair per server, which   
   signs all messages originated on that server. Again public keys are   
   distributed with messages.   
      
   The first effect is to identify who has administrative responsibility   
   for posts through the server. If a user starts to use a particular   
   server for abuse of some kind, such as spam, then it gives the server   
   operator the option of issuing cancels (or perhaps more complex kinds of   
   policy statement, be creative l-) for the abusive messages.   
      
   A second use case would be to authenticate institutional affilation,   
   e.g. if the server is owned by a university, business, etc. (This might   
   involve signing the user keys rather than signing the posts - I’ve not   
   thought this through.)   
      
   Logistics:   
      
   Key pairs above may actually be hierarchies of key pairs, e.g. with   
   well-protected root keys delegating to limited-scope operational keys.   
      
   Originating server keys could be rolled over relatively frequently   
   without losing much value.   
      
   Under current trends we’d expect to use (at least) a post-quantum   
   signature scheme, which means large signatures. Even with ML-DSA-44 two   
   signatures and two public keys adds about 6Kbyte to every message. That   
   could be reduced a bit by separating key distribution from message   
   distribution, but on modern networks the overhead isn’t actually that   
   much, so it might be better to just accept the cost.   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|