From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/40333 Path: main.gmane.org!not-for-mail From: (Chris Beggy ) news@kippona.com Newsgroups: gmane.emacs.gnus.general Subject: Re: PGP support Date: Fri, 16 Nov 2001 15:18:26 -0500 Organization: Kippona Sender: owner-ding@hpc.uh.edu Message-ID: <87y9l6zcz1.fsf@lackawana.kippona.com> References: <87eln2zeos.fsf@mclinux.com> <87r8r24d0z.fsf@squeaker.lickey.com> <87adxq4aqr.fsf@squeaker.lickey.com> <873d3e1sj7.fsf@lackawana.kippona.com> <87u1vupne3.fsf@alberti.gnupg.de> Reply-To: Chris Beggy NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035175901 358 80.91.224.250 (21 Oct 2002 04:51:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:51:41 +0000 (UTC) Return-Path: Original-Received: (qmail 28608 invoked from network); 16 Nov 2001 20:21:11 -0000 Original-Received: from malifon.math.uh.edu (129.7.128.13) by mastaler.com with SMTP; 16 Nov 2001 20:21:11 -0000 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 164pS1-0002WP-00; Fri, 16 Nov 2001 14:19:01 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 16 Nov 2001 14:18:44 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id OAA09121 for ; Fri, 16 Nov 2001 14:18:28 -0600 (CST) Original-Received: (qmail 28552 invoked by alias); 16 Nov 2001 20:18:30 -0000 Original-Received: (qmail 28546 invoked from network); 16 Nov 2001 20:18:30 -0000 Original-Received: from lackawana.kippona.com (root@207.8.195.148) by gnus.org with SMTP; 16 Nov 2001 20:18:30 -0000 Original-Received: from lackawana.kippona.com (nobody@localhost [127.0.0.1]) by lackawana.kippona.com (8.12.1/8.12.1/Kippona) with ESMTP id fAGKISQM009477 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 16 Nov 2001 15:18:29 -0500 Original-Received: (from nobody@localhost) by lackawana.kippona.com (8.12.1/8.12.1/Submit/Kippona) id fAGKISNc009476; Fri, 16 Nov 2001 15:18:28 -0500 X-Reply-To: Chris Beggy Original-Lines: 45 Original-X-Trace: lackawana.kippona.com 1005941906 9162 207.8.195.148 (16 Nov 2001 20:18:26 GMT) Original-X-Complaints-To: abuse@kippona.com X-gpgkeyid: 0x8060510A X-fingerprint: 6012 F8F8 29B3 67E4 0604 BCD2 F882 88AE 8060 510A Cancel-Lock: sha1:1e1EK8h/fvoZAfnq2USJwX9XdX4= Original-To: ding@gnus.org Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:40333 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:40333 Simon Josefsson writes: > Werner Koch writes: > >> On Fri, 16 Nov 2001 13:26:20 -0500, Chris Beggy said: >> >>> How about a header field: >> >>> X-Gnus: pgp-verified signature with key 0x454545 valid untrusted >> >> BTW, I might have missed it but an important feature would be to add a >> line like: >> >> X-Gnus-Orig-Encrypted-To: 0x12345678, 0x34567890 >> >> So that one can see that the message was originally encrypted and even >> more important to automagically suggest to encrypt any reply. > I don't understand the value of having a header line that says the > message was originally encrypted, the client already knows this? And > users should probably not trust such headers without the client saying > it is OK, and if the client can do that, the client could use some > other (better) way of conveying this information anyway. I thought you'd like this idea :-) I know you don't like the results placed in the message body, where they can be spoofed, as you showed. Previous posts in this thread have been discussing the shortcomings of: 1. poor visual cue from [hp e] in the modeline to convey signature/encryption status (signed,encrypted,valid,trusted?) 2. poor security of placing encryption status in the message body (you demonstrated this...) 3. introducing Orig-Encrypted-To info, presumably to confirm Cc and To fields, and to promote key exchange and web-of-trust scoring systems Using header fields addresses these points because it is a good place for visual cues when reading mail/news, it can be turned off if the reader doesn't want to be bothered, and it is a good place for ephemeral, timestamped information. Chris