Re: Notation packet for PGP/MIME ability

[Jon Callas <[e-mail]>]

On 27 Jan 2005, at 12:50 PM, Florian Weimer wrote:
>> The name field of the notation packet will be
>> "[e-mail]".
>
> Do we need a trademark license from PGP if we want to implement this
> proposal?

I certainly hope not. If you did, then the RFC 2440 mechanism of using 
a domain name as a namespace designator is fundamentally flawed and has 
to be redone. It would also mean that the Java namespace thing 
(essentially com.pgp.preferred-email-encoding) is also fraught with 
peril.

We're not going to require a trademark license for it. It would be 
improper for us to.

	Jon




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S2wIsM082975; Thu, 27 Jan 2005 18:58:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0S2wIbV082974; Thu, 27 Jan 2005 18:58:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S2wIBM082939 for <[e-mail]>; Thu, 27 Jan 2005 18:58:18 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 27 Jan 2005 18:58:09 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Thu, 27 Jan 2005 18:58:09 -0800
X-PGP-Universal: processed
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail] ("Hal Finney")
From: Jon Callas <[e-mail]>
Subject: Re: Notation packet for PGP/MIME ability
Date: Thu, 27 Jan 2005 18:58:27 -0800
To: Florian Weimer <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 27 Jan 2005, at 12:50 PM, Florian Weimer wrote:
>> The name field of the notation packet will be
>> "[e-mail]".
>
> Do we need a trademark license from PGP if we want to implement this
> proposal?

I certainly hope not. If you did, then the RFC 2440 mechanism of using 
a domain name as a namespace designator is fundamentally flawed and has 
to be redone. It would also mean that the Java namespace thing 
(essentially com.pgp.preferred-email-encoding) is also fraught with 
peril.

We're not going to require a trademark license for it. It would be 
improper for us to.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RKp8dv052925; Thu, 27 Jan 2005 12:51:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0RKp8FL052924; Thu, 27 Jan 2005 12:51:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RKp5wA052906 for <[e-mail]>; Thu, 27 Jan 2005 12:51:06 -0800 (PST) (envelope-from [e-mail])
Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CuGbQ-0002eU-0q; Thu, 27 Jan 2005 21:50:56 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CuGbN-0005th-Ub; Thu, 27 Jan 2005 21:50:53 +0100
From: Florian Weimer <[e-mail]>
To: [e-mail] ("Hal Finney")
Cc: [e-mail]
Subject: Re: Notation packet for PGP/MIME ability
References: <[e-mail]>
Date: Thu, 27 Jan 2005 21:50:53 +0100
In-Reply-To: <[e-mail]> (Hal Finney's message of "Thu, 13 Jan 2005 00:01:19 -0800 (PST)")
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

* Hal Finney:

> The name field of the notation packet will be
> "[e-mail]".

Do we need a trademark license from PGP if we want to implement this
proposal?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P7sd4Z070277; Mon, 24 Jan 2005 23:54:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0P7sdPi070276; Mon, 24 Jan 2005 23:54:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0P7scPX070189 for <[e-mail]>; Mon, 24 Jan 2005 23:54:39 -0800 (PST) (envelope-from [e-mail])
Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CtLWq-0007UE-Ng for [e-mail]; Tue, 25 Jan 2005 08:54:24 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CtLWq-00019U-G4 for [e-mail]; Tue, 25 Jan 2005 08:54:24 +0100
From: Florian Weimer <[e-mail]>
To: [e-mail]
Subject: [Slightly OT] revoked user IDs
Date: Tue, 25 Jan 2005 08:54:24 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Sorry, this is somewhat off-topic, but I don't know any other channel
which I can use to reach the relevant folks.

If you implement a robot that spams email addresses found in OpenPGP
user IDs, please make sure that you skip revoked user IDs.  If one of
my user IDs is revoked, the message is pretty clear: I opt out of the
web of trust.  Please respect this request.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OCjwx9087556; Mon, 24 Jan 2005 04:45:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0OCjwfH087555; Mon, 24 Jan 2005 04:45:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OCjvag087521 for <[e-mail]>; Mon, 24 Jan 2005 04:45:57 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.ru ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1Ct3b7-0004DS-Uc; Mon, 24 Jan 2005 15:45:18 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: "Ian G" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Mon, 24 Jan 2005 18:44:39 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> ( Hal, what did you think of the triple GOST idea?
> Are three ghosts scarier than one?  ;)

Please bear in mind that some of my precautions regarding GOST cipher strength
was a little overdo. To this day all attacks against the cipher remains fully
theoretical, and no practical weakness has been demonstrated. That will not
last for eternity, however. I think, we need a more detailed evaluation of its
current state before implementing it in three-encryption mode. I cannot
recommend any domestic literature on the topic -- most of it is heavily
biased.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OBM0M4036503; Mon, 24 Jan 2005 03:22:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0OBM06b036502; Mon, 24 Jan 2005 03:22:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OBLxCY036044 for <[e-mail]>; Mon, 24 Jan 2005 03:21:59 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0OBLG221409; Mon, 24 Jan 2005 11:21:26 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Mon, 24 Jan 2005 11:26:30 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vlad \"SATtva\" Miller" <[e-mail]>, [e-mail]
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Vlad "SATtva" Miller wrote:

>From: Ian G
>
>  
>
>>Vlad "SATtva" Miller wrote:
>>
>>    
>>
>>>This won't help much unless you also consider specifying GOST R 34.11-94
>>>(based on GOST 28147-89 block cipher) for hash function and GOST R
>>>      
>>>
>>34.19-2001
>>    
>>
>>>(based on elliptic curves) for digital signature. These are the
>>>      
>>>
>>only permitted
>>    
>>
>>>algorithms for banking/government use in Russia.
>>>
>>>      
>>>
>>Do they specify a public key encryption
>>algorithm?
>>    
>>
>
>Ok, here are results of my research on that matter. There in no
>government-proposed public key encryption in Russia as there was no sex in the
>USSR. :) For symmetric encryption and MACs GOSTs 28147-89 and R 34.11-94 are
>being used, but as to the session key generation from public key certificates
>(probably in DH key exchange), there is no such unclassified common specs, and
>it's supposed that each implementation needs to be scrutinized in the
>certification body (FSB currently, Russian Federal Security Service) on the
>individual basis to be approved.
>  
>

So it would appear that for this to be a viable
project, the ecnryption, the hash, and the digsig
in GOST form would all need to be implemented,
and a secret key exchange method chosen.

Is there a team willing to specify those in OpenPGP
form, and are there two implementations willing
to code them up and do some interop testing?

If that were the case, I suppose we could think
in terms of pencilling in the numbers, but I don't
see that there is much point in allocating them
in the draft, given our emphasis on cleaning out
cruft rather than adding it in.

I still think it's a worthwhile project to encourage
though.  Perhaps the users could consider using
OpenPGP in non-standard modes while waiting
for the implementations...

( Hal, what did you think of the triple GOST idea?
Are three ghosts scarier than one?  ;)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OBAgXa021035; Mon, 24 Jan 2005 03:10:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0OBAfNJ021011; Mon, 24 Jan 2005 03:10:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net ([69.28.242.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OBAHeK020372 for <[e-mail]>; Mon, 24 Jan 2005 03:10:36 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.net ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1Ct25N-0007ZI-AO; Mon, 24 Jan 2005 14:08:27 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: "Ian G" <[e-mail]>, "David Crick" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Mon, 24 Jan 2005 17:08:06 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: Ian G

> Vlad "SATtva" Miller wrote:
>
> >This won't help much unless you also consider specifying GOST R 34.11-94
> >(based on GOST 28147-89 block cipher) for hash function and GOST R
> 34.19-2001
> >(based on elliptic curves) for digital signature. These are the
> only permitted
> >algorithms for banking/government use in Russia.
> >
>
> Do they specify a public key encryption
> algorithm?

Ok, here are results of my research on that matter. There in no
government-proposed public key encryption in Russia as there was no sex in the
USSR. :) For symmetric encryption and MACs GOSTs 28147-89 and R 34.11-94 are
being used, but as to the session key generation from public key certificates
(probably in DH key exchange), there is no such unclassified common specs, and
it's supposed that each implementation needs to be scrutinized in the
certification body (FSB currently, Russian Federal Security Service) on the
individual basis to be approved.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0NCINRE013716; Sun, 23 Jan 2005 04:18:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0NCINh4013715; Sun, 23 Jan 2005 04:18:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0NCIM6s013581 for <[e-mail]>; Sun, 23 Jan 2005 04:18:23 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AD62533C45; Sun, 23 Jan 2005 12:18:19 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sun, 23 Jan 2005 12:18:20 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <[e-mail]>
Cc: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw wrote:
> On Sat, Jan 22, 2005 at 12:57:46PM +0000, Ben Laurie wrote:
> 
>>Jon Callas wrote:
> 
> 
>>>I'm happy to have documents say or not say whatever they need to
>>>say or not say. Whatever else we do, let's leave 1991 out of
>>>discussions. Like Mr. Cleese's parrot, it has joined the choir
>>>eternal, and only stands up if someone nails it to its perch.
>>
>>If only - 1991 is the only place I could find that defines V2 keys,
>>which I still see in the wild.
> 
> 
> That's not so - both 2440 in section 5.5.2, and 2440bis in section 14
> define V2 keys as the same as V3 keys except for the version number.
> Since both documents define V3 keys, that effectively defines V2 keys
> as well.

So it does. I managed to miss that somehow. Thanks.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0N9oRNQ060544; Sun, 23 Jan 2005 01:50:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0N9oRCn060543; Sun, 23 Jan 2005 01:50:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0N9oHaq060435 for <[e-mail]>; Sun, 23 Jan 2005 01:50:21 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.net ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1CseNU-0000qO-C7; Sun, 23 Jan 2005 12:49:37 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: "David Crick" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: GOST information in Applied Crypography 2nd Ed.
Date: Sun, 23 Jan 2005 15:49:09 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> Section 20.3, pages 495 - 496
> GOST Digital Signature Algorithm (GOST R 34.10-94)

This standard is outdated, and has been replaced with GOST R 34.10-2001.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MEp0rG009253; Sat, 22 Jan 2005 06:51:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0MEp042009252; Sat, 22 Jan 2005 06:51:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MEp0Av009229 for <[e-mail]>; Sat, 22 Jan 2005 06:51:00 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20050122145047015009gq1ve>; Sat, 22 Jan 2005 14:50:47 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0MEokff027237 for <[e-mail]>; Sat, 22 Jan 2005 09:50:46 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0MEoJ7B023041 for <[e-mail]>; Sat, 22 Jan 2005 09:50:19 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0MEoJ8e023040 for [e-mail]; Sat, 22 Jan 2005 09:50:19 -0500
Date: Sat, 22 Jan 2005 09:50:19 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Jan 22, 2005 at 12:57:46PM +0000, Ben Laurie wrote:
> Jon Callas wrote:

> >I'm happy to have documents say or not say whatever they need to
> >say or not say. Whatever else we do, let's leave 1991 out of
> >discussions. Like Mr. Cleese's parrot, it has joined the choir
> >eternal, and only stands up if someone nails it to its perch.
> 
> If only - 1991 is the only place I could find that defines V2 keys,
> which I still see in the wild.

That's not so - both 2440 in section 5.5.2, and 2440bis in section 14
define V2 keys as the same as V3 keys except for the version number.
Since both documents define V3 keys, that effectively defines V2 keys
as well.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MEoxST009241; Sat, 22 Jan 2005 06:50:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0MEoxns009240; Sat, 22 Jan 2005 06:50:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MEoxU9009230 for <[e-mail]>; Sat, 22 Jan 2005 06:50:59 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc12) with ESMTP id <2005012214504901400hecupe>; Sat, 22 Jan 2005 14:50:49 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0MEomff027240 for <[e-mail]>; Sat, 22 Jan 2005 09:50:48 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0MEoLZE023046 for <[e-mail]>; Sat, 22 Jan 2005 09:50:21 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0MEoLWU023045 for [e-mail]; Sat, 22 Jan 2005 09:50:21 -0500
Date: Sat, 22 Jan 2005 09:50:21 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: [ISSUE] V2 PKESK advice is not correct
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

In section 14 of bis-12, one of the "Implementation Nits", after
mentioning that V2 and V3 keys are identical except for the version
number, adds:

  Similarly, these versions generated V2 PKESK packets (Tag 1). An
  implementation may accept or reject V2 PKESK packets as it sees fit,
  and MUST NOT generate them.

While the V2 and V3 Public Key Packets are indeed identical except for
the version number, this is not true for the V2 and V3 PKESK packets.
Somewhere in the PGP 2.3 timeframe, the encoding of the session key
was changed, but the PKESK version number was not changed.  Thus there
are pre-2.3 V2 PKESK packets that are not identical to post-2.3 V2
PKESK packets.

Rather than documenting all that in 2440bis and giving the different
encodings, and since V2 packets are well beyond deprecated at this
point, I suggest just dropping the whole sentence beginning
"Similarly, these versions generated V2...."

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCvloT046297; Sat, 22 Jan 2005 04:57:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0MCvlR4046293; Sat, 22 Jan 2005 04:57:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCvknJ046259 for <[e-mail]>; Sat, 22 Jan 2005 04:57:46 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id EE6A333C2E; Sat, 22 Jan 2005 12:57:45 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sat, 22 Jan 2005 12:57:46 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: "Brian G. Peterson" <[e-mail]>, [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> 
> On 16 Jan 2005, at 10:11 AM, Brian G. Peterson wrote:
> 
>> I do not believe that support for partitioned in the notation packet 
>> implies
>> RFC 1991 compatibility.  We have decided that 2440bis will obsolete 
>> RFC 1991,
>> if I recall the concensus of the group correctly.  We have also otherwise
>> addressed dash-escaping and trailing whitespace issues.  I think that a
>> 'partitioned' scheme is the only option currently available to 
>> implementors
>> who require independent verification of each part, as well as 
>> verification of
>> the whole.
>>
> 
> RFC 1991 was an informational RFC. It has no basis in anything. 2440 
> tacitly replaces it, since 2440 is standards track and 1991 isn't. 1991 
> is pre-OpenPGP history. Please don't drag it in. Thanks.
> 
> We had debates before about whether we should explicitly say we obsolete 
> 1991. In the old days, you never said that standards-track replaced 
> informational-track because informational is merely, well, 
> informational. That interpretation has changed and we're now explicitly 
> saying we replace something that was never a standard to begin with.
> 
> I'm happy to have documents say or not say whatever they need to say or 
> not say. Whatever else we do, let's leave 1991 out of discussions. Like 
> Mr. Cleese's parrot, it has joined the choir eternal, and only stands up 
> if someone nails it to its perch.

If only - 1991 is the only place I could find that defines V2 keys, 
which I still see in the wild.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCqDN3037971; Sat, 22 Jan 2005 04:52:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0MCqDet037970; Sat, 22 Jan 2005 04:52:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCqDMY037574 for <[e-mail]>; Sat, 22 Jan 2005 04:52:13 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1F99733C2E for <[e-mail]>; Sat, 22 Jan 2005 12:52:02 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sat, 22 Jan 2005 12:52:02 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: More comments
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

In section 9.1, Schneier is given as the reference for DSA - why not 
refer to FIPS 186-2, which is freely available? Or, indeed, HAC 11.5.1, 
available here: http://www.cacr.math.uwaterloo.ca/hac/about/chap11.pdf.

Similarly 9.2, TripleDES (which, presumably, is EDE 3DES - it'd be good 
to be specific) is in some FIPS document which I forget or in HAC 
chapter 7 (7.32 in 7.2.3 and 7.4.2).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCY9JI027406; Sat, 22 Jan 2005 04:34:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0MCY9hG027404; Sat, 22 Jan 2005 04:34:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0MCY8ax027363 for <[e-mail]>; Sat, 22 Jan 2005 04:34:08 -0800 (PST) (envelope-from [e-mail])
Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <[e-mail]> for <[e-mail]>; Sat, 22 Jan 2005 12:34:02 +0000
Received: from [192.168.1.100] (really [81.100.121.98]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050122123402.GKKT9818.aamta03-winn.mailhost.ntl.com@[192.168.1.100]> for <[e-mail]>; Sat, 22 Jan 2005 12:34:02 +0000
Message-ID: <[e-mail]>
Date: Sat, 22 Jan 2005 12:33:56 +0000
From: David Crick <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-gb, en, en-us
MIME-Version: 1.0
To: [e-mail]
Subject: GOST information in Applied Crypography 2nd Ed.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Section 14.1, pages 331 - 334
GOST Block Cipher (GOST 28147-89)

Mentions use of random S-Boxes, but also states:

"More recently, a set of S-Boxes used in an application
for the Central Bank of the Russian Federation surfaced.
These S-Boxes are also used in the GOST one-way hash
function."

S-Box 1:
  4 10  9  2 13  8  0 14  6 11  1 12  7 15  5  3

S-Box 2:
14 11  4 12  6 13 15 10  2  3  8  1  0  7  5  9

S-Box 3:
  5  8  1 13 10  3  4  2 14 15 12  7  6  0  9 11

S-Box 4:
  7 13 10  1  0  8  9 15 14  4  6 12 11  2  5  3

S-Box 5:
  6 12  7  1  5 15 13  8  4 10  9 14  0  3 11  2

S-Box 6:
  4 11 10  0  7  2  1 13  3  6  8  5  9 12 15 14

S-Box 7:
13 11  4  1  3 15  5  9  0 10 14  7  6  8  2 12

S-Box 8:
  1 15 13  0  5  7 10  4  9  2  3 14  6 11  8 12


Section 18.11, page 454
GOST Hash Function (GOST R 34.11-94)

NB errata: "XOR of all the message blocks" SHOULD BE
"sum of the message blocks as if they were 256-bit
integers"


Section 20.3, pages 495 - 496
GOST Digital Signature Algorithm (GOST R 34.10-94)

Schneier notes that q is 256 bits compared to DSA's 160.


Part V, pages 643 - 647
GOST C source code (uses ECB mode)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFB8kfWcuzN6jLXKHYRAkwmAJ9ZJ5QXfAejrwq9/vBeGRSMEJNE8ACdGW9I
QqCMfBiGAov9EdQRePE3190=
=cpcO
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LNAh7B086311; Fri, 21 Jan 2005 15:10:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LNAhhE086310; Fri, 21 Jan 2005 15:10:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LNAgtg086252 for <[e-mail]>; Fri, 21 Jan 2005 15:10:42 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.ru ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1Cs7vI-0000dQ-O7; Sat, 22 Jan 2005 02:10:18 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: "Ian G" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Sat, 22 Jan 2005 05:08:35 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> >This won't help much unless you also consider specifying GOST R 34.11-94
> >(based on GOST 28147-89 block cipher) for hash function and GOST R
> 34.19-2001
> >(based on elliptic curves) for digital signature. These are the
> only permitted
> >algorithms for banking/government use in Russia.
> >
>
> Do they specify a public key encryption
> algorithm?

I'm now trying to figure it out. Oddly, there is no GOST standard for PK. RSA
is used often enough in banking sector, but banks have less strict
regulations, and even using 3DES. That's not an issue for government
organisations though. I'll give an answer on PK in day or two.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LN0xd5078668; Fri, 21 Jan 2005 15:00:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LN0xAi078667; Fri, 21 Jan 2005 15:00:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LN0vrc078661 for <[e-mail]>; Fri, 21 Jan 2005 15:00:58 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LN0e226609; Fri, 21 Jan 2005 23:00:45 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 23:05:53 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vlad \"SATtva\" Miller" <[e-mail]>
CC: [e-mail]
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Vlad "SATtva" Miller wrote:

>This won't help much unless you also consider specifying GOST R 34.11-94
>(based on GOST 28147-89 block cipher) for hash function and GOST R 34.19-2001
>(based on elliptic curves) for digital signature. These are the only permitted
>algorithms for banking/government use in Russia.
>

Do they specify a public key encryption
algorithm?


iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LMsnj7074208; Fri, 21 Jan 2005 14:54:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LMsnVc074207; Fri, 21 Jan 2005 14:54:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LMsliE074201 for <[e-mail]>; Fri, 21 Jan 2005 14:54:48 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LMsO226577; Fri, 21 Jan 2005 22:54:35 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 22:59:37 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vlad \"SATtva\" Miller" <[e-mail]>
CC: [e-mail]
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Vlad "SATtva" Miller wrote:

>>How about doing a triple-GOST?  That would
>>meet the letter of the rules, and give a boost
>>to the security?  Just brainstorming here...
>>    
>>
>
>Well, this may be helpful if GOST is really subject to "sliding" attacks, and
>would put excercises in "meet in the middle", et cetera to pure theoretic
>field (because of memory requirements). But this is hardly a good decision
>anyway. Maybe GOST multiple encriptions -- on the assumpsion of architectual
>similarity to DES -- isn't forming a group, but look at the keylength.
>Standard variant has 256 bits + secret S-boxes give us something about 610
>bits of secret data. In 3GOST (or whatever) it would be more than 1800 bits --
>for symmetric cipher! Moreover, there are speed considerations...
>  
>


Let's see now.  1800 bits of secret key data.
That's less than a millisecond of random data
from my /dev/urandom.  So that's not an issue.

Secret key data, certainly in the OpenPGP
world is *primarily* used as a secret key
exchange encrypted by public key.  So, if
one looks at the public key algoriths, they
mostly have the characteristic that when
they are encrypting, they do so over a block
that is the same size as the key.  E.g., a
1024 bit key can encrypt a 1024 bit block.

(Or something - can someone post the real
cryptographer's viewpoint on this?)

So we may be limited to using 2048 bit public
keys and above when using GOST.  Oh well,
that's not a biggie!  Some would say that
should be mandated anyway.

Then there is the notion of straight secret
key encryption;  that's solved by a key expansion
algorithm.  The strength of the key then becomes
the determining issue, so doesn't matter how
long it is.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LMb8Qf068499; Fri, 21 Jan 2005 14:37:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LMb8KF068498; Fri, 21 Jan 2005 14:37:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LMb8bS068429 for <[e-mail]>; Fri, 21 Jan 2005 14:37:08 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Fri, 21 Jan 2005 14:36:59 -0800
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 21 Jan 2005 14:36:59 -0800
X-PGP-Universal: processed
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
Date: Fri, 21 Jan 2005 14:36:55 -0800
To: "Brian G. Peterson" <[e-mail]>
X-Mailer: Apple Mail (2.619)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 16 Jan 2005, at 10:11 AM, Brian G. Peterson wrote:

> I do not believe that support for partitioned in the notation packet 
> implies
> RFC 1991 compatibility.  We have decided that 2440bis will obsolete 
> RFC 1991,
> if I recall the concensus of the group correctly.  We have also 
> otherwise
> addressed dash-escaping and trailing whitespace issues.  I think that a
> 'partitioned' scheme is the only option currently available to 
> implementors
> who require independent verification of each part, as well as 
> verification of
> the whole.
>

RFC 1991 was an informational RFC. It has no basis in anything. 2440 
tacitly replaces it, since 2440 is standards track and 1991 isn't. 1991 
is pre-OpenPGP history. Please don't drag it in. Thanks.

We had debates before about whether we should explicitly say we 
obsolete 1991. In the old days, you never said that standards-track 
replaced informational-track because informational is merely, well, 
informational. That interpretation has changed and we're now explicitly 
saying we replace something that was never a standard to begin with.

I'm happy to have documents say or not say whatever they need to say or 
not say. Whatever else we do, let's leave 1991 out of discussions. Like 
Mr. Cleese's parrot, it has joined the choir eternal, and only stands 
up if someone nails it to its perch.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LMPrNB065466; Fri, 21 Jan 2005 14:25:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LMPrbU065465; Fri, 21 Jan 2005 14:25:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LMPiTJ065452 for <[e-mail]>; Fri, 21 Jan 2005 14:25:49 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.com ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1Cs7Di-0007AS-Oh; Sat, 22 Jan 2005 01:25:17 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: "Ian G" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Sat, 22 Jan 2005 04:23:52 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> >A few years ago it was theoretically estimated that an effective
> strength of
> >GOST cipher is approximately 2^56, that is about the same value as
> DES's. Not
> >quite what we need by today's standards. And not quite what has been always
> >officially supported by OpenPGP.
>
> How about doing a triple-GOST?  That would
> meet the letter of the rules, and give a boost
> to the security?  Just brainstorming here...

Well, this may be helpful if GOST is really subject to "sliding" attacks, and
would put excercises in "meet in the middle", et cetera to pure theoretic
field (because of memory requirements). But this is hardly a good decision
anyway. Maybe GOST multiple encriptions -- on the assumpsion of architectual
similarity to DES -- isn't forming a group, but look at the keylength.
Standard variant has 256 bits + secret S-boxes give us something about 610
bits of secret data. In 3GOST (or whatever) it would be more than 1800 bits --
for symmetric cipher! Moreover, there are speed considerations...






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LK777b049558; Fri, 21 Jan 2005 12:07:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LK77tG049557; Fri, 21 Jan 2005 12:07:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LK76FX049538 for <[e-mail]>; Fri, 21 Jan 2005 12:07:06 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <200501212007010130096gaje>; Fri, 21 Jan 2005 20:07:01 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0LK6xff023728 for <[e-mail]>; Fri, 21 Jan 2005 15:07:00 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0LK6YOY010916 for <[e-mail]>; Fri, 21 Jan 2005 15:06:34 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0LK6Ygi010915 for [e-mail]; Fri, 21 Jan 2005 15:06:34 -0500
Date: Fri, 21 Jan 2005 15:06:34 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Adding GOST as a cipher?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Jan 21, 2005 at 10:32:11AM -0800, "Hal Finney" wrote:

> For those who want to use it, would an acceptable alternative be a
> short informational RFC which specified an algorithm ID from the
> private/experimental range?

That feels a bit like cheating to me.  As soon as there is an RFC
(informational or otherwise), an algorithm should not be in the
experimental range.  Otherwise, we'd be effectively moving that
experimental algorithm number into the operational range.  We couldn't
use it for experimental purposes any longer.

(Not arguing for or against GOST.  Just for algorithm numbering
cleanliness.)

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LJeN4n044304; Fri, 21 Jan 2005 11:40:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LJeNqE044303; Fri, 21 Jan 2005 11:40:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LJeLHv044296 for <[e-mail]>; Fri, 21 Jan 2005 11:40:22 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LJdq225725; Fri, 21 Jan 2005 19:40:02 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 19:45:04 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vlad \"SATtva\" Miller" <[e-mail]>
CC: "Hal Finney" <[e-mail]>, [e-mail]
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Vlad "SATtva" Miller wrote:

[bad news snipped!]

>A few years ago it was theoretically estimated that an effective strength of
>GOST cipher is approximately 2^56, that is about the same value as DES's. Not
>quite what we need by today's standards. And not quite what has been always
>officially supported by OpenPGP.
>  
>

How about doing a triple-GOST?  That would
meet the letter of the rules, and give a boost
to the security?  Just brainstorming here...

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LJUmuU043011; Fri, 21 Jan 2005 11:30:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LJUmHg043010; Fri, 21 Jan 2005 11:30:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LJUkYT043002 for <[e-mail]>; Fri, 21 Jan 2005 11:30:47 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LJUK225690; Fri, 21 Jan 2005 19:30:30 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 19:35:33 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Hal Finney <[e-mail]>
CC: [e-mail]
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal Finney wrote:

>I'm not happy about adding a cipher with a 64 bit block size in this day
>and age.  Putting it into the spec seems to be an implicit endorsement to
>some degree.  We took out ElGamal signatures because of the difficulty of
>using them securely, and I think we should continue to demand that we only
>add algorithms to the spec if they provide acceptable levels of security.
>  
>

I think of it as a chess game.  Advancing a pawn
into line of attack of the queen is not a good
strategy, for the pawn, and perhaps we should
take away the pawn from the game's rules?

By putting GOST into OpenPGP we are offering
a product that conforms to "the rules."  That
means those rule-takers are more likely to use
OpenPGP than another product.

Not only is the other product likely to be more
insecure (any arguments there? ;) it won't also
come with AES, etc.  All OpenPGP products these
days come with a lot of other nice strong options;
these are the knights covering the pawn's move.

The rule-takers that we are talking about are
notoriously poor at following the spirit of the
rules....  For the most part, "we use OpenPGP
and OpenPGP has GOST" is probably sufficient
to get a pass.

>I don't know the details of GOST but it is often called the "Russian
>DES" and we certainly wouldn't want to add a DES-strength cipher now.
>GOST has a much larger key so it is not quite the same but overall it
>seems like an old cipher whose time has passed.
>
>For those who want to use it, would an acceptable alternative be
>a short informational RFC which specified an algorithm ID from the
>private/experimental range?
>  
>

If it is specified it shouldn't be in the private/
experimental range.  That range should be for
stuff that isn't specified, by definition.

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LJAr7x039032; Fri, 21 Jan 2005 11:10:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LJArkQ039031; Fri, 21 Jan 2005 11:10:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LJAqMO039022 for <[e-mail]>; Fri, 21 Jan 2005 11:10:52 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.ru ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1Cs4Aw-0007qg-5s; Fri, 21 Jan 2005 22:10:12 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: "\"Hal Finney\"" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Sat, 22 Jan 2005 01:09:52 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> I don't know the details of GOST but it is often called the "Russian
> DES" and we certainly wouldn't want to add a DES-strength cipher now.
> GOST has a much larger key so it is not quite the same but overall it
> seems like an old cipher whose time has passed.

You're absolutely right. Aside from the longer key, more rounds, and linear
and differential cryptanalysis resistence, it has many disadventages even
compared to DES. Some of these includes:

* key schedule virtually non-existent (subject to related key attacks)
* very simple round function with cyclic linear shift (smaller avalanche
effect)
* S-boxes' size is too short, and criteria for their choosing is not available
(something to think about in connection with "A Family of Trapdoor Ciphers" by
Vincent Rijmen and Bart Preenel)
* weak keys and short cycles exists

A few years ago it was theoretically estimated that an effective strength of
GOST cipher is approximately 2^56, that is about the same value as DES's. Not
quite what we need by today's standards. And not quite what has been always
officially supported by OpenPGP.


Respectfully yours,

 Vladislav "SATtva" Miller
 http://www.pgpru.com






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LIHCwI035591; Fri, 21 Jan 2005 10:17:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LIHCM0035590; Fri, 21 Jan 2005 10:17:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LIHBPg035583 for <[e-mail]>; Fri, 21 Jan 2005 10:17:11 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 5D29057E2C; Fri, 21 Jan 2005 10:32:11 -0800 (PST)
To: [e-mail]
Subject: Re: Adding GOST as a cipher?
Message-Id: <[e-mail]>
Date: Fri, 21 Jan 2005 10:32:11 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I'm not happy about adding a cipher with a 64 bit block size in this day
and age.  Putting it into the spec seems to be an implicit endorsement to
some degree.  We took out ElGamal signatures because of the difficulty of
using them securely, and I think we should continue to demand that we only
add algorithms to the spec if they provide acceptable levels of security.

I don't know the details of GOST but it is often called the "Russian
DES" and we certainly wouldn't want to add a DES-strength cipher now.
GOST has a much larger key so it is not quite the same but overall it
seems like an old cipher whose time has passed.

For those who want to use it, would an acceptable alternative be
a short informational RFC which specified an algorithm ID from the
private/experimental range?

Hal



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LI7Nci034793; Fri, 21 Jan 2005 10:07:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LI7N7i034792; Fri, 21 Jan 2005 10:07:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LI7N5V034778 for <[e-mail]>; Fri, 21 Jan 2005 10:07:23 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005012118071701500d7love>; Fri, 21 Jan 2005 18:07:17 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0LI7Gff023173 for <[e-mail]>; Fri, 21 Jan 2005 13:07:17 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0LI6qr2010684 for <[e-mail]>; Fri, 21 Jan 2005 13:06:52 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0LI6qpe010683 for [e-mail]; Fri, 21 Jan 2005 13:06:52 -0500
Date: Fri, 21 Jan 2005 13:06:52 -0500
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Adding GOST as a cipher?
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Jan 21, 2005 at 05:50:48PM +0000, Ian G wrote:

> >I'm taking a wait and see attitude with regards to GOST itself, but
> >I am against sticking in an ID without details.  Whether in 2440bis
> >or in another document, we should either do GOST or not do GOST.
> >The halfway thing doesn't really help anyone.
> >
> >A few months back we actually removed some 'IDs without details'
> >from the draft.
> > 
> 
> So the test might be that even though 2440bis does
> not describe the paramaters/details, it should have
> a reference to where they *are* definitively stated,
> to the extent that any implementation can create an
> OpenPGP compatible plugin with that algorithm.

Not even that.  There is no need to split details between two
documents.  If we're going to do GOST, put it all in 2440bis, or put
it all in another document.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LHjvS6018431; Fri, 21 Jan 2005 09:45:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LHjvbP018429; Fri, 21 Jan 2005 09:45:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LHjp97018409 for <[e-mail]>; Fri, 21 Jan 2005 09:45:56 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LHjZ225229 for <[e-mail]>; Fri, 21 Jan 2005 17:45:45 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 17:50:48 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw wrote:

>On Fri, Jan 21, 2005 at 03:00:01PM +0100, Adrian von Bidder wrote:
>  
>
>>Perhaps 'rush in' an ID (or a couple of IDs, as per Vlad Miller's mail) with 
>>reference to it being the sole legally useful algorithm for some 
>>applications in russia, with all details to be ironed out in another 
>>document?
>>    
>>
>
>I'm taking a wait and see attitude with regards to GOST itself, but I
>am against sticking in an ID without details.  Whether in 2440bis or
>in another document, we should either do GOST or not do GOST.  The
>halfway thing doesn't really help anyone.
>
>A few months back we actually removed some 'IDs without details' from
>the draft.
>  
>

So the test might be that even though 2440bis does
not describe the paramaters/details, it should have
a reference to where they *are* definitively stated,
to the extent that any implementation can create an
OpenPGP compatible plugin with that algorithm.

I must admit, if these details are not laid down
somewhere, I'm unsure what the point of adding
the Id into 2440bis is.  If there is a risk that this
could end up pointing to separate implementations,
then that would indicate that we had put the cart
before the horse?

iang


-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LGDrZV089384; Fri, 21 Jan 2005 08:13:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LGDrYK089383; Fri, 21 Jan 2005 08:13:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LGDquf089375 for <[e-mail]>; Fri, 21 Jan 2005 08:13:53 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <20050121161345011000lhaie>; Fri, 21 Jan 2005 16:13:46 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0LGDjff022781 for <[e-mail]>; Fri, 21 Jan 2005 11:13:45 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0LGDFjO010517 for <[e-mail]>; Fri, 21 Jan 2005 11:13:20 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0LGDFiX010516 for [e-mail]; Fri, 21 Jan 2005 11:13:15 -0500
Date: Fri, 21 Jan 2005 11:13:15 -0500
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Adding GOST as a cipher?
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Jan 21, 2005 at 03:00:01PM +0100, Adrian von Bidder wrote:
> On Friday 21 January 2005 01.53, Ian G wrote:
> 
> > The only objection I would have is if it help up the
> > draft.  If something else is holding up the draft, no
> > problems.
> >
> > It would however be a nuisance if it was "rushed in"
> > only to find out later that it is ... not quite right.
> 
> Perhaps 'rush in' an ID (or a couple of IDs, as per Vlad Miller's mail) with 
> reference to it being the sole legally useful algorithm for some 
> applications in russia, with all details to be ironed out in another 
> document?

I'm taking a wait and see attitude with regards to GOST itself, but I
am against sticking in an ID without details.  Whether in 2440bis or
in another document, we should either do GOST or not do GOST.  The
halfway thing doesn't really help anyone.

A few months back we actually removed some 'IDs without details' from
the draft.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LEbfVY061676; Fri, 21 Jan 2005 06:37:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LEbf7l061675; Fri, 21 Jan 2005 06:37:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from branwen.iks-jena.de ([e-mail] [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LEbeZ8061658 for <[e-mail]>; Fri, 21 Jan 2005 06:37:40 -0800 (PST) (envelope-from [e-mail])
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.1/8.13.1) with ESMTP id j0LEbb3B004894 for <[e-mail]>; Fri, 21 Jan 2005 15:37:39 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.1/8.13.1/Submit) id j0LEbbH3004893 for [e-mail]; Fri, 21 Jan 2005 15:37:37 +0100
To: [e-mail]
Path: not-for-mail
From: Lutz Donnerhacke <[e-mail]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Adding GOST as a cipher?
Date: Fri, 21 Jan 2005 14:37:37 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 9
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1106318257 2993 217.17.192.37 (21 Jan 2005 14:37:37 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Fri, 21 Jan 2005 14:37:37 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

* Vlad  SATtva  Miller wrote:
> Sorry, it was my mistake. S-boxes indeed aren't specified in the
> document, and are considered as an "additional" key (they must be kept in
> secret, and may be generated using RNG).

So the system has not changed. It's shown, that random S-boxes are less
secure than those of DES. Too bad.

Thanx for the material, I'll read through.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LE7h73034924; Fri, 21 Jan 2005 06:07:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LE7hNu034923; Fri, 21 Jan 2005 06:07:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LE7fQt034865 for <[e-mail]>; Fri, 21 Jan 2005 06:07:41 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.com ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1CrzRg-0001EO-L4 for [e-mail]; Fri, 21 Jan 2005 17:07:09 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Fri, 21 Jan 2005 20:06:31 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Vladislav "SATtva" Miller wrote:
> Ian G wrote:
> > It would however be a nuisance if it was "rushed in"
> > only to find out later that it is ... not quite right.  I
> > gather there are rather a lot of options behind the
> > simple 'GOST' word?  Is this the algorithm where
> > the S-Boxes aren't specified in the standard?
>
> Nope, the GOST S-boxes are specified directly in russian GOST (Government
> Standard) 28147-89.

Sorry, it was my mistake. S-boxes indeed aren't specified in the document, and
are considered as an "additional" key (they must be kept in secret, and may be
generated using RNG).






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LE0PFO029044; Fri, 21 Jan 2005 06:00:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LE0Pom029043; Fri, 21 Jan 2005 06:00:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from johnny.adanco.com (gate.adanco.com [212.25.16.151] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LE0OM9028966 for <[e-mail]>; Fri, 21 Jan 2005 06:00:24 -0800 (PST) (envelope-from [e-mail])
Received: from humphrey.adanco.local (humphrey.adanco.local [172.18.10.16]) by johnny.adanco.com (Postfix) with ESMTP id CE2E61BF6 for <[e-mail]>; Fri, 21 Jan 2005 15:00:06 +0100 (CET)
From: Adrian von Bidder <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Adding GOST as a cipher?
Date: Fri, 21 Jan 2005 15:00:01 +0100
User-Agent: KMail/1.7.2
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1306817.ulE1v069Vc"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--nextPart1306817.ulE1v069Vc
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 21 January 2005 01.53, Ian G wrote:

> The only objection I would have is if it help up the
> draft.  If something else is holding up the draft, no
> problems.
>
> It would however be a nuisance if it was "rushed in"
> only to find out later that it is ... not quite right.

Perhaps 'rush in' an ID (or a couple of IDs, as per Vlad Miller's mail) wit=
h=20
reference to it being the sole legally useful algorithm for some=20
applications in russia, with all details to be ironed out in another=20
document?

The big potential problem with this is conflicting non-compatible=20
implementations.

So perhaps using an id from the experimental range would still be best for=
=20
now; transition to a regular id shouldn't be a problem later on, apart from=
=20
the time it takes.

greetings
=2D- vbi

=2D-=20
Beware of the FUD - know your enemies. This week
    * Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion

--nextPart1306817.ulE1v069Vc
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEABECAGcFAkHxCuZgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6koMAn3p0YVeE7m7bRiHFNQa8Y59V
oVTqAJ4xBoPxswBrja5IoO/HefnL4I3zVA==
=inRj
-----END PGP SIGNATURE-----

--nextPart1306817.ulE1v069Vc--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCum9q065146; Fri, 21 Jan 2005 04:56:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LCumdO065145; Fri, 21 Jan 2005 04:56:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCukc8065035 for <[e-mail]>; Fri, 21 Jan 2005 04:56:47 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id B74C83475A; Sat, 22 Jan 2005 01:56:28 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16205-18; Sat, 22 Jan 2005 01:56:28 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 66D6B346E0; Sat, 22 Jan 2005 01:56:28 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3D8FC37749; Sat, 22 Jan 2005 01:56:28 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CryL7-0000gd-00; Sat, 22 Jan 2005 01:56:37 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Adding GOST as a cipher?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 22 Jan 2005 01:56:37 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ian G <[e-mail]> writes:

>That's the sort of information we need.  Is that sufficient to create the
>paramaters and specify them in the standard?

I don't really know how necessary this would be in practice.  S/MIME (which
Jon referred to in his original message) has a couple of algorithms in there
that were added due to various national requirements where the understanding
is that those who feel compelled to support the Wombat128 algorithm will know
the details of Wombat128 and don't need much in the RFC beyond an ID.  Because
of this the S/MIME approach is to have a distinct RFC for each NIH algorithm
that copies 10 pages of boilerplate from the previous NIH algorithm RFC and
then changes a few sentences to say "Use this ID".  I think this would be the
best approach for OpenPGP as well.  We're well into the political layer here,
not much to do with technology any more.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCdTLf043576; Fri, 21 Jan 2005 04:39:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LCdTSx043575; Fri, 21 Jan 2005 04:39:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCdRaE043500 for <[e-mail]>; Fri, 21 Jan 2005 04:39:28 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LCd2223813; Fri, 21 Jan 2005 12:39:13 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 12:44:15 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lutz Donnerhacke <[e-mail]>
CC: [e-mail]
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Lutz Donnerhacke wrote:

>* Ian G wrote:
>  
>
>>It would however be a nuisance if it was "rushed in" only to find out
>>later that it is ... not quite right.  I gather there are rather a lot of
>>options behind the simple 'GOST' word?  Is this the algorithm where the
>>S-Boxes aren't specified in the standard?
>>    
>>
>
>Exactly. GOST is assumed to be more vulnerable than DES.
>  
>

Hmmm... What is our take on adding an algorithm
less well respected than DES?  It was never considered
as being useful in the past.

Perhaps the fine line is walked by saying that the
paramaters get added but there is a warning that
there are security issues with the algorithms, and
they become a MAY implement, for markets that
have regulatory requirements?

Once upon a time, PGP was the tool of cryptorebels.
These days however, it is not their sole preserve.
Are clients and preferences up to allowing two
opposing communities to co-exist in peace?

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCZ2eh036357; Fri, 21 Jan 2005 04:35:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LCZ2FF036356; Fri, 21 Jan 2005 04:35:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCZ1IV036276 for <[e-mail]>; Fri, 21 Jan 2005 04:35:01 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0LCYU223793; Fri, 21 Jan 2005 12:34:35 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 12:39:43 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: "Vlad \"SATtva\" Miller" <[e-mail]>
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Vlad "SATtva" Miller wrote:

>Jon Callas wrote:
>  
>
>>Recently, I've been asked about adding GOST as a cipher into OpenPGP.
>>It's needed in Russia and parts of Eastern Europe, where they use it in
>>banking and government applications.
>>    
>>
>
>This won't help much unless you also consider specifying GOST R 34.11-94
>(based on GOST 28147-89 block cipher) for hash function and GOST R 34.19-2001
>(based on elliptic curves) for digital signature. These are the only permitted
>algorithms for banking/government use in Russia. Don't know about other
>Eastern Eaurope countries policies, though.
>  
>

That's the sort of information we need.  Is that
sufficient to create the paramaters and specify
them in the standard?

Another issue is implementations.  Is it appropriate
to get a couple of cooperating code bases in action
before they get added to the standard?

> ...
>
> the GOST S-boxes are specified directly in russian GOST (Government
>Standard) 28147-89.
>  
>


-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCSfmp025381; Fri, 21 Jan 2005 04:28:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0LCSfAY025376; Fri, 21 Jan 2005 04:28:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0LCSdes025282 for <[e-mail]>; Fri, 21 Jan 2005 04:28:39 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.ru ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1Crxtk-0004lP-2P for [e-mail]; Fri, 21 Jan 2005 15:28:03 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: <[e-mail]>
Subject: RE: Adding GOST as a cipher? (algo specs)
Date: Fri, 21 Jan 2005 18:26:34 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

In case somebody is interested in more information, here are some references:

Original GOST 28147-89 cipher specs translated in English
http://vipul.net/gost/papers/gost-spec.ps.gz
http://vipul.net/gost/papers/russian-des.ps.gz
GOST 28147-89 mathematical analysis
http://vipul.net/gost/papers/further-comments.ps.gz

Original GOST R 34.11-94 hash algorithm specs translated in English
http://www.cl.cam.ac.uk/users/mrr/gost/gost34.11.dvi (incomplete)
C implementation and test vectors
http://www.tcs.hut.fi/~mjos/gosthash.tar.gz

Additional cryptographic algorithms for use with GOST 28147-89, GOST R
34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 algorithms (Vladimir Popov,
Igor Kurepkin, Serguei Leontiev)
http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-popov-cryptopro-cp
algs-01.txt

Many GOST documents translations for a reasonable prices
http://www.eastview.com/xq/ASP/ics_code=35.040/f_start_value=1/f_ml=20/browse_
order=gost_english/browse_order_asc=asc/f_locale=_cyr/qx/russian/standards/bro
wse_standard.asp

IAIK-JCE API GOST Java implementation
http://jce.iaik.tugraz.at/products/01_jce/documentation/javadoc/iaik/security/
cipher/GOST.html


Respectfully yours,

 Vladislav "SATtva" Miller
 http://www.pgpru.com






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L8lQlY096516; Fri, 21 Jan 2005 00:47:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L8lQ7E096514; Fri, 21 Jan 2005 00:47:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from branwen.iks-jena.de ([e-mail] [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L8lONd096473 for <[e-mail]>; Fri, 21 Jan 2005 00:47:25 -0800 (PST) (envelope-from [e-mail])
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.1/8.13.1) with ESMTP id j0L8lL3i026939 for <[e-mail]>; Fri, 21 Jan 2005 09:47:23 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.1/8.13.1/Submit) id j0L8lLrv026938 for [e-mail]; Fri, 21 Jan 2005 09:47:21 +0100
To: [e-mail]
Path: not-for-mail
From: Lutz Donnerhacke <[e-mail]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Adding GOST as a cipher?
Date: Fri, 21 Jan 2005 08:47:21 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 11
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1106297241 25738 217.17.192.37 (21 Jan 2005 08:47:21 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Fri, 21 Jan 2005 08:47:21 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

* Lutz Donnerhacke wrote:
> * Ian G wrote:
>> It would however be a nuisance if it was "rushed in" only to find out
>> later that it is ... not quite right.  I gather there are rather a lot of
>> options behind the simple 'GOST' word?  Is this the algorithm where the
>> S-Boxes aren't specified in the standard?
>
> Exactly. GOST is assumed to be more vulnerable than DES.

It seems to be changed in the past. I try to get the standards in order to
quickly evaluate the usefulness.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L8S4rX063648; Fri, 21 Jan 2005 00:28:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L8S4Os063647; Fri, 21 Jan 2005 00:28:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from branwen.iks-jena.de ([e-mail] [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L8S2gs063336 for <[e-mail]>; Fri, 21 Jan 2005 00:28:03 -0800 (PST) (envelope-from [e-mail])
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.1/8.13.1) with ESMTP id j0L8Rraa026407 for <[e-mail]>; Fri, 21 Jan 2005 09:27:55 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.1/8.13.1/Submit) id j0L8RrPO026406 for [e-mail]; Fri, 21 Jan 2005 09:27:53 +0100
To: [e-mail]
Path: not-for-mail
From: Lutz Donnerhacke <[e-mail]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Adding GOST as a cipher?
Date: Fri, 21 Jan 2005 08:27:52 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 7
Message-ID:  <[e-mail]>
References:  <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1106296072 25738 217.17.192.37 (21 Jan 2005 08:27:52 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Fri, 21 Jan 2005 08:27:52 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

* Ian G wrote:
> It would however be a nuisance if it was "rushed in" only to find out
> later that it is ... not quite right.  I gather there are rather a lot of
> options behind the simple 'GOST' word?  Is this the algorithm where the
> S-Boxes aren't specified in the standard?

Exactly. GOST is assumed to be more vulnerable than DES.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L3MJtC053777; Thu, 20 Jan 2005 19:22:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L3MJik053776; Thu, 20 Jan 2005 19:22:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L3MIhh053594 for <[e-mail]>; Thu, 20 Jan 2005 19:22:18 -0800 (PST) (envelope-from [e-mail])
Received: from nskfw1.beelinegprs.ru ([217.118.79.9] helo=1) by server.myhostnet.net with esmtpa (Exim 4.43) id 1CrpN2-0006tZ-EE for [e-mail]; Fri, 21 Jan 2005 06:21:41 +0300
From: "Vlad \"SATtva\" Miller" <[e-mail]>
To: <[e-mail]>
Subject: RE: Adding GOST as a cipher?
Date: Fri, 21 Jan 2005 09:18:24 +0600
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> Recently, I've been asked about adding GOST as a cipher into OpenPGP.
> It's needed in Russia and parts of Eastern Europe, where they use it in
> banking and government applications.

This won't help much unless you also consider specifying GOST R 34.11-94
(based on GOST 28147-89 block cipher) for hash function and GOST R 34.19-2001
(based on elliptic curves) for digital signature. These are the only permitted
algorithms for banking/government use in Russia. Don't know about other
Eastern Eaurope countries policies, though.

Ian G wrote:
> It would however be a nuisance if it was "rushed in"
> only to find out later that it is ... not quite right.  I
> gather there are rather a lot of options behind the
> simple 'GOST' word?  Is this the algorithm where
> the S-Boxes aren't specified in the standard?

Nope, the GOST S-boxes are specified directly in russian GOST (Government
Standard) 28147-89.


 Vladislav "SATtva" Miller
 "PGP in Russia" project leader
 http://www.pgpru.com





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L0nMsM000503; Thu, 20 Jan 2005 16:49:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0L0nMIS000502; Thu, 20 Jan 2005 16:49:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0L0nHPa099926 for <[e-mail]>; Thu, 20 Jan 2005 16:49:21 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0L0mN220510; Fri, 21 Jan 2005 00:48:35 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Fri, 21 Jan 2005 00:53:36 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: Adding GOST as a cipher?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:

>
> Recently, I've been asked about adding GOST as a cipher into OpenPGP. 
> It's needed in Russia and parts of Eastern Europe, where they use it 
> in banking and government applications.


I gather that there are regulations that state that
only GOST is permitted to be used.  (Beyond that, I
don't know any more.)

> Is there an objection to finding out what the right thing to do is, 
> and putting it in the draft? This really consists of allocating an 
> identifier for it, and specifying the parameters. I'd look to what 
> they're doing in an S/MIME draft for the right thing.


The only objection I would have is if it help up the
draft.  If something else is holding up the draft, no
problems.

It would however be a nuisance if it was "rushed in"
only to find out later that it is ... not quite right.  I
gather there are rather a lot of options behind the
simple 'GOST' word?  Is this the algorithm where
the S-Boxes aren't specified in the standard?

> Without this, the people who need to do it are going to push it into 
> the private/experimental range, which is not the right thing, nor 
> scalable.


( There's no reason why they can't get it going in the
private/exp range and then when they are happy,
ask for allocation.  That's what it's for, really.  But,
whatever.... )

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KNmS59027063; Thu, 20 Jan 2005 15:48:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0KNmSU9027062; Thu, 20 Jan 2005 15:48:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0KNmRNQ026995 for <[e-mail]>; Thu, 20 Jan 2005 15:48:27 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.5) for <[e-mail]>; Thu, 20 Jan 2005 15:48:08 -0800
Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Thu, 20 Jan 2005 15:48:07 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: OpenPGP <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Adding GOST as a cipher?
Date: Thu, 20 Jan 2005 15:48:27 -0800
X-Mailer: Apple Mail (2.619)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Recently, I've been asked about adding GOST as a cipher into OpenPGP. 
It's needed in Russia and parts of Eastern Europe, where they use it in 
banking and government applications.

Is there an objection to finding out what the right thing to do is, and 
putting it in the draft? This really consists of allocating an 
identifier for it, and specifying the parameters. I'd look to what 
they're doing in an S/MIME draft for the right thing.

Without this, the people who need to do it are going to push it into 
the private/experimental range, which is not the right thing, nor 
scalable.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HHrHWe057208; Mon, 17 Jan 2005 09:53:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0HHrH3a057207; Mon, 17 Jan 2005 09:53:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HHrG1b057199 for <[e-mail]>; Mon, 17 Jan 2005 09:53:16 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 880FA33C6A; Mon, 17 Jan 2005 17:53:15 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Mon, 17 Jan 2005 17:53:18 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw wrote:
> On Sun, Jan 16, 2005 at 08:03:54AM +0000, Ben Laurie wrote:
> 
>>David Shaw wrote:
>>
>>>On Sat, Jan 15, 2005 at 04:38:32PM -0500, David Shaw wrote:
>>>
>>>
>>>>On Sat, Jan 15, 2005 at 08:54:51PM +0000, Ben Laurie wrote:
>>>>
>>>>
>>>>>3.2 (MPI) doesn't specify what the unused bits should be set to. This 
>>>>>may be deliberate but I think it should either say they MUST be zero 
>>>>>(which I prefer) or that their content is unspecified.
>>>>
>>>>I'm not completely sure what you are referring to here.  Do you mean
>>>>the difference (given an MPI of value "1") between [00 01 01] and [00
>>>>01 02] ?  The 0x02 bit of the 3rd octet?
>>>
>>>
>>>Er, I meant [00 01 03], but the question still holds.  Are you
>>>referring to the 0x02 bit of the last octet?
>>
>>Yes.
> 
> 
> I see.  I think that the draft does indirectly specify that the unused
> bits are 0.  In section 3.2 it states "These octets form a big-endian
> number; a big-endian number can be made into an MPI by prefixing it
> with the appropriate length."  [00 01 03] would violate that
> statement, since the big-endian number would be 3, rather than 1.

I don't think that would be an unambiguous requirement, since the 
implementation might also measure length in bits.

> I certainly don't have any objection to making it more explicit than
> that, though.

Good.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HGiInk041943; Mon, 17 Jan 2005 08:44:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0HGiIIl041942; Mon, 17 Jan 2005 08:44:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HGiH0T041930 for <[e-mail]>; Mon, 17 Jan 2005 08:44:17 -0800 (PST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1CqZTy-0005KT-MS for <[e-mail]>; Mon, 17 Jan 2005 17:11:58 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1CqZyD-0003Cm-C7; Mon, 17 Jan 2005 17:43:13 +0100
To: "Brian G. Peterson" <[e-mail]>
Cc: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Mon, 17 Jan 2005 17:43:13 +0100
In-Reply-To: <[e-mail]> (Brian G. Peterson's message of "Mon, 17 Jan 2005 08:07:59 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0HGiI0T041935
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 17 Jan 2005 08:07:59 -0600, Brian G Peterson said:

> Your examples serve to show the flaw in the RFC. Because the RFC does not 
> specify that each attachment should be signed as a digital file with a 
> detached signature to allow external verification, the user is required to do 
PGP/MIME describes a MIME content type and trhat's it.  It does not
give guidelines on how users should write or sign mail; that is a
policy decision and not in the scope of a MIME.  

> RFC 3156 does not forbid this kind of behaviour, but it does not require it 
> either, so most implementations have chosen to supply one signature across 
> all the MIME parts, making verification outside of an email systems extremely 
In most cases there is no need to separate signatures.  They only make
sense if you either receive and forward a signed attachment with a new
mail or you want to save the attackment independent of the mail.
That is an organizational issue and a technical one.  

> require a MIME compliant MUA/program/script to verify.  They are 
> independently verifiable once detached from the MUA.  I just want that 
> independent verification standardized in MIME implementations as well.

You need a pretty complicated tool to very the signature but don't
want to throw in a couple of lines for a tool for proper MIME parsing?
That is strange.  Go to any vendor or hacker and ask for an
appropriate tool; its easy build.
  
> Inserting a MIME-specific Content-Header inside the boundaries of the 
> signature is a *problem* for independent verification.  Removal of the 
> unneeded Content-Header and MIME junk from attachments, and requiring 

It is not a problem but a MIME requirement.  Without the
content-header you have no way to identify the used charset.  Without
this infotrmation you are not able to display a document correctly -
it might even convey the wrong message: There are similar character
sets using the same encoding for the national currency symbol.  It
makes a lot of difference whether to talk about British Pound or USD.

It sometimes happens that you need to compile a message from different
sources where those message are not all in utf-8.  Indicating the
characterset is thus a requirement; you might not even be able to
recode all character set if you didn't install it or there are no 1-1
conversions possible.  And recoding would break the signature.

> Some MUA implementors (KMail, Mutt, the GPG Plugin for Squirrelmail) do this 
> already, because it is the right thing to do.  I just want to see the 
> standard (a future revision of RFC 3156) support and require that. 

Huh?  You mean they don't send a content-type if it defaults to
us-ascii?  Well, this is possible but in the majority of the world's
languages this does not work.

> It looks as though the PGP Corp folks have chosen to implement it not using 
> the standard preferences model.  Perhaps Hal or Jon could comment on this, 

Which is the Right Thing to do; unless it is defined by the standard
they may only use the namespace reserved for private use.  

>> that this will lead to practically abolish PGP/MIME.

> I don't think that is the case.  I too would prefer to use PGP MIME with minor 
> improvements on the standard to guide MUA implementors to do the right thing.

MIME and PGP/MIME are a reality and both are good and usable standards;
used in all modern IETF protocols - not only for mail.  Its a bit
strange to hear comments against the use of MIME only from people
using almost only English and ASCII for there communication.  The
world is not anymore plain 7 bit; these times have fortunately gone. I
am not the only one glad to see that there are no more printouts like 
"foo_t fooÄ3Ü = ä 'ß', 1ö2, 'Ön' ü;" as common in the pre MIME days.


Shalom-Salam,

   Werner




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HE82q3081254; Mon, 17 Jan 2005 06:08:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0HE82Hn081253; Mon, 17 Jan 2005 06:08:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (IDENT:[e-mail] [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HE81nD081244 for <[e-mail]>; Mon, 17 Jan 2005 06:08:01 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.1.102] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.12.8/8.12.8) with ESMTP id j0HE80k0030315 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 17 Jan 2005 08:08:00 -0600
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
Date: Mon, 17 Jan 2005 08:07:59 -0600
User-Agent: KMail/1.7.2
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Monday 17 January 2005 03:47 am, Werner Koch wrote:
> > On Sun, 16 Jan 2005 12:11:03 -0600, Brian G Peterson said:
> > across all parts, generating a signature for the entirety of the
> > email-specific MIME structure, and not signing individual attachments.  I
> > believe that this is a serious flaw in RFC 3156.
>
> That is not a flaw in rfc 3156 but in the implementations. The same UI
> requirements hold true for that partitioned format.
>
> Kmail for example allows to select the attachments to be signed. By
> using forwarding and combining messages you are able to select
> different signatures with any fully MIME aware MUA.

Your examples serve to show the flaw in the RFC. Because the RFC does not 
specify that each attachment should be signed as a digital file with a 
detached signature to allow external verification, the user is required to do 
a lot of work that should be unnecessary.

A signature across all the MIME parts to verify the entire email structure, 
plus separate detached signatures on each *attachment* (without the 
unecessary Content-Type header that RFC 3156 unwisely requires) would allow 
for simple signature verification of the signature on any attachment, using 
any OpernPGP compliant tool, and requiring no MIME knowledge for the 
verifier.

RFC 3156 does not forbid this kind of behaviour, but it does not require it 
either, so most implementations have chosen to supply one signature across 
all the MIME parts, making verification outside of an email systems extremely 
difficult.  This is, in my opinion, a serious flaw in RFC 3156.

Partitioned is not much better, because it does, as you note, have UI 
difficulties in presenting the information to the user, verifying signatures 
on each individual part and across the whole.  Partitioned implementations 
currently have the advantage that the signatures on each attachment do not 
require a MIME compliant MUA/program/script to verify.  They are 
independently verifiable once detached from the MUA.  I just want that 
independent verification standardized in MIME implementations as well.
  
> > decryptable/verifiable, even outside of an MUA.  I think that independent
>
> Again, that is a matter of the tools and not of the protocol.  In fact
> it is not that hard to verify PGP/MIME with a simple script and the
> usual mime tools.  The real challenge is to present the signature
> status in an appropriate way to the user.

If each attachment were required to have an independently verifiable 
signature, then there would be no difficulty in doing so, and you wouldn't 
need MIME tools and technical knowledge outside the MUA to verify the 
detached signatures.

> > verification of a signature on each part, and a signature across the
> > whole, are a feature that should be required of any email implementation
> > (although
>
> Kmail as well as Mutt allow exactly for this.  Any MUA with proper
> MIME and OpenPGP support will handle this.

Because they chose to, because it is the right thing to do.  The RFC does not 
require it, which was my point.

> > Many MUA's have chosen to not support inline or partitioned methods of
> > Encrypting/Signing mail content.  This seriously limits interoperability,
> > and I think that this needs to be addressed in RFC 2440bis (because that
> > is what is under discussion now) and in any future revision of RFC 3156.
>
> There is only one MUA which causes all the problems and that one is
> notriously known for its security flaws.  MUAs not doing PGP?MIME do
> this to be compatible to that one other MUA.
>
> > I do not believe that support for partitioned in the notation packet
> > implies RFC 1991 compatibility.  We have decided that 2440bis will
> > obsolete RFC 1991,
>
> Please recall that 1991 is informational and not on the standard
> track.
>
> > 'partitioned' scheme is the only option currently available to
> > implementors who require independent verification of each part, as well
> > as verification of
>
> Wrong.  

Inserting a MIME-specific Content-Header inside the boundaries of the 
signature is a *problem* for independent verification.  Removal of the 
unneeded Content-Header and MIME junk from attachments, and requiring 
separate signatures on attachments, would remove my complaint about RFC 3156.  
Some MUA implementors (KMail, Mutt, the GPG Plugin for Squirrelmail) do this 
already, because it is the right thing to do.  I just want to see the 
standard (a future revision of RFC 3156) support and require that. 
 
> The only reason is allowing plugins for Outlook.  I don't 
> expect that Cryptorights suggests the use of that MUA.

No, Cryptorights does not use Outlook internally, or recommend it to others 
where security is an issue.  However, many *recipients* of mail from human 
rights workers will undoubtedly be using MS Outlook.  Interoperability is in 
everyone's advantage, as I'm sure you agree.  Having the standard be clear on 
what is required for interoperability makes it far more likely than in the 
current state where the right thing to do is not the same as the minimum that 
the standard requires.

> I am not against these preferences but they should not in any way
> endorse non-PGP/MIME.  Keeping that off the standard and using agreed
> on notation data is thus the better decision.  

It looks as though the PGP Corp folks have chosen to implement it not using 
the standard preferences model.  Perhaps Hal or Jon could comment on this, 
and indicate whether they would be willing to comment on that proposal: 
putting email preference data in the existing preferences packets on the key.
   
> For technical reasons 
> I'd like to see it done in the same way as the preferences but I fear
> that this will lead to practically abolish PGP/MIME.

I don't think that is the case.  I too would prefer to use PGP MIME with minor 
improvements on the standard to guide MUA implementors to do the right thing.

Regards,

  - Brian



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0HA0RnR052486; Mon, 17 Jan 2005 02:00:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0H9neYU047902; Mon, 17 Jan 2005 01:49:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0H9nZQH047547 for <[e-mail]>; Mon, 17 Jan 2005 01:49:39 -0800 (PST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1CqT0X-0003DQ-TY for <[e-mail]>; Mon, 17 Jan 2005 10:17:09 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1CqTTc-0001Cq-Dd; Mon, 17 Jan 2005 10:47:12 +0100
To: "Brian G. Peterson" <[e-mail]>
Cc: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Mon, 17 Jan 2005 10:47:12 +0100
In-Reply-To: <[e-mail]> (Brian G. Peterson's message of "Sun, 16 Jan 2005 12:11:03 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sun, 16 Jan 2005 12:11:03 -0600, Brian G Peterson said:

> across all parts, generating a signature for the entirety of the 
> email-specific MIME structure, and not signing individual attachments.  I 
> believe that this is a serious flaw in RFC 3156.

That is not a flaw in rfc 3156 but in the implementations. The same UI
requirements hold true for that partitioned format.

Kmail for example allows to select the attachments to be signed. By
using forwarding and combining messages you are able to select
different signatures with any fully MIME aware MUA.

> decryptable/verifiable, even outside of an MUA.  I think that independent 

Again, that is a matter of the tools and not of the protocol.  In fact
it is not that hard to verify PGP/MIME with a simple script and the
usual mime tools.  The real challenge is to present the signature
status in an appropriate way to the user.

> verification of a signature on each part, and a signature across the whole, 
> are a feature that should be required of any email implementation (although 

Kmail as well as Mutt allow exactly for this.  Any MUA with proper
MIME and OpenPGP support will handle this.

> Many MUA's have chosen to not support inline or partitioned methods of 
> Encrypting/Signing mail content.  This seriously limits interoperability, and 
> I think that this needs to be addressed in RFC 2440bis (because that is what 
> is under discussion now) and in any future revision of RFC 3156.

There is only one MUA which causes all the problems and that one is
notriously known for its security flaws.  MUAs not doing PGP?MIME do
this to be compatible to that one other MUA.

> I do not believe that support for partitioned in the notation packet implies 
> RFC 1991 compatibility.  We have decided that 2440bis will obsolete RFC 1991, 

Please recall that 1991 is informational and not on the standard
track.

> 'partitioned' scheme is the only option currently available to implementors 
> who require independent verification of each part, as well as verification of 

Wrong.  The only reason is allowing plugins for Outlook.  I don't
expect that Cryptorights suggests the use of that MUA.

I am not against these preferences but they should not in any way
endorse non-PGP/MIME.  Keeping that off the standard and using agreed
on notation data is thus the better decision.  For technical reasons
I'd like to see it done in the same way as the preferences but I fear
that this will lead to practically abolish PGP/MIME.



Salam-Shalom,

   Werner





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0H63RMo092623; Sun, 16 Jan 2005 22:03:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0H63RS6092622; Sun, 16 Jan 2005 22:03:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0H63Qf1092527 for <[e-mail]>; Sun, 16 Jan 2005 22:03:27 -0800 (PST) (envelope-from [e-mail])
Received: from pd9e1f62c.dip.t-dialin.net ([217.225.246.44] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1CqPyu-0000Kg-00 for <[e-mail]>; Mon, 17 Jan 2005 07:03:16 +0100
From: Konrad Rosenbaum <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header
Date: Mon, 17 Jan 2005 07:03:11 +0100
User-Agent: KMail/1.7.2
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3530965.pIDdUtvxFC"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--nextPart3530965.pIDdUtvxFC
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 16 January 2005 21:00, Simon Josefsson wrote:
> >> The reason was supposedly that with v3 keys, you subject to something
> >> called the 0xDEADBEEF attack, where I infer that keys can be created
> >> easily with any given key id.  The attack is not possible with v4
> >> keys.  Someone said the attack is harder for v3 keys if you also
> >> compare the key size, key algorithm and creation time.
> >
> > There are actually two different attacks.  It is trivial to create a
> > V3 key with any key ID you like.  That's the 0xDEADBEEF attack.  There
> > is a different attack altogether (but lacking a catchy name), which is
> > against the V3 fingerprint.  Since the V3 fingerprint consists of the
> > RSA values n and e, but not their lengths, you can do tricks with
> > 'sliding' bits from one into the other.  The end result is a
> > constructed V3 key with the same fingerprint as the 'victim' V3 key.
> > The trick is that such a constructed key will always have a different
> > size than the original key.
>
> Thanks for explaining this, I finally understand.  So it seems
> "created" never help to mitigate any attacks.  Only size does (and
> from your description, perhaps also algo).

Actually: only V4 helps. Everything else with V3 can (theoretically, as=20
unlikely as it is) be changed during transmission (length, timestamps,=20
etc.pp.) without the receipient noticing, since the fingerprint does not=20
change (well, with recent advances against MD5 even the V3 key material=20
cannot be considered secure any more).



	Konrad

--nextPart3530965.pIDdUtvxFC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBB61UiClt766LaIH0RAkwqAJ0VySAJAUMxJLg3y9vIGF9M3rqmaQCggF+7
l0f7FB0NEc3humes6JHmMqY=
=13ZF
-----END PGP SIGNATURE-----

--nextPart3530965.pIDdUtvxFC--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GK0eSL097051; Sun, 16 Jan 2005 12:00:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GK0e4S097050; Sun, 16 Jan 2005 12:00:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GK0cs5097017 for <[e-mail]>; Sun, 16 Jan 2005 12:00:39 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0GK0a3V010308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for <[e-mail]>; Sun, 16 Jan 2005 21:00:37 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050116:[e-mail]::B6RErRjtfpK4Wxyx:Mzj/
Date: Sun, 16 Jan 2005 21:00:26 +0100
In-Reply-To: <[e-mail]> (David Shaw's message of "Sun, 16 Jan 2005 13:39:42 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw <[e-mail]> writes:

> On Sun, Jan 16, 2005 at 12:04:37PM +0100, Simon Josefsson wrote:
>
>> This seems like a good solution.  Will there ever be a need to have
>> key id's of different length than 4, 8, 16 and 20 bytes?  The BNF now
>> reads:
>> 
>> id        := 4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG
>> 
>> And I'm not certain it is a good idea to allow the flexibility of
>> 
>> id        := *HEXDIG
>
> I like the simplicity and flexibility of this.  The key ID field is a
> message from the OpenPGP user to the world.  Specifying that the ID
> must be a particular length doesn't really help anyone, since it is up
> to the recipient to decide how the key ID is going to be handled
> anyway.  Plus, someday we'll have a v5 key.  Chances are it won't be
> 40 hex digits long.

Ok, I'm convinced.

>> Thanks for this input.  I have been trying to understand why
>> algo/size/created are needed, but nobody has been able to explain it
>> to me.
>> 
>> The reason was supposedly that with v3 keys, you subject to something
>> called the 0xDEADBEEF attack, where I infer that keys can be created
>> easily with any given key id.  The attack is not possible with v4
>> keys.  Someone said the attack is harder for v3 keys if you also
>> compare the key size, key algorithm and creation time.
>
> There are actually two different attacks.  It is trivial to create a
> V3 key with any key ID you like.  That's the 0xDEADBEEF attack.  There
> is a different attack altogether (but lacking a catchy name), which is
> against the V3 fingerprint.  Since the V3 fingerprint consists of the
> RSA values n and e, but not their lengths, you can do tricks with
> 'sliding' bits from one into the other.  The end result is a
> constructed V3 key with the same fingerprint as the 'victim' V3 key.
> The trick is that such a constructed key will always have a different
> size than the original key.

Thanks for explaining this, I finally understand.  So it seems
"created" never help to mitigate any attacks.  Only size does (and
from your description, perhaps also algo).

>> Without understanding the motivation for size/algo/created, I'm in
>> favor of dropping them.
>
> Even understanding the motivation, I'm in favor of dropping them.  V3
> keys are deprecated.  If someone desperately needs to use V3 keys, and
> desperately needs to include their key size in the OpenPGP header to
> foil this attack, well, there is already a way to include arbitrary
> free-text comments in the header.

Right, unless someone has a good argument to keep them, I believe they
will be dropped.

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GJRDso054191; Sun, 16 Jan 2005 11:27:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GJRDQJ054189; Sun, 16 Jan 2005 11:27:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GJRB5v054115 for <[e-mail]>; Sun, 16 Jan 2005 11:27:12 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0GJR4qc008394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sun, 16 Jan 2005 20:27:05 +0100
From: Simon Josefsson <[e-mail]>
To: "Brian G. Peterson" <[e-mail]>
Cc: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050116:[e-mail]::B7rvdWpXAdepbDp1:05QH
X-Hashcash: 1:21:050116:[e-mail]::ofFf/OoYLCpFb6B+:2ciJ
Date: Sun, 16 Jan 2005 20:26:54 +0100
In-Reply-To: <[e-mail]> (Brian G. Peterson's message of "Sun, 16 Jan 2005 12:11:03 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"Brian G. Peterson" <[e-mail]> writes:

> Here's my issue with PGP/MIME (RFC 3156)  The PGP/MIME standard defines 
> placing an email-specific Content-Type header inside the section covered by 
> the signature, making verification of binary content difficult outside of a 
> mail client.  Further, almost all implementations generate a single signature 
> across all parts, generating a signature for the entirety of the 
> email-specific MIME structure, and not signing individual attachments.  I 
> believe that this is a serious flaw in RFC 3156.
>
> One of the users of the GPG Plugin for Squirrelmail the I am the primary 
> implementor of is human rights workers (via the CryptoRights Foundation).  
> For evidentiary reasons in this implementation, it is critical that each 
> binary attachment (documents, pictures, whatever) have independently 
> verifiable signatures.  The 'partitioned' method accomplishes this, by 
> encrypting/signing each part, so that each part is independently 
> decryptable/verifiable, even outside of an MUA.  I think that independent 
> verification of a signature on each part, and a signature across the whole, 
> are a feature that should be required of any email implementation (although 
> this is a bit out of scope for the current discussion of preference 
> notations).

That was a good summary of issues with PGP/MIME.  I hadn't been fully
aware of these before, although now that you make them clear, I recall
several situations (think proxies) where this has been an issue.

>> If you are seriously proposing to make inline/partitioned a standard
>> scheme for PGP in e-mail, you should describe how it should be
>> implemented.  I have experience with the inline style, and
>> non-deployed experience with the "partitioned"-style.  The problems
>> that need to be addressed to make this a serious alternative is RFC
>> 1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
>> in bodies and PGP headers), trailing white space interaction with
>> format=flowed, interaction with QP and '-' and '=' in the PGP armor.
>
> Many MUA's have chosen to not support inline or partitioned methods of 
> Encrypting/Signing mail content.  This seriously limits interoperability, and 
> I think that this needs to be addressed in RFC 2440bis (because that is what 
> is under discussion now) and in any future revision of RFC 3156.

Or a separate document.  I agree.  I think the reason people don't
implement inline/partitioned is that there simply is no specification
for how to do it.  And there are a number of complicated things to
solve to implement it.  Whether to apply the non-ASCII processing in
MIME before or after the PGP layer is one open issue.  If QP is
applied before PGP, it is also unclear how to deal with escaping of
'=' for QP in the PGP CRC24 field.

Regards,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GJLhvO045392; Sun, 16 Jan 2005 11:21:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GJLhgs045391; Sun, 16 Jan 2005 11:21:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GJLgoA045313 for <[e-mail]>; Sun, 16 Jan 2005 11:21:42 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0GJLU9J008228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sun, 16 Jan 2005 20:21:31 +0100
From: Simon Josefsson <[e-mail]>
To: Ian G <[e-mail]>
Cc: [e-mail]
Subject: Re: OpenPGP mail/news header
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050116:[e-mail]::VfbVI6C5mNCmY+Ff:4I2g
X-Hashcash: 1:21:050116:[e-mail]::FNSwRZjGnAWDt43L:KyIF
Date: Sun, 16 Jan 2005 20:21:20 +0100
In-Reply-To: <[e-mail]> (Ian G.'s message of "Sun, 16 Jan 2005 18:43:36 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ian G <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>
>>>This may (already has?) provide a loophole to MUA implementations
>>>that don't want to support inline/partitioned.  I'm very much in
>>>support of a user preference notation packet, because this puts the
>>>control in the hands of the key holder, and implies that MUA's
>>>SHOULD (RFC language intentional here) support partitioned and mime.
>>>    
>>>
>>
>>Oh.  It seems we do disagree.
>>
>>I believe that inline/partitioned should never be recommended by any
>>RFC, at least without more specification.  I believe RFCs should
>>clearly recommended against its use in e-mail because we have PGP/MIME
>>that, to my knowledge, solve all known problems, if implementors were
>>to actually support it.  RFC 2440 does this correctly.
>>
>>A question was raised earlier in this WG why 2440bis do not include
>>the same text, but I'm not sure there was consensus declared.
>>  
>>
>
> If I follow you, you are saying that 2440bis should
> recommend email as being done in a certain way
> (PGP/MIME?).

It may be a good idea, yes.  Having more than one way to do things is
generally bad.

> But that way is specified in another RFC which is higher layer.
> This is the normal way of things, the lower layers specify things
> like data packet preparation and key issues, and the higher layer
> applications sort out transport issues in their medium.

If that way worked, then it would be fine, but it seems that many
organizations are not using PGP/MIME but rather use inline or
"partitioned".  I doubt they all do it because they have considered
PGP/MIME and rejected it on a technical basis, although Brian's post
made me recall that there are some unaddressed matters in PGP/MIME as
well.

> (What could be said is that the ascii-armoured form
> would be better off in another RFC.  But I think it
> is a bit of a sidetrack at this late stage of the game,
> the historical circumstance is that PGP includes
> a legacy method of ascii-armouring for email and
> other things, and I don't think there is much support
> for removing it ... which would be far preferable to
> muddying RFC2440bis with PGP/MIME.)

Continuing this hypothetical discussion, perhaps PGP/MIME should have
been just that ASCII-armor layer on top of a binary PGP format.  The
ASCII limitation come from the e-mail world, after all, if I
understand correctly, so it make sense for the e-mail world to handle
it, instead of the PGP format itself.

I think this would also make things more similar between OpenPGP and
CMS, and how CMS is used in e-mail.

However, all this is probably not a practical course of action.

>>I'd be disappointed if IETF approved a standard that implied use of
>>PGP in e-mail in any other way than PGP/MIME.
>>
>
> Other than the inclusion of the ascii-armouring
> thing, I don't think there is a need to specify
> email at all in RFC2440bis.  PGP is a way of
> creating messages for sending, and it cares
> not whether the transport is over email or
> over IM or over pigeon post.

However, there is a lot of confusion about how to use OpenPGP in
e-mail.  If there is an opportunity to resolve that confusion by
adding text to 2440bis, then I think it would help.

>>If you are seriously proposing to make inline/partitioned a standard
>>scheme for PGP in e-mail, you should describe how it should be
>>implemented.  I have experience with the inline style, and
>>non-deployed experience with the "partitioned"-style.  The problems
>>that need to be addressed to make this a serious alternative is RFC
>>1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
>>in bodies and PGP headers), trailing white space interaction with
>>format=flowed, interaction with QP and '-' and '=' in the PGP armor.
>
> The RFC is pretty much fixed in the large.  I
> don't think it does what you say:  propose a
> standard scheme for email.
>
> Having said that, there is some scope for
> including some warnings, seeing as the
> scheme is in there.

I didn't mean 2440bis would standardize "partitioned".  For what it's
worth, I think it should go into a separate document, much like
PGP/MIME.  Specifying a notational packet that indicate implementors
should support a specific scheme that isn't specified appear to invite
interoperability problems.

>>> As an MUA implementor, I'm very concerned with the poor
>>> interoperability caused by the current lack of clarity, so I want
>>> this strengthened for the benefit of the users, who shouldn't need
>>> to worry too much about this if the standard is clear.
>>>    
>>>
>>
>>Right.
>>
>>If everyone implemented PGP/MIME we wouldn't have this problem.
>>  
>>
>
> Yes, but we are in the world of standardising
> practice, not hopes and desires.

But when existing practice are problematic for users, it needs to be
improved, and I have viewed PGP/MIME as being an improvement like
that.

Regards,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GIe1wR090986; Sun, 16 Jan 2005 10:40:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GIe1wY090985; Sun, 16 Jan 2005 10:40:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GIe0jr090930 for <[e-mail]>; Sun, 16 Jan 2005 10:40:00 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <20050116183954016006opnve>; Sun, 16 Jan 2005 18:39:54 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0GIdrff027965 for <[e-mail]>; Sun, 16 Jan 2005 13:39:54 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0GIdg5o025154 for <[e-mail]>; Sun, 16 Jan 2005 13:39:42 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0GIdgZI025153 for [e-mail]; Sun, 16 Jan 2005 13:39:42 -0500
Date: Sun, 16 Jan 2005 13:39:42 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=0x99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sun, Jan 16, 2005 at 12:04:37PM +0100, Simon Josefsson wrote:

> This seems like a good solution.  Will there ever be a need to have
> key id's of different length than 4, 8, 16 and 20 bytes?  The BNF now
> reads:
> 
> id        := 4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG
> 
> And I'm not certain it is a good idea to allow the flexibility of
> 
> id        := *HEXDIG

I like the simplicity and flexibility of this.  The key ID field is a
message from the OpenPGP user to the world.  Specifying that the ID
must be a particular length doesn't really help anyone, since it is up
to the recipient to decide how the key ID is going to be handled
anyway.  Plus, someday we'll have a v5 key.  Chances are it won't be
40 hex digits long.

> Thanks for this input.  I have been trying to understand why
> algo/size/created are needed, but nobody has been able to explain it
> to me.
> 
> The reason was supposedly that with v3 keys, you subject to something
> called the 0xDEADBEEF attack, where I infer that keys can be created
> easily with any given key id.  The attack is not possible with v4
> keys.  Someone said the attack is harder for v3 keys if you also
> compare the key size, key algorithm and creation time.

There are actually two different attacks.  It is trivial to create a
V3 key with any key ID you like.  That's the 0xDEADBEEF attack.  There
is a different attack altogether (but lacking a catchy name), which is
against the V3 fingerprint.  Since the V3 fingerprint consists of the
RSA values n and e, but not their lengths, you can do tricks with
'sliding' bits from one into the other.  The end result is a
constructed V3 key with the same fingerprint as the 'victim' V3 key.
The trick is that such a constructed key will always have a different
size than the original key.

> Without understanding the motivation for size/algo/created, I'm in
> favor of dropping them.

Even understanding the motivation, I'm in favor of dropping them.  V3
keys are deprecated.  If someone desperately needs to use V3 keys, and
desperately needs to include their key size in the OpenPGP header to
foil this attack, well, there is already a way to include arbitrary
free-text comments in the header.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GIcOjK089188; Sun, 16 Jan 2005 10:38:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GIcOVY089186; Sun, 16 Jan 2005 10:38:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GIcMRR089118 for <[e-mail]>; Sun, 16 Jan 2005 10:38:22 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0GIc6226332 for <[e-mail]>; Sun, 16 Jan 2005 18:38:16 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Sun, 16 Jan 2005 18:43:36 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OpenPGP mail/news header
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Simon Josefsson wrote:

>
>>This may (already has?) provide a loophole to MUA implementations
>>that don't want to support inline/partitioned.  I'm very much in
>>support of a user preference notation packet, because this puts the
>>control in the hands of the key holder, and implies that MUA's
>>SHOULD (RFC language intentional here) support partitioned and mime.
>>    
>>
>
>Oh.  It seems we do disagree.
>
>I believe that inline/partitioned should never be recommended by any
>RFC, at least without more specification.  I believe RFCs should
>clearly recommended against its use in e-mail because we have PGP/MIME
>that, to my knowledge, solve all known problems, if implementors were
>to actually support it.  RFC 2440 does this correctly.
>
>A question was raised earlier in this WG why 2440bis do not include
>the same text, but I'm not sure there was consensus declared.
>  
>

If I follow you, you are saying that 2440bis should
recommend email as being done in a certain way
(PGP/MIME?).  But that way is specified in another
RFC which is higher layer.  This is the normal way
of things, the lower layers specify things like data
packet preparation and key issues, and the higher
layer applications sort out transport issues in their
medium.

(What could be said is that the ascii-armoured form
would be better off in another RFC.  But I think it
is a bit of a sidetrack at this late stage of the game,
the historical circumstance is that PGP includes
a legacy method of ascii-armouring for email and
other things, and I don't think there is much support
for removing it ... which would be far preferable to
muddying RFC2440bis with PGP/MIME.)

>I'd be disappointed if IETF approved a standard that implied use of
>PGP in e-mail in any other way than PGP/MIME.
>  
>

Other than the inclusion of the ascii-armouring
thing, I don't think there is a need to specify
email at all in RFC2440bis.  PGP is a way of
creating messages for sending, and it cares
not whether the transport is over email or
over IM or over pigeon post.

>If you are seriously proposing to make inline/partitioned a standard
>scheme for PGP in e-mail, you should describe how it should be
>implemented.  I have experience with the inline style, and
>non-deployed experience with the "partitioned"-style.  The problems
>that need to be addressed to make this a serious alternative is RFC
>1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
>in bodies and PGP headers), trailing white space interaction with
>format=flowed, interaction with QP and '-' and '=' in the PGP armor.
>  
>

The RFC is pretty much fixed in the large.  I
don't think it does what you say:  propose a
standard scheme for email.

Having said that, there is some scope for
including some warnings, seeing as the
scheme is in there.

>>As an MUA implementor, I'm very concerned with the poor interoperability 
>>caused by the current lack of clarity, so I want this strengthened for the 
>>benefit of the users, who shouldn't need to worry too much about this if the 
>>standard is clear.
>>    
>>
>
>Right.
>
>If everyone implemented PGP/MIME we wouldn't have this problem.
>  
>

Yes, but we are in the world of standardising
practice, not hopes and desires.

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GIB7ZQ055620; Sun, 16 Jan 2005 10:11:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GIB7ft055617; Sun, 16 Jan 2005 10:11:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (IDENT:[e-mail] [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GIB68i055590 for <[e-mail]>; Sun, 16 Jan 2005 10:11:06 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.1.102] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.12.8/8.12.8) with ESMTP id j0GIB3k0012666 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 16 Jan 2005 12:11:04 -0600
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: inline/partitioned vs. PGP/MIME support in MUA's
Date: Sun, 16 Jan 2005 12:11:03 -0600
User-Agent: KMail/1.7.2
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0GIB78i055612
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I'm changing the subject of my replay, to denote that UI think that this is a 
somewhat separate issue from whether the preference notation packets should 
be added to RFC 2440bis.

On Sunday 16 January 2005 10:58 am, Simon Josefsson wrote:
> I believe that inline/partitioned should never be recommended by any
> RFC, at least without more specification.  I believe RFCs should
> clearly recommended against its use in e-mail because we have PGP/MIME
> that, to my knowledge, solve all known problems, if implementors were
> to actually support it.  RFC 2440 does this correctly.
>
> A question was raised earlier in this WG why 2440bis do not include
> the same text, but I'm not sure there was consensus declared.
>
> I'd be disappointed if IETF approved a standard that implied use of
> PGP in e-mail in any other way than PGP/MIME.

Here's my issue with PGP/MIME (RFC 3156)  The PGP/MIME standard defines 
placing an email-specific Content-Type header inside the section covered by 
the signature, making verification of binary content difficult outside of a 
mail client.  Further, almost all implementations generate a single signature 
across all parts, generating a signature for the entirety of the 
email-specific MIME structure, and not signing individual attachments.  I 
believe that this is a serious flaw in RFC 3156.

One of the users of the GPG Plugin for Squirrelmail the I am the primary 
implementor of is human rights workers (via the CryptoRights Foundation).  
For evidentiary reasons in this implementation, it is critical that each 
binary attachment (documents, pictures, whatever) have independently 
verifiable signatures.  The 'partitioned' method accomplishes this, by 
encrypting/signing each part, so that each part is independently 
decryptable/verifiable, even outside of an MUA.  I think that independent 
verification of a signature on each part, and a signature across the whole, 
are a feature that should be required of any email implementation (although 
this is a bit out of scope for the current discussion of preference 
notations).

> If you are seriously proposing to make inline/partitioned a standard
> scheme for PGP in e-mail, you should describe how it should be
> implemented.  I have experience with the inline style, and
> non-deployed experience with the "partitioned"-style.  The problems
> that need to be addressed to make this a serious alternative is RFC
> 1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
> in bodies and PGP headers), trailing white space interaction with
> format=flowed, interaction with QP and '-' and '=' in the PGP armor.

Many MUA's have chosen to not support inline or partitioned methods of 
Encrypting/Signing mail content.  This seriously limits interoperability, and 
I think that this needs to be addressed in RFC 2440bis (because that is what 
is under discussion now) and in any future revision of RFC 3156.

> The problems that need to be addressed to make this a serious 
> alternative is RFC 1991-compatibility wrt dash-escaping, 
> interaction with non-ASCII (both in bodies and PGP headers), 
> trailing white space interaction with format=flowed, 
> interaction with QP and '-' and '=' in the PGP armor. 

I do not believe that support for partitioned in the notation packet implies 
RFC 1991 compatibility.  We have decided that 2440bis will obsolete RFC 1991, 
if I recall the concensus of the group correctly.  We have also otherwise 
addressed dash-escaping and trailing whitespace issues.  I think that a 
'partitioned' scheme is the only option currently available to implementors 
who require independent verification of each part, as well as verification of 
the whole.

Regards,

  - Brian



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GHDCQf082502; Sun, 16 Jan 2005 09:13:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GHDC6b082501; Sun, 16 Jan 2005 09:13:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GHD8w6082123 for <[e-mail]>; Sun, 16 Jan 2005 09:13:09 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0GHBq225725; Sun, 16 Jan 2005 17:12:04 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Sun, 16 Jan 2005 17:17:22 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simon Josefsson <[e-mail]>
CC: Jon Callas <[e-mail]>, [e-mail], atom <[e-mail]>
Subject: Re: OpenPGP mail/news header
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Simon Josefsson wrote:

>>* We're deprecating V3 keys.  You should either not mention them, or
>>mention that they're deprecated.
>>    
>>
>
>What would a suitable reference for that decision be?
>  
>

It's been debated on this list many times.  I
don't think there is a suitable single for
this.  Here's the summary of the issues that
I know of, but bear in mind that I am biased.



1.  V3 keys are subject to a few quirky security
issues.

2.  V3 usage is quite low.  I don't think this has
been tested properly, but we are talking in the
low 1-10% area.

3.  V3 architecture is old.  A rewrite is well
over due.  (Note that the same applies to the
V4 architecture which is now a good 8 years
old or so ;)

4.  Supporting both key types is a drain on
the implementors.  If they are supporting
old / dying key formats, they are not writing
other crypto code.

5.  As it is security code, the notion of clearing
out deadwood is always good.  Complexity
leads to security holes.  This is different to
the (say) Microsoft world where customer
compatibility is the important issue.  (hmmm,
maybe I need to revise that?  Nah...)

6.  Finally, deprecating the V3 in the standard
doesn't mean you can't support it.  By all means,
support it if you think there is some use for it.
Dropping it from the standard just means that
we are not telling all the implementors that
they *have* to support it.  So now, V3 can move
over to a market-driven retirement.  In practice,
I suspect it will take another 5 years before the
major apps drop support for it.

7.  Our decision not to support it in the Java
library is indicative of a small budget;  there's
no way we can do "it all".  I imagine a lot of
small implementors will think the same,
RFC2440bis is already so big that something
has to give.



Hmm... having written all that, I'm not sure
there is a case for keeping them above :)  I'll
let someone else write that.


iang
-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GGx2xv061143; Sun, 16 Jan 2005 08:59:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GGx1jI061124; Sun, 16 Jan 2005 08:59:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GGwsYG060770 for <[e-mail]>; Sun, 16 Jan 2005 08:59:00 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0GGwiXG000994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sun, 16 Jan 2005 17:58:46 +0100
From: Simon Josefsson <[e-mail]>
To: "Brian G. Peterson" <[e-mail]>
Cc: [e-mail]
Subject: Re: OpenPGP mail/news header
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050116:[e-mail]::lXCz2LjAPFVhyxpj:11as
X-Hashcash: 1:21:050116:[e-mail]::qIK93NZpNEzSP635:DHsC
Date: Sun, 16 Jan 2005 17:58:34 +0100
In-Reply-To: <[e-mail]> (Brian G. Peterson's message of "Sun, 16 Jan 2005 10:04:28 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"Brian G. Peterson" <[e-mail]> writes:

> My concern with a 'supports' token is that this is probably/potentially 
> controlled by the MUA, not the user.

I'm not sure I agree with this view.

I believe OpenPGP should be an ultimately user controlled field, much
like From/To/Reply-To/Newsgroups etc are ultimately user controlled
fields.

> This may (already has?) provide a loophole to MUA implementations
> that don't want to support inline/partitioned.  I'm very much in
> support of a user preference notation packet, because this puts the
> control in the hands of the key holder, and implies that MUA's
> SHOULD (RFC language intentional here) support partitioned and mime.

Oh.  It seems we do disagree.

I believe that inline/partitioned should never be recommended by any
RFC, at least without more specification.  I believe RFCs should
clearly recommended against its use in e-mail because we have PGP/MIME
that, to my knowledge, solve all known problems, if implementors were
to actually support it.  RFC 2440 does this correctly.

A question was raised earlier in this WG why 2440bis do not include
the same text, but I'm not sure there was consensus declared.

I'd be disappointed if IETF approved a standard that implied use of
PGP in e-mail in any other way than PGP/MIME.

If you are seriously proposing to make inline/partitioned a standard
scheme for PGP in e-mail, you should describe how it should be
implemented.  I have experience with the inline style, and
non-deployed experience with the "partitioned"-style.  The problems
that need to be addressed to make this a serious alternative is RFC
1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
in bodies and PGP headers), trailing white space interaction with
format=flowed, interaction with QP and '-' and '=' in the PGP armor.

> I'm not opposed to a 'supports' Header in the email headers.  I am most 
> concerned with strengthening the language on user preferences in the key self 
> signature, as I think lack of clarity has been a big problem.  

Agreed.  More clarity is needed.

> As an MUA implementor, I'm very concerned with the poor interoperability 
> caused by the current lack of clarity, so I want this strengthened for the 
> benefit of the users, who shouldn't need to worry too much about this if the 
> standard is clear.

Right.

If everyone implemented PGP/MIME we wouldn't have this problem.

I believe that standardizing inline/partitioned may turn out to be
more painful than implementing PGP/MIME.

To be clear: I'm not against the notation packet idea.  I think it is
a great idea.  But it shouldn't imply that the "partitioned" approach
is something which the IETF recommend.  It should be seen as a way to
smooth the upgrade path into PGP/MIME.

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GGQfgh015500; Sun, 16 Jan 2005 08:26:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GGQfI4015499; Sun, 16 Jan 2005 08:26:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GGQfrq015353 for <[e-mail]>; Sun, 16 Jan 2005 08:26:41 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <20050116162635016006ri6je>; Sun, 16 Jan 2005 16:26:35 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0GGQYff027540; Sun, 16 Jan 2005 11:26:35 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0GGQNPU024966; Sun, 16 Jan 2005 11:26:23 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0GGQNtf024965; Sun, 16 Jan 2005 11:26:23 -0500
Date: Sun, 16 Jan 2005 11:26:23 -0500
From: David Shaw <[e-mail]>
To: Ben Laurie <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
Message-ID: <[e-mail]>
Mail-Followup-To: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=0x99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sun, Jan 16, 2005 at 08:03:54AM +0000, Ben Laurie wrote:
> 
> David Shaw wrote:
> >On Sat, Jan 15, 2005 at 04:38:32PM -0500, David Shaw wrote:
> >
> >>On Sat, Jan 15, 2005 at 08:54:51PM +0000, Ben Laurie wrote:
> >>
> >>>3.2 (MPI) doesn't specify what the unused bits should be set to. This 
> >>>may be deliberate but I think it should either say they MUST be zero 
> >>>(which I prefer) or that their content is unspecified.
> >>
> >>I'm not completely sure what you are referring to here.  Do you mean
> >>the difference (given an MPI of value "1") between [00 01 01] and [00
> >>01 02] ?  The 0x02 bit of the 3rd octet?
> >
> >
> >Er, I meant [00 01 03], but the question still holds.  Are you
> >referring to the 0x02 bit of the last octet?
> 
> Yes.

I see.  I think that the draft does indirectly specify that the unused
bits are 0.  In section 3.2 it states "These octets form a big-endian
number; a big-endian number can be made into an MPI by prefixing it
with the appropriate length."  [00 01 03] would violate that
statement, since the big-endian number would be 3, rather than 1.

I certainly don't have any objection to making it more explicit than
that, though.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GGPEqI013671; Sun, 16 Jan 2005 08:25:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GGPEAq013670; Sun, 16 Jan 2005 08:25:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GGPEM2013374 for <[e-mail]>; Sun, 16 Jan 2005 08:25:14 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <200501161625060120010u6re>; Sun, 16 Jan 2005 16:25:06 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0GGP5ff027529 for <[e-mail]>; Sun, 16 Jan 2005 11:25:05 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0GGOriZ024954 for <[e-mail]>; Sun, 16 Jan 2005 11:24:53 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0GGOrZa024953 for [e-mail]; Sun, 16 Jan 2005 11:24:53 -0500
Date: Sun, 16 Jan 2005 11:24:53 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Notation packet for PGP/MIME ability
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=0x99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Jan 13, 2005 at 09:07:29AM -0800, "Hal Finney" wrote:
> 
> Regarding the location of the preferred email format notation packet, I
> should have made it clear that this is a subpacket in the self-signature
> on the userid.
> 
> As far as human-readability, it's true that it might be more convenient
> in terms of compatibility with existing code to use an array of numeric
> values.  But human readability has some advantages, too.  It allows
> notation packets to be displayed to users even when the software doesn't
> understand what they mean.  Utilities like pgpdump and gnupg's built-in
> dumper can probably already display this notation packet.  It doesn't
> help all that much for what we are doing in this particular case but it
> does add to the transparency and understandability of the overall system.

Note that pgpdump and GPG's dumper can display either human or machine
readable notations.

I do understand the desire for more transparency, but the "regular
user" is not going to examine a key packet-by-packet to determine
whether to send PGP/MIME or not.  They're going to let the system
handle such details for them.

Thinking about it some, one good reason to be human-readable is to
allow earlier versions of programs to partcipate in this.  GnuPG does
have a --cert-notation option which lets users set notations on key
signatures (including self-signatures), but this is not really
workable for this.  Once set, users cannot change such notations
without deleting and recreating the whole self signature (and then
item-by-item replacing the various preferences, feature flags, etc).
I forsee a lot of user confusion there, as the --cert-notation option
was never really designed for self-signatures and this kind of use.
GPG will need new code to allow users to set and unset this mail
preference in the way they'd expect - the way they can set and unset
all other preferences.

Since it needs new code anyway, I'd much rather be able to leverage
the existing preference code.  The standard has three preference
lists, all done the same way.  This would be the only different one.

I want to emphasize that I'm not arguing against the idea of a mail
encoding preference.  I think it's a excellent idea, and have argued
for it in the past.  I'd just much rather have a simple array of bytes
for speed and ease of both implementation and use.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GG4Ucw086858; Sun, 16 Jan 2005 08:04:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GG4UM4086857; Sun, 16 Jan 2005 08:04:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (IDENT:iHcbODyOST6Iy/[e-mail] [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GG4Tui086825 for <[e-mail]>; Sun, 16 Jan 2005 08:04:29 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.1.102] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.12.8/8.12.8) with ESMTP id j0GG4Sk0010903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 16 Jan 2005 10:04:29 -0600
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header
Date: Sun, 16 Jan 2005 10:04:28 -0600
User-Agent: KMail/1.7.2
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sunday 16 January 2005 09:38 am, Simon Josefsson wrote:
>> "Brian G. Peterson" <[e-mail]> writes:
>> I would very much like to see the approach that Jon and Hal have outlined
>> of putting the preference in a notation packet on the key self signature
>> be put into the RFC, and made official.
>>
>> This issue is extremely important, and the proposed solution is well
>> thought out, and easy to understand and implement.  Lack of guidance on
>> this issue in the standard has already led to unnecessary
>> incompatibilities between mail implementations.  Let's get that resolved
>> with the new standard.
>
> I agree completely.
>
> The OpenPGP: header does not yet include a "supports" token, so this
> is an open issue.  I wasn't aware of Jon and Hal's proposal when I
> mentioned "supports" as an open question, nor when we discussed this
> problem with MUA implementors earlier.
>
> Perhaps we can get some input on the viability of a "supports"-token
> in the OpenPGP-header by resolving the following question:

My concern with a 'supports' token is that this is probably/potentially 
controlled by the MUA, not the user.  This may (already has?) provide a 
loophole to MUA implementations that don't want to support 
inline/partitioned.  I'm very much in support of a user preference notation 
packet, because this puts the control in the hands of the key holder, and 
implies that MUA's SHOULD (RFC language intentional here) support partitioned 
and mime.

> Will the proposed notation packet scheme be sufficient to tell whether
> MUAs should use PGP/MIME, plaintext PGP, or the "partitioned" scheme,
> in every situation that MUA users care about?
>
> For encryption, the question seems clear.  You need the key to
> encrypt, and the notation packet tell you which PGP-in-mail style to
> use.
>
> For signing, the answer is not so clear to me.  
<...>
> In theory, for signing, you might not even know who the recipients 
> are, so you can't inspect a notation packet.  But you may be 
> sending mail to a mailing list that require signed messages, 
> that add 'OpenPGP: supports=mime' to all posts to signal what 
> kind of PGP-style to use. 
>
> Fundamentally, what I'm asking is whether the notation packet solve
> all problems that a "supports"-tokens in the OpenPGP: header would.
>
> If it does, then I don't think we shouldn't have a "supports"-token.
>
> If it doesn't, then I don't see what harm it would cause by adding it,
> and I'd probably would support adding it.

I'm not opposed to a 'supports' Header in the email headers.  I am most 
concerned with strengthening the language on user preferences in the key self 
signature, as I think lack of clarity has been a big problem.  

The proposed 'supports' email header provides guidance on what the receiving 
MUA wants, the user preference provides guidance on what the user wants, and 
the sending MUA should follow the user preference.  The receiving MUA should 
be flexible enough to handle either the inline/partitioned or mime formats 
for both sending and receiving.  

As an MUA implementor, I'm very concerned with the poor interoperability 
caused by the current lack of clarity, so I want this strengthened for the 
benefit of the users, who shouldn't need to worry too much about this if the 
standard is clear.

Regards,

  - Brian



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GFdEfB050863; Sun, 16 Jan 2005 07:39:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GFdEBD050862; Sun, 16 Jan 2005 07:39:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GFd8mc050272 for <[e-mail]>; Sun, 16 Jan 2005 07:39:13 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0GFcrE7030180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sun, 16 Jan 2005 16:38:54 +0100
From: Simon Josefsson <[e-mail]>
To: "Brian G. Peterson" <[e-mail]>
Cc: [e-mail]
Subject: Re: OpenPGP mail/news header
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050116:[e-mail]::JhqFkd7vi4xnF8UE:2S/p
X-Hashcash: 1:21:050116:[e-mail]::kO92tKYTL+2+3SWW:DeaP
Date: Sun, 16 Jan 2005 16:38:43 +0100
In-Reply-To: <[e-mail]> (Brian G. Peterson's message of "Sun, 16 Jan 2005 08:14:54 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"Brian G. Peterson" <[e-mail]> writes:

> On Sunday 16 January 2005 05:04 am, Simon Josefsson wrote:
>> Jon Callas <[e-mail]> writes:
>> > * I think the other open question you have, as to whether someone wants
>> > MIME encodings or not is much more important. At PGP, we're starting to
>> > code that into the certificates themselves, so the encryption mechanism
>> > can do the right thing.
>>
>> I realize it is a big issue, and potentially a contentious one.
>>
>> I'd hate to see disagreement on this part stop the document, though,
>> so if consensus on this matter cannot be reached, I think we should
>> simply drop it.
>
> I would very much like to see the approach that Jon and Hal have outlined of 
> putting the preference in a notation packet on the key self signature be put 
> into the RFC, and made official.
>
> This issue is extremely important, and the proposed solution is well thought 
> out, and easy to understand and implement.  Lack of guidance on this issue in 
> the standard has already led to unnecessary incompatibilities between mail 
> implementations.  Let's get that resolved with the new standard.

I agree completely.

The OpenPGP: header does not yet include a "supports" token, so this
is an open issue.  I wasn't aware of Jon and Hal's proposal when I
mentioned "supports" as an open question, nor when we discussed this
problem with MUA implementors earlier.

Perhaps we can get some input on the viability of a "supports"-token
in the OpenPGP-header by resolving the following question:

Will the proposed notation packet scheme be sufficient to tell whether
MUAs should use PGP/MIME, plaintext PGP, or the "partitioned" scheme,
in every situation that MUA users care about?

For encryption, the question seems clear.  You need the key to
encrypt, and the notation packet tell you which PGP-in-mail style to
use.

For signing, the answer is not so clear to me.  I'm not sure there are
no situations where you want to send signed mail, but doesn't posses,
or care about, the recipients keys, but do wish to follow a loose
recommendation on which PGP-in-mail style to use.  In theory, for
signing, you might not even know who the recipients are, so you can't
inspect a notation packet.  But you may be sending mail to a mailing
list that require signed messages, that add 'OpenPGP: supports=mime'
to all posts to signal what kind of PGP-style to use.

Fundamentally, what I'm asking is whether the notation packet solve
all problems that a "supports"-tokens in the OpenPGP: header would.

If it does, then I don't think we shouldn't have a "supports"-token.

If it doesn't, then I don't see what harm it would cause by adding it,
and I'd probably would support adding it.

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GEWomX055994; Sun, 16 Jan 2005 06:32:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GEWoIm055993; Sun, 16 Jan 2005 06:32:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GEWnZx055953 for <[e-mail]>; Sun, 16 Jan 2005 06:32:49 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1DA6233C45 for <[e-mail]>; Sun, 16 Jan 2005 14:32:49 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sun, 16 Jan 2005 14:32:50 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: draft-ietf-openpgp-rfc2440bis-12 5.2.3
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

5.2.3 refers to two groups of subpackets, each of which is preceded by a 
two byte count. 5.2.3.1 then says:

    The subpacket fields consist of zero or more signature subpackets.
    Each set of subpackets is preceded by a two-octet scalar count of
    the length of the set of subpackets.

I assume this count is the same count as referred to in 5.2.3, but it is 
unclear (at least to me). Perhaps it would be better if instead of:

      - Two-octet scalar octet count for following hashed subpacket
        data. Note that this is the length in octets of all of the
        hashed subpackets; a pointer incremented by this number will
        skip over the hashed subpackets.

      - Hashed subpacket data. (zero or more subpackets)

      - Two-octet scalar octet count for following unhashed subpacket
        data. Note that this is the length in octets of all of the
        unhashed subpackets; a pointer incremented by this number will
        skip over the unhashed subpackets.

      - Unhashed subpacket data. (zero or more subpackets)

in 5.2.3, there was:

      - Hashed subpacket data set.

      - Unhashed subpacket data set.

and in 5.2.3.1:

A subpacket data set consists of zero or more signature subpackets, 
preceded by a two-octet scalar count of the length in octets of all the 
subpackets; a pointer incremented by this number will skip over the 
subpacket data set.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GEExih032380; Sun, 16 Jan 2005 06:14:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GEExUj032379; Sun, 16 Jan 2005 06:14:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (IDENT:1cd9KfwG+99hYPfsL/[e-mail] [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GEEwZQ032371 for <[e-mail]>; Sun, 16 Jan 2005 06:14:58 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.1.102] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.12.8/8.12.8) with ESMTP id j0GEEtk0009569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 16 Jan 2005 08:14:55 -0600
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP mail/news header
Date: Sun, 16 Jan 2005 08:14:54 -0600
User-Agent: KMail/1.7.2
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sunday 16 January 2005 05:04 am, Simon Josefsson wrote:
> Jon Callas <[e-mail]> writes:
> > * I think the other open question you have, as to whether someone wants
> > MIME encodings or not is much more important. At PGP, we're starting to
> > code that into the certificates themselves, so the encryption mechanism
> > can do the right thing.
>
> I realize it is a big issue, and potentially a contentious one.
>
> I'd hate to see disagreement on this part stop the document, though,
> so if consensus on this matter cannot be reached, I think we should
> simply drop it.

I would very much like to see the approach that Jon and Hal have outlined of 
putting the preference in a notation packet on the key self signature be put 
into the RFC, and made official.

This issue is extremely important, and the proposed solution is well thought 
out, and easy to understand and implement.  Lack of guidance on this issue in 
the standard has already led to unnecessary incompatibilities between mail 
implementations.  Let's get that resolved with the new standard.

Regards,

  - Brian



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GB5IAf058473; Sun, 16 Jan 2005 03:05:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0GB5IBD058472; Sun, 16 Jan 2005 03:05:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0GB5BIg058381 for <[e-mail]>; Sun, 16 Jan 2005 03:05:17 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0GB4lxh017452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sun, 16 Jan 2005 12:04:48 +0100
From: Simon Josefsson <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail], atom <[e-mail]>
Subject: Re: OpenPGP mail/news header
References: <[e-mail]> <[e-mail]>
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050116:[e-mail]::ohnaFPRc3M4aJgIr:25nn
X-Hashcash: 1:21:050116:[e-mail]::5RESmUskEYgiZUq6:1Tkh
X-Hashcash: 1:21:050116:[e-mail]::cZDO2wdTZ8XLY8ff:Dhff
Date: Sun, 16 Jan 2005 12:04:37 +0100
In-Reply-To: <[e-mail]> (Jon Callas's message of "Tue, 11 Jan 2005 16:29:00 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> writes:

> I have some comments:

Thanks for looking at it!

> * We're deprecating V3 keys.  You should either not mention them, or
> mention that they're deprecated.

What would a suitable reference for that decision be?

> On the other hand, you could just punt the whole issue by allowing a 
> fingerprint to just be a string of hex digits. The length tells you 
> what you need to know. If it's 128 bits in length, it's a V3 key; 160 
> means V4. Even key ids are implicit based on length. (And with V4 keys, 
> the key id is just a truncation of the fingerprint.)

This seems like a good solution.  Will there ever be a need to have
key id's of different length than 4, 8, 16 and 20 bytes?  The BNF now
reads:

id        := 4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG

And I'm not certain it is a good idea to allow the flexibility of

id        := *HEXDIG

However, I have replaced the references to v3/v4 with:

   The length of the field imply the kind of key id, i.e., short or
   long form, or a v3 or v4 key.

   Note that each of the following examples includes a comment, which is
   optional.

   	    id=12345678 (short key ID)
   	    id=1234567890ABCDEF (long key ID)
   	    id=1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
   	    id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)

> * I also don't think you need the 0x. Just define it to be hexadecimal. 
> The breaker is needed to know that literals in a programming language 
> are of one base or another. Key IDs and fingerprints come in only one 
> base. I know it's a MAY. Drop it anyway, because if it's there, an 
> implementation has to handle both its presence and absence. It's merely 
> noise.

I agree, I've dropped it.

> * I understand why you have the url header, and think it's nice. But 
> once you have that, (or the key is uniquely identified by key id or 
> fingerprint) you don't need the algorithm, size, and created fields. 
> These are merely comments all on their own, and if you have them there, 
> you have to deal with what happens if they are wrong.
>
> Let's suppose a URL points to my key and the header erroneously states 
> that it's a DSA key, when it is in fact an RSA key. Now what? What if 
> the creation time in the header is wrong? Since all that information is 
> in the key itself, better to just get it from the key.
>
> So to answer the question in section 6, I think you should drop them.

Thanks for this input.  I have been trying to understand why
algo/size/created are needed, but nobody has been able to explain it
to me.

The reason was supposedly that with v3 keys, you subject to something
called the 0xDEADBEEF attack, where I infer that keys can be created
easily with any given key id.  The attack is not possible with v4
keys.  Someone said the attack is harder for v3 keys if you also
compare the key size, key algorithm and creation time.

What nobody has explained to me is how much difficult the attack is.
If the attack is only slightly more difficult, I don't think it is
worth the added complexity in OpenPGP:.  However, if the attack is
completely avoided by comparing these fields, there may be some point
to it.  On the other hand, if v3 keys are deprecated, it might be
simpler to forget about all v3 issues.

Without understanding the motivation for size/algo/created, I'm in
favor of dropping them.

> * I think the other open question you have, as to whether someone wants 
> MIME encodings or not is much more important. At PGP, we're starting to 
> code that into the certificates themselves, so the encryption mechanism 
> can do the right thing.

I realize it is a big issue, and potentially a contentious one.

I'd hate to see disagreement on this part stop the document, though,
so if consensus on this matter cannot be reached, I think we should
simply drop it.

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0G83tEt082726; Sun, 16 Jan 2005 00:03:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0G83tSR082725; Sun, 16 Jan 2005 00:03:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0G83sS1082711 for <[e-mail]>; Sun, 16 Jan 2005 00:03:54 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 10BA133C33; Sun, 16 Jan 2005 08:03:53 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sun, 16 Jan 2005 08:03:54 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw wrote:
> On Sat, Jan 15, 2005 at 04:38:32PM -0500, David Shaw wrote:
> 
>>On Sat, Jan 15, 2005 at 08:54:51PM +0000, Ben Laurie wrote:
>>
>>>3.2 (MPI) doesn't specify what the unused bits should be set to. This 
>>>may be deliberate but I think it should either say they MUST be zero 
>>>(which I prefer) or that their content is unspecified.
>>
>>I'm not completely sure what you are referring to here.  Do you mean
>>the difference (given an MPI of value "1") between [00 01 01] and [00
>>01 02] ?  The 0x02 bit of the 3rd octet?
> 
> 
> Er, I meant [00 01 03], but the question still holds.  Are you
> referring to the 0x02 bit of the last octet?

Yes.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FLvTkx043769; Sat, 15 Jan 2005 13:57:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0FLvT8e043768; Sat, 15 Jan 2005 13:57:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FLvShu043754 for <[e-mail]>; Sat, 15 Jan 2005 13:57:28 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <20050115215722013009a9tae>; Sat, 15 Jan 2005 21:57:22 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0FLvLff015739 for <[e-mail]>; Sat, 15 Jan 2005 16:57:22 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0FLvCwO023332 for <[e-mail]>; Sat, 15 Jan 2005 16:57:12 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0FLvC4p023331 for [e-mail]; Sat, 15 Jan 2005 16:57:12 -0500
Date: Sat, 15 Jan 2005 16:57:12 -0500
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=0x99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Jan 15, 2005 at 04:38:32PM -0500, David Shaw wrote:
> On Sat, Jan 15, 2005 at 08:54:51PM +0000, Ben Laurie wrote:
> > 
> > 3.2 (MPI) doesn't specify what the unused bits should be set to. This 
> > may be deliberate but I think it should either say they MUST be zero 
> > (which I prefer) or that their content is unspecified.
> 
> I'm not completely sure what you are referring to here.  Do you mean
> the difference (given an MPI of value "1") between [00 01 01] and [00
> 01 02] ?  The 0x02 bit of the 3rd octet?

Er, I meant [00 01 03], but the question still holds.  Are you
referring to the 0x02 bit of the last octet?

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FLcm7v027067; Sat, 15 Jan 2005 13:38:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0FLcm4M027065; Sat, 15 Jan 2005 13:38:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FLclYl026971 for <[e-mail]>; Sat, 15 Jan 2005 13:38:47 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <20050115213842016006qfjke>; Sat, 15 Jan 2005 21:38:42 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0FLcfff015641 for <[e-mail]>; Sat, 15 Jan 2005 16:38:41 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0FLcWVJ023243 for <[e-mail]>; Sat, 15 Jan 2005 16:38:32 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0FLcW0C023242 for [e-mail]; Sat, 15 Jan 2005 16:38:32 -0500
Date: Sat, 15 Jan 2005 16:38:32 -0500
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=0x99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Jan 15, 2005 at 08:54:51PM +0000, Ben Laurie wrote:
> 
> 3.2 (MPI) doesn't specify what the unused bits should be set to. This 
> may be deliberate but I think it should either say they MUST be zero 
> (which I prefer) or that their content is unspecified.

I'm not completely sure what you are referring to here.  Do you mean
the difference (given an MPI of value "1") between [00 01 01] and [00
01 02] ?  The 0x02 bit of the 3rd octet?

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FKt3wL064789; Sat, 15 Jan 2005 12:55:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0FKt3l3064788; Sat, 15 Jan 2005 12:55:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0FKt1EI064370 for <[e-mail]>; Sat, 15 Jan 2005 12:55:02 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C45C333C33 for <[e-mail]>; Sat, 15 Jan 2005 20:54:50 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Sat, 15 Jan 2005 20:54:51 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: Comments on draft-ietf-openpgp-rfc2440bis-12
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

3.2 (MPI) doesn't specify what the unused bits should be set to. This 
may be deliberate but I think it should either say they MUST be zero 
(which I prefer) or that their content is unspecified.

4.2 refers to Content Tags, but 4.3 calls them Packet Tags.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0EKpAeX047709; Fri, 14 Jan 2005 12:51:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0EKpABr047708; Fri, 14 Jan 2005 12:51:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from is3smtp04.cec.eu.int (is3smtp04.cec.eu.int [147.67.3.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0EKp5eC047581 for <[e-mail]>; Fri, 14 Jan 2005 12:51:10 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by is3smtp04.cec.eu.int with Microsoft SMTPSVC; Fri, 14 Jan 2005 21:45:44 +0100
Received: from above.proper.com ([208.184.76.39]) by is3smtp03.cec.eu.int with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Jan 2005 19:34:54 +0100
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DIPIHn063603; Thu, 13 Jan 2005 10:25:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DIPIjC063602; Thu, 13 Jan 2005 10:25:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spam1.wiktel.com (spam1.wiktel.com [204.221.145.252]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DIPHSW063554 for <[e-mail]>; Thu, 13 Jan 2005 10:25:17 -0800 (PST) (envelope-from [e-mail])
Received: from 944dh51.umcrookston.edu ([146.57.174.55]) (authenticated bits=0) by spam1.wiktel.com (8.13.1/8.13.1) with ESMTP id j0DIP3QY030702 for <[e-mail]>; Thu, 13 Jan 2005 12:25:05 -0600
Subject: Re: Notation packet for PGP/MIME ability
From: Richard Laager <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p3+LjLvVjxcs14u39p4R"
Organization: Wikstrom Telecom Internet
Date: Thu, 13 Jan 2005 12:25:05 -0600
Message-Id: <1105640705.3616.1.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
X-bounce-key: wiktel.com-1;[e-mail];1105640706;LNvncfXU0yrkuaXVmjRtq8XlPp8;
X-Scanned-By: MIMEDefang 2.49 on 204.221.145.252
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-OriginalArrivalTime: 13 Jan 2005 18:34:54.0953 (UTC) FILETIME=[93974590:01C4F99E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-p3+LjLvVjxcs14u39p4R
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-01-13 at 00:01 -0800, "Hal Finney" wrote:
>     Value: pgpmime,partitioned
>=20
> This would mean that the key holder can handle both PGP/MIME and
> partitioned formats, but that he prefers to receive PGP/MIME.
>=20
> If in the future a new PGP email format becomes popular then it is
> possible that new keywords could appear in the value field.  It is
> recommended that software ignore any keywords which it does not recognize
> and make its format choice based on the keywords that it understands.

I'd like to suggest "inline" as an option (for Outlook users, among
others) as well.

Richard Laager


--=-p3+LjLvVjxcs14u39p4R
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBB5r0BbfU6uV4fG84RArycAKCtUhnPjvQdjAUAV/efaJpVwC+gxgCZAaTk
sgxm4KTyRLVZIL7Ipz/poxo=
=qc5x
-----END PGP SIGNATURE-----

--=-p3+LjLvVjxcs14u39p4R--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DNa5HL073786; Thu, 13 Jan 2005 15:36:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DNa5nb073785; Thu, 13 Jan 2005 15:36:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cyphers.net (mail.cyphers.net [64.220.173.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DNa4rR073712 for <[e-mail]>; Thu, 13 Jan 2005 15:36:04 -0800 (PST) (envelope-from [e-mail])
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail.cyphers.net
X-Spam-Status: No, score=-0.4 required=2.9 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS autolearn=no version=3.0.2
X-TFF-CGPSA-Version: 1.4a3
X-TFF-CGPSA-Filter: Scanned
Received: from [66.236.113.186] (account wprice HELO dyn-2-76.pgp.com) by cyphers.net (CommuniGate Pro SMTP 4.2.4) with ESMTP-TLS id 2627538 for [e-mail]; Thu, 13 Jan 2005 15:35:59 -0800
Received: from [192.168.2.76] by dyn-2-76.pgp.com (PGP Universal service); Thu, 13 Jan 2005 15:35:58 -0800
X-PGP-Universal: processed; by dyn-2-76.pgp.com on Thu, 13 Jan 2005 15:35:58 -0800
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <1105640705.3616.1.camel@localhost>
References: <[e-mail]> <1105640705.3616.1.camel@localhost>
Message-Id: <[e-mail]>
From: William Price <[e-mail]>
Subject: Re: Notation packet for PGP/MIME ability
Date: Thu, 13 Jan 2005 15:35:55 -0800
To: [e-mail]
X-Mailer: Apple Mail (2.619)
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 13, 2005, at 10:25 AM, Richard Laager wrote:
> On Thu, 2005-01-13 at 00:01 -0800, "Hal Finney" wrote:
>>     Value: pgpmime,partitioned
>>
>> This would mean that the key holder can handle both PGP/MIME and
>> partitioned formats, but that he prefers to receive PGP/MIME.
>>
>> If in the future a new PGP email format becomes popular then it is
>> possible that new keywords could appear in the value field.  It is
>> recommended that software ignore any keywords which it does not 
>> recognize
>> and make its format choice based on the keywords that it understands.
>
> I'd like to suggest "inline" as an option (for Outlook users, among
> others) as well.

Inline is a subset of partitioned. Partitioned is basically another 
word for "use smart ad-hoc encryption of each MIME part into an 
encrypted MIME part -- message bodies get inline encrypted, attachments 
get file-encrypted." More or less, and generally in no particular 
standard ways, this is what most implementations have been doing for 14 
years. At some point, it would be worth writing up a definition of how 
we're handling all the little cases that come up in the real world for 
partitioned encoding, but the one golden rule of partitioned encoding 
is full backwards compatibility and thus technically it should not 
matter.

- --
Will Price, VP Engineering
PGP Corporation


-----BEGIN PGP SIGNATURE-----
Version: 1500

iQA/AwUBQecF3qy7FkvPc+xMEQJU9wCdGpiZvoyo/+cSPLCUEiQEUZaxl6oAoK0k
/RLseOLo71iSLAf/uE9A5hS7
=a6q2
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DIPIHn063603; Thu, 13 Jan 2005 10:25:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DIPIjC063602; Thu, 13 Jan 2005 10:25:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spam1.wiktel.com (spam1.wiktel.com [204.221.145.252]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DIPHSW063554 for <[e-mail]>; Thu, 13 Jan 2005 10:25:17 -0800 (PST) (envelope-from [e-mail])
Received: from 944dh51.umcrookston.edu ([146.57.174.55]) (authenticated bits=0) by spam1.wiktel.com (8.13.1/8.13.1) with ESMTP id j0DIP3QY030702 for <[e-mail]>; Thu, 13 Jan 2005 12:25:05 -0600
Subject: Re: Notation packet for PGP/MIME ability
From: Richard Laager <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p3+LjLvVjxcs14u39p4R"
Organization: Wikstrom Telecom Internet
Date: Thu, 13 Jan 2005 12:25:05 -0600
Message-Id: <1105640705.3616.1.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-3) 
X-bounce-key: wiktel.com-1;[e-mail];1105640706;LNvncfXU0yrkuaXVmjRtq8XlPp8;
X-Scanned-By: MIMEDefang 2.49 on 204.221.145.252
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-p3+LjLvVjxcs14u39p4R
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-01-13 at 00:01 -0800, "Hal Finney" wrote:
>     Value: pgpmime,partitioned
>=20
> This would mean that the key holder can handle both PGP/MIME and
> partitioned formats, but that he prefers to receive PGP/MIME.
>=20
> If in the future a new PGP email format becomes popular then it is
> possible that new keywords could appear in the value field.  It is
> recommended that software ignore any keywords which it does not recognize
> and make its format choice based on the keywords that it understands.

I'd like to suggest "inline" as an option (for Outlook users, among
others) as well.

Richard Laager


--=-p3+LjLvVjxcs14u39p4R
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBB5r0BbfU6uV4fG84RArycAKCtUhnPjvQdjAUAV/efaJpVwC+gxgCZAaTk
sgxm4KTyRLVZIL7Ipz/poxo=
=qc5x
-----END PGP SIGNATURE-----

--=-p3+LjLvVjxcs14u39p4R--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DGqj5o015924; Thu, 13 Jan 2005 08:52:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DGqjsF015923; Thu, 13 Jan 2005 08:52:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DGqj8w015891 for <[e-mail]>; Thu, 13 Jan 2005 08:52:45 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 262FC57E2C; Thu, 13 Jan 2005 09:07:29 -0800 (PST)
To: [e-mail]
Subject: Re: Notation packet for PGP/MIME ability
Message-Id: <[e-mail]>
Date: Thu, 13 Jan 2005 09:07:29 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Regarding the location of the preferred email format notation packet, I
should have made it clear that this is a subpacket in the self-signature
on the userid.

As far as human-readability, it's true that it might be more convenient
in terms of compatibility with existing code to use an array of numeric
values.  But human readability has some advantages, too.  It allows
notation packets to be displayed to users even when the software doesn't
understand what they mean.  Utilities like pgpdump and gnupg's built-in
dumper can probably already display this notation packet.  It doesn't
help all that much for what we are doing in this particular case but it
does add to the transparency and understandability of the overall system.
Going forward I suggest that it would be better to have notation packets
generally be human readable where possible.

Hal Finney



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DEiWKk013053; Thu, 13 Jan 2005 06:44:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DEiWkN013052; Thu, 13 Jan 2005 06:44:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DEiVg0012943 for <[e-mail]>; Thu, 13 Jan 2005 06:44:31 -0800 (PST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1Cp5kL-000797-MS for <[e-mail]>; Thu, 13 Jan 2005 15:14:45 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1Cp6Di-0000pY-1y; Thu, 13 Jan 2005 15:45:06 +0100
To: "Brian G. Peterson" <[e-mail]>
Cc: [e-mail]
Subject: Re: Notation packet for PGP/MIME ability
References: <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Thu, 13 Jan 2005 15:45:06 +0100
In-Reply-To: <[e-mail]> (Brian G. Peterson's message of "Thu, 13 Jan 2005 07:55:58 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 13 Jan 2005 07:55:58 -0600, Brian G Peterson said:

> For context, I work on the OpenPGP implementation for Squirrelmail, an open 
> source mail client.  Our implementation uses GnuPG 'underneath' to do the 
> encryption.  I only see support in gpg for adding/examining notation packets 
> on *signature* data, not notations on *keys*.

Use --show-sig-subpacket --with-colons and you get all the
subpackets.  Grepping for the relevant notation data is the easy.

--sig-notation and --cert-notation may be used to set notation data.


In general I think it is better to fix Outlook than to find ways to
work around it.  Maybe the EU decision is of help here.


Shalom-Salam,

   Werner



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DER9op000967; Thu, 13 Jan 2005 06:27:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DER9qt000966; Thu, 13 Jan 2005 06:27:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DER8BX000755 for <[e-mail]>; Thu, 13 Jan 2005 06:27:09 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <20050113142705011000djf3e>; Thu, 13 Jan 2005 14:27:05 +0000
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j0DER1ff003858 for <[e-mail]>; Thu, 13 Jan 2005 09:27:01 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j0DEQwr2029969 for <[e-mail]>; Thu, 13 Jan 2005 09:26:58 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j0DEQwuU029968 for [e-mail]; Thu, 13 Jan 2005 09:26:58 -0500
Date: Thu, 13 Jan 2005 09:26:58 -0500
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Notation packet for PGP/MIME ability
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=0x99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Jan 13, 2005 at 12:01:19AM -0800, "Hal Finney" wrote:

> The new notation packet will allow key holders to specify whether
> they prefer to receive email in PGP/MIME format or in this other
> format, which we call "partitioned".  Here is the format of the
> notation packet.

I think this is an excellent idea, and I'm very pleased to see it
happening.

One question that comes to mind is why is this human readable?  It's
going to be written by software and read by software.  To be sure, a
machine can read and parse it anyway, but it seems like a needless
extra step.

It strikes me that this is really another preference list like the
cipher/hash/compression preferences.  Most every implementation has
code to parse preference lists, and if this notation was a
non-human-readable array of bytes like the others then the same code
could parse them all.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DENG58096133; Thu, 13 Jan 2005 06:23:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DENGQG096132; Thu, 13 Jan 2005 06:23:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from branwen.iks-jena.de ([e-mail] [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DENFoO096018 for <[e-mail]>; Thu, 13 Jan 2005 06:23:15 -0800 (PST) (envelope-from [e-mail])
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.1/8.13.1) with ESMTP id j0DEN7oa009942 for <[e-mail]>; Thu, 13 Jan 2005 15:23:09 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.1/8.13.1/Submit) id j0DEN7RI009941 for [e-mail]; Thu, 13 Jan 2005 15:23:07 +0100
To: [e-mail]
Path: not-for-mail
From: Lutz Donnerhacke <[e-mail]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Notation packet for PGP/MIME ability
Date: Thu, 13 Jan 2005 14:23:07 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 7
Message-ID:  <[e-mail]>
References:  <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1105626187 9271 217.17.192.37 (13 Jan 2005 14:23:07 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Thu, 13 Jan 2005 14:23:07 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

* Brian G. Peterson wrote:
> You describe adding a notation packet to a *key*.

No, he wrote "key holder". This packet is most useful on User IDs aka
emails, because different email accounts tend to terminate on different
systems. So the transport encoding should be selectable to support each
target system separately.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DDtwbw065581; Thu, 13 Jan 2005 05:55:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DDtwQf065579; Thu, 13 Jan 2005 05:55:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (IDENT:[e-mail] [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DDtvqB065562 for <[e-mail]>; Thu, 13 Jan 2005 05:55:57 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.1.102] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.12.8/8.12.8) with ESMTP id j0DDtwk0024631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 13 Jan 2005 07:55:59 -0600
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: Notation packet for PGP/MIME ability
Date: Thu, 13 Jan 2005 07:55:58 -0600
User-Agent: KMail/1.7.2
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thursday 13 January 2005 02:01 am, "Hal Finney" wrote:
> At PGP Corporation we are planning on adding a notation packet to newly
> generated keys.  It is intended to let key holders indicate whether they
> can receive PGP/MIME email, or an alternate format used by PGP, or both.
<... snip ...>
> An example preferred-email-encoding notation packet will have the
> following fields:
>
>     Flags: 0x80, 0x00, 0x00, 0x00
>
>     Name: [e-mail]
>
>     Value: pgpmime,partitioned
>
> This would mean that the key holder can handle both PGP/MIME and
> partitioned formats, but that he prefers to receive PGP/MIME.

I think that this is a great idea.  This kind of preference support is a 
critical feature for one of the most used applications of OpenPGP.

Hal, 
You describe adding a notation packet to a *key*.  Section 5.2.3.16. "Notation 
Data" describes only notation packets on a *signature* 

  "This subpacket describes a "notation" on the signature that the
   issuer wishes to make. The notation has a name and a value, each of
   which are strings of octets. There may be more than one notation in
   a signature. Notations can be used for any extension the issuer of
   the signature cares to make."

Can you please clarify?  Is your packet on the signature, or the key?

For context, I work on the OpenPGP implementation for Squirrelmail, an open 
source mail client.  Our implementation uses GnuPG 'underneath' to do the 
encryption.  I only see support in gpg for adding/examining notation packets 
on *signature* data, not notations on *keys*.

We'll certainly implement the functionality that Hal describes, if gpg 
supports setting and extracting the notation packet required.  From what I 
can tell, this will require setting/checking the notation packet on the 
signature of the message.

I spoke up on the issues around PGP/MIME on this list several times in the 
past.  I wish that this kind of standardization would show up *in the RFC*, 
as I've previously indicated.

Hal, thanks again for the detailed message and any clarifying response.
 
Regards,

  - Brian



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D7kd50089057; Wed, 12 Jan 2005 23:46:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0D7kd7w089056; Wed, 12 Jan 2005 23:46:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0D7kdEr088981 for <[e-mail]>; Wed, 12 Jan 2005 23:46:39 -0800 (PST) (envelope-from [e-mail])
Received: by finney.org (Postfix, from userid 500) id 6566557E2B; Thu, 13 Jan 2005 00:01:19 -0800 (PST)
To: [e-mail]
Subject: Notation packet for PGP/MIME ability
Message-Id: <[e-mail]>
Date: Thu, 13 Jan 2005 00:01:19 -0800 (PST)
From: [e-mail] ("Hal Finney")
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At PGP Corporation we are planning on adding a notation packet to newly
generated keys.  It is intended to let key holders indicate whether they
can receive PGP/MIME email, or an alternate format used by PGP, or both.

Although PGP/MIME provides a powerful and flexible mechanism for
dealing with multiparts, some mail processing software does not lend
itself to automating PGP processing of MIME messages.  As a result we
have implemented alternatives which use RFC2440 PGP message formats
(non-PGP/MIME).  For non-multipart messages, this involves simply
processing the message body per RFC 2440.  For multiparts, we process
each message part and attachment separately, applying the appropriate
cryptographic transformations for privacy and authenticity to each
part, while retaining the overall structure of the message.

The new notation packet will allow key holders to specify whether they
prefer to receive email in PGP/MIME format or in this other format,
which we call "partitioned".  Here is the format of the notation packet.

The notation packet does not have the critical bit set.

The flags field of the notation packet will have the human-readable bit
set, which is 0x80 in the first octet of the four octet flags field.

The name field of the notation packet will be
"[e-mail]".  This follows the RFC2440bis naming
convention for a "private" name in the namespace assocated with pgp.com.

The value field of the notation packet will be a single instance, or
a comma separated list, of the keywords: "pgpmime" and "partitioned".
If there is a single item, that is the format the key holder wants
to receive in; if there are multiple items, he can handle all (both)
formats and they are listed in order of preference.

An example preferred-email-encoding notation packet will have the
following fields:

    Flags: 0x80, 0x00, 0x00, 0x00

    Name: [e-mail]

    Value: pgpmime,partitioned

This would mean that the key holder can handle both PGP/MIME and
partitioned formats, but that he prefers to receive PGP/MIME.

If in the future a new PGP email format becomes popular then it is
possible that new keywords could appear in the value field.  It is
recommended that software ignore any keywords which it does not recognize
and make its format choice based on the keywords that it understands.

I will be happy to answer any questions about this new notation packet.

Hal Finney
PGP Corporation
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0C0Uf93087809; Tue, 11 Jan 2005 16:30:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0C0Uf0S087808; Tue, 11 Jan 2005 16:30:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0C0UcCT087771 for <[e-mail]>; Tue, 11 Jan 2005 16:30:38 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.5); Tue, 11 Jan 2005 16:30:38 -0800
Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Jan 2005 16:30:36 -0800
X-PGP-Universal: processed
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail], atom <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: OpenPGP mail/news header
Date: Tue, 11 Jan 2005 16:29:00 -0800
To: Simon Josefsson <[e-mail]>
X-Mailer: Apple Mail (2.619)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I have some comments:

* We're deprecating V3 keys. You should either not mention them, or 
mention that they're deprecated.

On the other hand, you could just punt the whole issue by allowing a 
fingerprint to just be a string of hex digits. The length tells you 
what you need to know. If it's 128 bits in length, it's a V3 key; 160 
means V4. Even key ids are implicit based on length. (And with V4 keys, 
the key id is just a truncation of the fingerprint.)

* I also don't think you need the 0x. Just define it to be hexadecimal. 
The breaker is needed to know that literals in a programming language 
are of one base or another. Key IDs and fingerprints come in only one 
base. I know it's a MAY. Drop it anyway, because if it's there, an 
implementation has to handle both its presence and absence. It's merely 
noise.

* I understand why you have the url header, and think it's nice. But 
once you have that, (or the key is uniquely identified by key id or 
fingerprint) you don't need the algorithm, size, and created fields. 
These are merely comments all on their own, and if you have them there, 
you have to deal with what happens if they are wrong.

Let's suppose a URL points to my key and the header erroneously states 
that it's a DSA key, when it is in fact an RSA key. Now what? What if 
the creation time in the header is wrong? Since all that information is 
in the key itself, better to just get it from the key.

So to answer the question in section 6, I think you should drop them.

* I think the other open question you have, as to whether someone wants 
MIME encodings or not is much more important. At PGP, we're starting to 
code that into the certificates themselves, so the encryption mechanism 
can do the right thing.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07N8ja4042907; Fri, 7 Jan 2005 15:08:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j07N8j0k042906; Fri, 7 Jan 2005 15:08:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07N8dPX042631 for <[e-mail]>; Fri, 7 Jan 2005 15:08:44 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j07N8X2H030789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Sat, 8 Jan 2005 00:08:34 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Cc: atom <[e-mail]>
Subject: OpenPGP mail/news header
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:23:050107:[e-mail]::QqJhYFBvNGbZ5GOI:00000000000000000000000000000000000000000byDt
X-Hashcash: 1:23:050107:[e-mail]::pFrCxqiMUynEQFlI:000000000000000000000000000000000000000000jOMo
Date: Sat, 08 Jan 2005 00:08:28 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: ClamAV 0.80/618/Mon Dec  6 00:09:24 2004 clamav-milter version 0.80j on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hello.

Atom and I would appreciate your thoughts on the following document.

http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-00.txt

For a few references to earlier discussions on this proposal, see:

http://josefsson.org/openpgp-header/

(Alas, some of the links are not working, due to problems with gmane.)

Thanks.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035BC95029029; Sun, 2 Jan 2005 21:11:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j035BCnv029026; Sun, 2 Jan 2005 21:11:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035B5pY028813; Sun, 2 Jan 2005 21:11:05 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0359wjf003765; Mon, 3 Jan 2005 00:09:58 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p061005d3bdf24f5d9a23@[128.89.89.115]>
Date: Mon, 3 Jan 2005 00:13:09 -0500
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
From: Karen Seo <[e-mail]>
Subject: 2005 Network and Distributed System Security Symposium (NDSS '05)
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1107393303==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--============_-1107393303==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

   ** My apologies if you receive multiple copies of this message. **

                ANNOUNCING THE INTERNET SOCIETY'S
2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05)

February 2, 2005 - Pre Conference Workshop
February 3-4, 2005 - Symposium
Catamaran Resort Hotel, San Diego, California
General Chair:  Eric Harder, National Security Agency
Program co-Chairs: Dan Simon, Microsoft Research
		   Dan Boneh, Stanford University

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/

     The 12th annual NDSS Symposium brings together innovative and
     forward thinking members of the Internet community including
     leading edge security researchers and implementers, globally
     recognized security technology experts, and users from both
     the private and public sectors who design, develop, exploit,
     and deploy the technologies that define network and distributed
     system security.

     NDSS'05 provides a balanced mix of technical papers (with a
     strong emphasis on implementation) that cover new and practical
     approaches to security problems that are endemic to network and
     distributed systems. 

THIS YEAR'S TOPICS INCLUDE:
	* Cryptography in Network Security
	* Denial of Service Attacks,
	* Peer to Peer Approaches
	* Internet Defense
	* Intrusion Detection
	* Platform Security.

FEATURED GUEST SPEAKER:
	* Amit Yoran, who was responsible for coordinating cyber-security
           activities for Homeland Security, will speak on "Security
           Challenges and Opportunities of the Future Enterprise"

PRE CONFERENCE WORKSHOP TOPICS INCLUDE:
	* Security in handling mobility on the internet
	* Security in wireless LANs
	* Security for telephony or voice over IP
	* Trust relations in ad hoc networks
	* Key management strategies to support mobility
	* Security in RFID.
      More information is available at:
         http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml
      Parties interested in submitting papers should see the above
         web page for directions

REGISTER EARLY FOR BEST PRICING
      Registration for NDSS'05 is now open. Student rates are available
      for both the workshop and symposium. See the web site for more
      information -- http://www.isoc.org/ndss05/  Registration fees:
	*  November 31, 2004-January 10, 2005   $625.
	*  After January 10, 2005               $695.

SPONSORSHIP OPPORTUNITIES AVAILABLE!
      If your organization would like to help support NDSS and gain
      visibility through sponsoring, please contact:
      [e-mail].  Information is also available at   
      http://www.isoc.org/ndss05/


Karen Seo
NDSS'05 Publicity Chair
--============_-1107393303==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>2005 Network and Distributed System Security
Symposium (ND</title></head><body>
<div>&nbsp; ** My apologies if you receive multiple copies of this
message. **</div>
<div><font color="#000000"><br></font></div>
<div><font
color="#000000"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp; ANNOUNCING THE INTERNET
SOCIETY'S</font></div>
<div><font color="#000000">2005 NETWORK AND DISTRIBUTED SYSTEM
SECURITY SYMPOSIUM (NDSS'05)</font></div>
<div><font color="#000000"><br>
February 2, 2005 - Pre Conference Workshop<br>
February 3-4, 2005 - Symposium<br>
Catamaran Resort Hotel, San Diego, California</font></div>
<div><font color="#000000">General Chair:&nbsp; Eric Harder, National
Security Agency</font></div>
<div><font color="#000000">Program co-Chairs: Dan Simon, Microsoft
Research</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>&nbsp;&nbsp; Dan Boneh, Stanford University</font></div>
<div><font color="#000000"><br>
ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/<br>
<br>
&nbsp;&nbsp;&nbsp; The 12th annual NDSS Symposium brings together
innovative and</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; forward thinking members
of the Internet community including</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; leading edge security
researchers and implementers, globally</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; recognized security
technology experts, and users from both</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; the private and public
sectors who design, develop, exploit,</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; and deploy the
technologies that define network and distributed</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; system
security.</font></div>
<div><font color="#000000"><br>
&nbsp;&nbsp;&nbsp; NDSS'05 provides a balanced mix of technical papers
(with a</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; strong emphasis on
implementation) that cover new and practical</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; approaches to security
problems that are endemic to network and</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; distributed
systems.&nbsp;</font></div>
<div><font color="#000000"><br>
THIS YEAR'S TOPICS INCLUDE:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Cryptography in Network
Security<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Denial of Service
Attacks,<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* Peer to Peer Approaches<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Internet
Defense<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Intrusion
Detection<br>
<x-tab>&nbsp;&nbsp; </x-tab>* Platform Security.</font><br>
</div>
<div>FEATURED GUEST SPEAKER:</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Amit
Yoran, who was responsible for coordinating cyber-security</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; activities
for Homeland Security, will speak on &quot;Security</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Challenges
and Opportunities of the Future Enterprise&quot;</div>
<div><br>
PRE CONFERENCE WORKSHOP TOPICS INCLUDE:<br>
<x-tab> </x-tab>* Security in handling mobility on the internet</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>*
Security in wireless LANs<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Security for telephony or
voice over IP<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>* Trust relations
in ad hoc networks<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>* Key management strategies to
support mobility</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>*
Security in RFID.</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; More information is available at:</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; Parties interested in submitting papers
should see the above</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; web page for
directions</div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">REGISTER EARLY FOR BEST
PRICING</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; Registration for
NDSS'05 is now open. Student rates are available</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; for both the
workshop and symposium. See the web site for more</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; information
--&nbsp;</font><font
color="#0000FF"><u>http://www.isoc.org/ndss05/</u></font><font
color="#000000">&nbsp; Registration fees:</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>*&nbsp; November 31, 2004-January 10, 2005&nbsp;&nbsp;
$625.</font></div>
<div><font
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>*&nbsp; After January 10,
2005&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; $695.</font></div>
<div><font color="#000000"><br>
SPONSORSHIP OPPORTUNITIES AVAILABLE!</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; If your
organization would like to help support NDSS and gain</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp; visibility through
sponsoring, please contact:</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail].&nbsp; Information is also available
at&nbsp;&nbsp;&nbsp;</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;
http://www.isoc.org/ndss05/</font></div>
<div><br></div>
<div><br></div>
<div>Karen Seo</div>
<div>NDSS'05 Publicity Chair</div>
</body>
</html>
--============_-1107393303==_ma============--