Re: Date fields

[[e-mail]]

>     Are those problems worth the change of the date fields from
> localtime to UTC ?

They are in UTC.  See RFC2440:

   3.5. Time fields
   
      A time field is an unsigned four-octet number containing the number
      of seconds elapsed since midnight, 1 January 1970 UTC.
   
Hal



Received: by above.proper.com (8.9.3/8.9.3) id KAA12700 for ietf-openpgp-bks; Sat, 31 Mar 2001 10:53:20 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA12695 for <[e-mail]>; Sat, 31 Mar 2001 10:53:18 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA25658; Sat, 31 Mar 2001 10:49:56 -0800
Date: Sat, 31 Mar 2001 10:49:56 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Date fields
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>

>     Are those problems worth the change of the date fields from
> localtime to UTC ?

They are in UTC.  See RFC2440:

   3.5. Time fields
   
      A time field is an unsigned four-octet number containing the number
      of seconds elapsed since midnight, 1 January 1970 UTC.
   
Hal


Received: by above.proper.com (8.9.3/8.9.3) id JAA08660 for ietf-openpgp-bks; Sat, 31 Mar 2001 09:05:54 -0800 (PST)
Received: from webmail.vento.com.br ([200.214.174.70]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA08655 for <[e-mail]>; Sat, 31 Mar 2001 09:05:51 -0800 (PST)
Received: from pterodactilo (200.251.73.191) by webmail.vento.com.br (5.1.056) id 3ABFF8C700057B87 for [e-mail]; Sat, 31 Mar 2001 14:05:50 -0300
Message-ID: <003501c0ba04$55313e60$0140a8c0@pterodactilo>
From: "Jacques Exelrud" <[e-mail]>
To: <[e-mail]>
Subject: Date fields
Date: Sat, 31 Mar 2001 13:54:32 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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

    Recently I was faced with a strange behavior of one of my keys.
 One of the subkeys was showing the start date of 1/1/2002 and the
 end date of 31/12/2002 in some machines and 31/12/2001 for starting
 date and 30/21/2002 for ending date in some other machines. 
    Seems the problem is related to DST as the date is interpreted as
localtime and based on wht if those date fall inside DST periods in
some countries and if the computer is configured to take this into
account or not.
    Ate least the third subkey does behave this way on my machine. If
I turn DST handling on or off the dates do change.
    What is still not clear is why just one of the subkeys behaves
this way and the other two seems imune to that funtinality.

    In my opinion, this may lead to some problems.

    For split-keys (hope that's a OpenPGP feature and not just a PGP
feature, have not checked the rfc) it may happen that parts of this
key be located in different parts of the worl so some group of key
holders may be able to still use the key while others may not.

    For non split-keys the problem may not be as serious. What may
happen is that the user may receive an encrypted message with the
about to expire subkey while he is waiting to receive the message
encrypted to the new subkey. At first sign this does not lead to any
security/legal problem. At most the lack of certain on the date the
message was generated because there is a one day lag the the key have
geographic locations able to use it and some that are not.

    Are those problems worth the change of the date fields from
localtime to UTC ?

    Thanks in advance,
    Jacques

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
Comment: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x81F4

iQA/AwUBOsYLxYI01R+B9JjDEQKM7gCfX+KybuWNLNLmkKx97j0bUd61rFYAoMzr
QLhupXonjgiDcvsb2ruqxKhm
=DzLI
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.9.3/8.9.3) id SAA14216 for ietf-openpgp-bks; Thu, 29 Mar 2001 18:18:09 -0800 (PST)
Received: from webmail.vento.com.br ([200.214.174.71]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA14211 for <[e-mail]>; Thu, 29 Mar 2001 18:18:06 -0800 (PST)
Received: from pterodactilo (200.251.73.186) by webmail.vento.com.br (5.1.056) id 3ABB2F16000712A7 for [e-mail]; Thu, 29 Mar 2001 23:18:07 -0300
Message-ID: <002601c0b8bf$27a8eba0$0140a8c0@pterodactilo>
From: "Jacques Exelrud" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Java implementation
Date: Thu, 29 Mar 2001 23:14:27 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

    
    Does anyone knows if I can find Java implementations of OpenPGP ?
    Cryptix has one but it's not ready yet. Any other ?

    Thanks in advance,
    Jacques




Received: by above.proper.com (8.9.3/8.9.3) id KAA18917 for ietf-openpgp-bks; Thu, 29 Mar 2001 10:19:59 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA18913 for <[e-mail]>; Thu, 29 Mar 2001 10:19:58 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA11027; Thu, 29 Mar 2001 10:16:28 -0800
Date: Thu, 29 Mar 2001 10:16:28 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Czech attack to PGP
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>

Werner Koch writes, quoting Hal:
> > A thread on sci.crypt recently pointed to an AsiaCrypt 2000 paper by Mihir
> > Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html.  This is
>
> Thanks.
>
> > In our case we might just compute an HMAC over the entire secret key
> > packet, and append it.
>
> This still does not solve the problem, how to get the key for the
> HMAC.

Yes, it is true we would need another key.

> I didn't read the Bellare paper in detail but I can't see
> that it goes into the problem of possible interaction between the
> encryption and HMAC key.  I think it is good practise, not to use
> the same key (or a derived onbe).  So we would need a second
> passphrase - argh.

What is usually done is that both the encryption key and the MAC
key are derived from a common seed.  In this case the seed would be
the passphrase.  Presently we put the passphrase through a hash-based
transform to generate the encryption key.  We could use a different
transform to generate the HMAC key.  Perhaps it could have a different
iteration count or the hash function could be pre-loaded with a different
prefix value.

> > The commercial version of PGP also uses some special S2K values, but
> > we could certainly decide on a new value to identify the new form of
>
> Can you please tell us which identifiers you use, so that we don't
> run into problems if we encounter such identifiers.  

Yes, I'll put together some documentation on these and on the other
places we use packets.  For now, we use S2K identifier numbers 4 and 5.

Hal


Received: by above.proper.com (8.9.3/8.9.3) id XAA13854 for ietf-openpgp-bks; Wed, 28 Mar 2001 23:42:45 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA13848 for <[e-mail]>; Wed, 28 Mar 2001 23:42:43 -0800 (PST)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.16 #1 (Debian)) id 14iXQr-0005lF-00; Thu, 29 Mar 2001 10:05:25 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14iX5T-0006si-00; Thu, 29 Mar 2001 09:43:19 +0200
Date: Thu, 29 Mar 2001 09:43:19 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Czech attack to PGP
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
User-Agent: Mutt/1.3.16i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Mar 28, 2001 at 11:18:12AM -0800
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03 58A2
X-Request-PGP: finger:[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 Wed, 28 Mar 2001, [e-mail] wrote:

> A thread on sci.crypt recently pointed to an AsiaCrypt 2000 paper by Mihir
> Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html.  This is

Thanks.

> In our case we might just compute an HMAC over the entire secret key
> packet, and append it.

This still does not solve the problem, how to get the key for the
HMAC.  I didn't read the Bellare paper in detail but I can't see
that it goes into the problem of possible interaction between the
encryption and HMAC key.  I think it is good practise, not to use
the same key (or a derived onbe).  So we would need a second
passphrase - argh.

> The commercial version of PGP also uses some special S2K values, but
> we could certainly decide on a new value to identify the new form of

Can you please tell us which identifiers you use, so that we don't
run into problems if we encounter such identifiers.  

Ciao,

  Werner
  

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.9.3/8.9.3) id XAA12736 for ietf-openpgp-bks; Wed, 28 Mar 2001 23:36:45 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA12725 for <[e-mail]>; Wed, 28 Mar 2001 23:36:43 -0800 (PST)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.16 #1 (Debian)) id 14iXL3-0005kx-00; Thu, 29 Mar 2001 09:59:25 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14iWzw-0006s7-00; Thu, 29 Mar 2001 09:37:36 +0200
Date: Thu, 29 Mar 2001 09:37:36 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Fix the secret key packet, not the S2K
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
User-Agent: Mutt/1.3.16i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Mar 28, 2001 at 03:49:04PM -0800
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03 58A2
X-Request-PGP: finger:[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 Wed, 28 Mar 2001, [e-mail] wrote:

> comes shortly before the S2K in the secret key packet.  This byte is
> fixed at a value of 255 to flag that an S2K is in use.  We could perhaps
> use some alternate value for this byte to flag that the private key is
> using a different form of checksum protection.

That would be fine with me.  Although GnuPG already uses the S2K for
similiar purposes.

> is a signature subpacket that holds an X.509 cert.  We should probably
> add these to the revised draft as reserved identifiers.  GPG or other
> implementations may also have some reserved values.

We already have a range for experimental/private extensions (except
for the S2K.  IMHO, an implementation should use these values as
long as that new feature is not in the standard or the WG has agreed
on some new values.  Of course, there should be a way to distinguish
between different usages of those experimental values.  For example,
GnuPG adds a string "GNU" to its private extensions to the S2K.

Ciao,

  Werner
  

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.9.3/8.9.3) id XAA11849 for ietf-openpgp-bks; Wed, 28 Mar 2001 23:32:51 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA11833 for <[e-mail]>; Wed, 28 Mar 2001 23:32:48 -0800 (PST)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.16 #1 (Debian)) id 14iXHA-0005kr-00; Thu, 29 Mar 2001 09:55:24 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14iWue-0006rm-00; Thu, 29 Mar 2001 09:32:08 +0200
Date: Thu, 29 Mar 2001 09:32:08 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Fix the secret key packet, not the S2K
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <03df01c0b7e9$c8c090a0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.16i
In-Reply-To: <03df01c0b7e9$c8c090a0$[e-mail]>; from [e-mail] on Wed, Mar 28, 2001 at 07:47:07PM -0500
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03 58A2
X-Request-PGP: finger:[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 Wed, 28 Mar 2001, Michael Young wrote:

> >First, the secret key packet as such doesn't have a version number.
> 
> There is no deep reason that it couldn't.  Instead of forcing a
> tight coupling between the two, give it its own version byte
> (starting with 5).  The whole public key packet (or just its contents)

The problem ist that this is not a local change but _may_ affect
other parts of an implementation.  For example, at a couple of
places we have to check whether this is a v[23] or v4 packet and if
at some place a version == 4 has accidently been used this would
lead to a lot of other bugs.  We are currently planning for
interoperability tests and such a change may delay those test even
further.  By not changing the the packet version number we can
implement that as a implementation specific change and don't have to
change the specs right now.

Ciao,

  Werner
  

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.9.3/8.9.3) id QAA15764 for ietf-openpgp-bks; Wed, 28 Mar 2001 16:50:45 -0800 (PST)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA15759 for <[e-mail]>; Wed, 28 Mar 2001 16:50:44 -0800 (PST)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id TAA32092 for <[e-mail]>; Wed, 28 Mar 2001 19:44:27 -0500 (EST)
Received: from mwyoung (dhcp-197-35.transarc.ibm.com [9.38.197.35]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id TAA05817 for <[e-mail]>; Wed, 28 Mar 2001 19:50:16 -0500 (EST)
Message-ID: <03df01c0b7e9$c8c090a0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Fix the secret key packet, not the S2K
Date: Wed, 28 Mar 2001 19:47:07 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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-----

>First, the secret key packet as such doesn't have a version number.

There is no deep reason that it couldn't.  Instead of forcing a
tight coupling between the two, give it its own version byte
(starting with 5).  The whole public key packet (or just its contents)
could follow, including its (independent) version number.

> Another place we could represent the alternative format is the byte
> which comes shortly before the S2K in the secret key packet.

A fine alternative... keeps the compatibility hacks together.  How
about 254?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBOsKFw2NDnIII+QUHAQHTNQf/R3PgVwTixzk/XnjTpNxstfi2th0MwDrA
lFYHDHCHhBrIiPenaqxnGFQ6saAtfJpDGtWkBdC85NyNBDz1j9Z9YQYssh6HC8aC
3jq22nfW//py29GV/QOrO8cUXRhns3nZUJYaYtvO/JB6FtWZpKWJPRsxSmBSgmae
P1irG8KvuLeGmmPH6SH/LuESz1Aw1/VPTc2oX5uIWsc+iLDZ600byTchXeKOZasS
DDuPLzyxdnTVjDytu5UuBc/AGoDpjynFg6Li2eDf2/XqEwMAAvpOVzZlbxEgg43R
5EgDxFbK7/TQlXS8tPnJv+FL2T9TpE9N2OaHapLGw/4AdXUvmaOTvg==
=kjmv
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.9.3/8.9.3) id QAA14001 for ietf-openpgp-bks; Wed, 28 Mar 2001 16:17:18 -0800 (PST)
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA13996 for <[e-mail]>; Wed, 28 Mar 2001 16:17:16 -0800 (PST)
Received: from [209.86.2.16] (user-38lc01t.dialup.mindspring.com [209.86.0.61]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA08079; Wed, 28 Mar 2001 19:16:53 -0500 (EST)
Message-Id: <v03110737b6e82d7a8017@[209.86.2.16]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 28 Mar 2001 16:12:43 -0800
To: [e-mail], [e-mail], [e-mail]
From: Bill Frantz <[e-mail]>
Subject: Re: Czech attack to PGP
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 11:18 AM -0800 3/28/01, [e-mail] wrote:
>A thread on sci.crypt recently pointed to an AsiaCrypt 2000 paper by Mihir
>Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html.  This is
>a theoretical analysis showing that based on very minimal assumptions
>of the properties of MAC and encryption algorithms, the strongest mode
>is to encrypt and then MAC.  That is, you compute a keyed MAC on the
>ciphertext in order to detect modification.
>
>In our case we might just compute an HMAC over the entire secret key
>packet, and append it.

I must admit that when coding for the real world, I always liked checking
the MAC as late as possible.  That lets the MAC check as much of the
process as possible for errors.  (If you compute the MAC before encryption
and check it after decryption, the MAC checks the encryption-decryption
process.  In real life, I have found a timing dependant error using this
check.)

In the specific case of secret keys, the arithmetic consistency checks may
result in the same degree of assurance as a MAC, so applying the MAC after
encryption and checking it before decryption may be the right answer.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz       | Microsoft Outlook, the     | Periwinkle -- Consulting
[phone]     | hacker's path to your      | 16345 Englewood Ave.
[e-mail] | hard disk.                 | Los Gatos, CA 95032, USA




Received: by above.proper.com (8.9.3/8.9.3) id PAA11938 for ietf-openpgp-bks; Wed, 28 Mar 2001 15:52:32 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA11933 for <[e-mail]>; Wed, 28 Mar 2001 15:52:30 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA02149; Wed, 28 Mar 2001 15:49:04 -0800
Date: Wed, 28 Mar 2001 15:49:04 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Fix the secret key packet, not the S2K
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>

Michael Young, <[e-mail]>, writes:
> Why is a new S2K mode preferable to a new key version?

I see two reasons:

First, the secret key packet as such doesn't have a version number.
The version number is borrowed from the public key packet that begins
the secret key packet.  In other words, the secret key packet is a public
key packet with extra data stored at the end.

So in order to change the secret key packet version, we need to bump the
public key packet version.  If we create a "V5" secret key then we need
to create a corresponding "V5" public key.  But since we aren't changing
the public key packet format, this is somewhat redundant, since V4 and
V5 public keys would be entirely identical.

Second, the purpose of the S2K specifier and associated information
(algorithm ID etc) is to describe how the secret data is protected.
Since we are making a change with regard to this protection, this is a
reasonable place to represent that change.

> The S2K is used in more than just the secret key packet.
> Adding another context-specific flag to the S2K seems
> wrong (unless you meant for this checksumming behavior
> to apply to other uses, which also seems wrong).

This is true, the S2K is also used for passphrase encrypted messages.

Another place we could represent the alternative format is the byte which
comes shortly before the S2K in the secret key packet.  This byte is
fixed at a value of 255 to flag that an S2K is in use.  We could perhaps
use some alternate value for this byte to flag that the private key is
using a different form of checksum protection.

> Do you think that existing implementations would just
> happen to ignore extra bits in the S2K specifier and
> extra checksum bytes at the end?  If so, I admire
> the trickery, but I don't think this is serious
> enough to warrant it in the spec -- as many folks have
> pointed out, local key storage can use any hackery
> an implementation likes anyway.

No, I think existing implementations will refuse to use the new keys
regardless of where we make the change.

> > The commercial version of PGP also uses some special S2K values, but
>
> Yes... the "raw" key used in key-splitting.
>
> Which brings me to another point: can we at least
> put placeholders in the spec for these existing PGP
> product features?  I know that some of these hidden
> features (ADKs, for instance) are unpopular, but an
> OpenPGP implementation may well run across them.
> I'd really like the spec to say how they appear (and
> even what they do), even if it does not endorse them,
> so that implementations can recognize them if they want.
> The spec does have a "placeholder" for the ADK
> subpacket.  Shouldn't it for the S2K extensions?
> Are there others we just haven't run across yet?

This is a good idea.  There are a few others I know of which are
undocumented, besides the two S2K identifiers.  These relate to X.509
certificate support.  There is a packet type used as CRL, and there
is a signature subpacket that holds an X.509 cert.  We should probably
add these to the revised draft as reserved identifiers.  GPG or other
implementations may also have some reserved values.

Hal


Received: by above.proper.com (8.9.3/8.9.3) id OAA07151 for ietf-openpgp-bks; Wed, 28 Mar 2001 14:26:10 -0800 (PST)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA07136 for <[e-mail]>; Wed, 28 Mar 2001 14:26:03 -0800 (PST)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id RAA30820 for <[e-mail]>; Wed, 28 Mar 2001 17:19:45 -0500 (EST)
Received: from mwyoung (dhcp-197-35.transarc.ibm.com [9.38.197.35]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA05036 for <[e-mail]>; Wed, 28 Mar 2001 17:25:35 -0500 (EST)
Message-ID: <007701c0b7d5$af3b73c0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Fix the secret key packet, not the S2K
Date: Wed, 28 Mar 2001 17:22:49 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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-----

Hal seems to endorse to Werner's suggestion:
> > We introcude a new S2K mode and encrypt this:

Why is a new S2K mode preferable to a new key version?

The S2K is used in more than just the secret key packet.
Adding another context-specific flag to the S2K seems
wrong (unless you meant for this checksumming behavior
to apply to other uses, which also seems wrong).

Do you think that existing implementations would just
happen to ignore extra bits in the S2K specifier and
extra checksum bytes at the end?  If so, I admire
the trickery, but I don't think this is serious
enough to warrant it in the spec -- as many folks have
pointed out, local key storage can use any hackery
an implementation likes anyway.

> The commercial version of PGP also uses some special S2K values, but

Yes... the "raw" key used in key-splitting.

Which brings me to another point: can we at least
put placeholders in the spec for these existing PGP
product features?  I know that some of these hidden
features (ADKs, for instance) are unpopular, but an
OpenPGP implementation may well run across them.
I'd really like the spec to say how they appear (and
even what they do), even if it does not endorse them,
so that implementations can recognize them if they want.
The spec does have a "placeholder" for the ADK
subpacket.  Shouldn't it for the S2K extensions?
Are there others we just haven't run across yet?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBOsJj/2NDnIII+QUHAQHU2QgAl36/7/SQ++dtBv1am8pEECYoAF3v7r8+
YOXSImQ9fODIx/hSipgtIrbzz4Ky1rkHPhlLwy43XhOT2msStghXKDgzjYzu2CJn
nvyCAkVLrT8QpfOr8cT7gvM4UlkgB5+TmPOJ4Uuz0wtfuz2BLvdBXDEBT9EbeCeE
QQuclQ/nJe99Dme1SThnKWRchmF3JkHLOxfS5PHwf0wYXihaL0ziZmQezMvGUQVL
zxfWKVlVzCGWwCG7bWtvpr7n6+Ye5ZoCEOCM8Qa642K0EMJ477E7CrSeZbvyMcps
4Vwb20ONtah80/Afko85vjSIzpXgGKQsKQIUihiR8vnSp4BB8ZxaZw==
=eplI
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.9.3/8.9.3) id LAA23748 for ietf-openpgp-bks; Wed, 28 Mar 2001 11:21:59 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA23734 for <[e-mail]>; Wed, 28 Mar 2001 11:21:48 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA30520; Wed, 28 Mar 2001 11:18:12 -0800
Date: Wed, 28 Mar 2001 11:18:12 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Czech attack to PGP
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>

Werner Koch writes:

> No need for a new format - doing such changes for OpenPGP right now
> will delay getting to draft even more.
>
> There is a far easier way to do this and we can do this first in our
> implementations and use the old format for transferring secret keys
> (which is a Bad Thing doing it at all or over an insecure channel):

Yes, I like the idea of doing extra checks internally, while retaining
at least for now the current format as a data interchange.  We could
add language to the draft warning implementors to check the arithmetic
validity of the keys if the files may have been meddled with.

> We introcude a new S2K mode and encrypt this:
>
>  1. fingerprint of the public key
>  2. the secret MPIs
>  3. A SHA-1 hash over 1 and 2.

A thread on sci.crypt recently pointed to an AsiaCrypt 2000 paper by Mihir
Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html.  This is
a theoretical analysis showing that based on very minimal assumptions
of the properties of MAC and encryption algorithms, the strongest mode
is to encrypt and then MAC.  That is, you compute a keyed MAC on the
ciphertext in order to detect modification.

In our case we might just compute an HMAC over the entire secret key
packet, and append it.

Now, Bellare's analysis is highly theoretical, and some of the attacks
he shows on other modes are quite artificial.  In practice something
like what Werner suggests should be fine.  But still we might want to
consider using the Bellare approach since it is strong even when we
consider artificial-seeming attacks.

> So either each implementation uses it's own scheme or we agree
> informally on one in the (not officially reserved) private range of
> S2K mode.

The commercial version of PGP also uses some special S2K values, but
we could certainly decide on a new value to identify the new form of
checksum.

Hal


Received: by above.proper.com (8.9.3/8.9.3) id XAA09602 for ietf-openpgp-bks; Sun, 25 Mar 2001 23:28:43 -0800 (PST)
Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA09598 for <[e-mail]>; Sun, 25 Mar 2001 23:28:42 -0800 (PST)
Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id XAA17067 for <[e-mail]>; Sun, 25 Mar 2001 23:28:41 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: fyi: PGP attack specs [english]
To: [e-mail]
Reply-to: [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 25 Mar 2001 23:28:41 -0800
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>

------- Forwarded Message

Date: Sun, 25 Mar 2001 18:13:27 +0100
To: [e-mail]
From: Donald ramsbottom <[e-mail]>
Subject: PGP attack specs

Via Cryptome, below is the URL for the tech specs on the PGP attack



http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf



Donald Ramsbottom BA LLb (Hons) PGdip
Ramsbottom & Co Solicitors
Internet and Global Encryption Law Specialists & General UK  Law Matters
5 Seagrove Avenue Hayling Island Hampshire UK
Tel [phone] Fax [phone]
Regulated by the Law Society in the conduct of Investment business
Service by Fax or Email NOT accepted



------- End of Forwarded Message





Received: by above.proper.com (8.9.3/8.9.3) id AAA10083 for ietf-openpgp-bks; Sun, 25 Mar 2001 00:09:44 -0800 (PST)
Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA10073 for <[e-mail]>; Sun, 25 Mar 2001 00:09:43 -0800 (PST)
Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bll013083 for <[e-mail]>; Sun, 25 Mar 2001 02:07:51 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
From: "[e-mail]" <[e-mail]>
To: [e-mail]
Date: Sun, 25 Mar 2001 02:04:33 -0600
Subject: Would you like to recieve information on how to register your pet online for free?
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18829276_7473.76"
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 is a Multipart MIME message.

------=_NextPart_000_001__18829276_7473.76
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__18829276_7473.76
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4
dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93
IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg
eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro
ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi
amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw
PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg
dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl
bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0
IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i
b2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_001__18829276_7473.76--



Received: by above.proper.com (8.9.3/8.9.3) id FAA20116 for ietf-openpgp-bks; Sat, 24 Mar 2001 05:51:14 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA20108 for <[e-mail]>; Sat, 24 Mar 2001 05:51:11 -0800 (PST)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.16 #1 (Debian)) id 14gomb-0008Sz-00; Sat, 24 Mar 2001 15:12:45 +0100
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14goRq-0003xF-00; Sat, 24 Mar 2001 14:51:18 +0100
Date: Sat, 24 Mar 2001 14:51:18 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Czech attack to PGP
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Mar 22, 2001 at 10:51:30AM -0800
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03 58A2
X-Request-PGP: finger:[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 Thu, 22 Mar 2001, [e-mail] wrote:

> and how the key for the HMAC is calculated from the passphrase (generally
> it is a good idea for MAC keys to be different from decryption keys).
> Do we need to define a new packet format, V5 for keys?  Or could we keep

No need for a new format - doing such changes for OpenPGP right now
will delay getting to draft even more.

There is a far easier way to do this and we can do this first in our
implementations and use the old format for transferring secret keys
(which is a Bad Thing doing it at all or over an insecure channel):

We introcude a new S2K mode and encrypt this:

 1. fingerprint of the public key
 2. the secret MPIs
 3. A SHA-1 hash over 1 and 2.
 
This closly resembles the MDC encryption we are now using. The
fingerprint also comes handy to store these secret parts on hardware
tokens and migh be a good idea anyway for an internal secret key
storage format.  If there are concerns about known plaintext we
could leave the fingerprint out of the encryption so that we hash
1+2 and encrypt 2+3.

GnuPG can already use an extension to the secret key protection,
which is used to allow for a primary key without secret key but
workable secret subkeys (nice on a automated system):

| S2K mode 101 is used to identify these extensions.
| After the hash algorithm the 3 bytes "GNU" are used to make
| clear that these are extensions for GNU, the next bytes gives the
| GNU protection mode - 1000.  Defined modes are:
|   1001 - do not store the secret part at all
 
So either each implementation uses it's own scheme or we agree
informally on one in the (not officially reserved) private range of
S2K mode.

I agree with Hal that there is no urgent need to do something.  This
might backfire on repudation of the OpenPGP specs.

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.9.3/8.9.3) id UAA00669 for ietf-openpgp-bks; Fri, 23 Mar 2001 20:28:16 -0800 (PST)
Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA00665 for <[e-mail]>; Fri, 23 Mar 2001 20:28:15 -0800 (PST)
Received: by cypherpunks.ai (Postfix, from userid 1019) id 1F2D54C; Sat, 24 Mar 2001 00:27:47 -0400 (AST)
Date: Sat, 24 Mar 2001 00:27:47 -0400
From: Adam Back <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: pgp-6.5.8 secret key keyID export bug? / rfc doesn't specify keyIDs
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 23, 2001 at 08:14:37PM -0800
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>

Yes you are right.  I'll see if I can fix pgpacket.pl.  (It is internally
computing hashes using some perl sha1 code.)  It has an option not
to do it even because the hashes are slow, I should have remembered
that as Mark Shoulson was telling me about it.

Adam

On Fri, Mar 23, 2001 at 08:14:37PM -0800, [e-mail] wrote:
> The keyID is not present as a field in key packets.  It must be computed
> from the key data.  For DSA keys it is defined as the last 64 (or 32)
> bits of the fingerprint, which is itself a hash of the data in the public
> key packet.
> 
> Probably that packet-dump program you were using computes keyids
> incorrectly for private key packets.  It is probably hashing too much
> data.


Received: by above.proper.com (8.9.3/8.9.3) id UAA00525 for ietf-openpgp-bks; Fri, 23 Mar 2001 20:18:34 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id UAA00521 for <[e-mail]>; Fri, 23 Mar 2001 20:18:33 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id UAA03535; Fri, 23 Mar 2001 20:14:37 -0800
Date: Fri, 23 Mar 2001 20:14:37 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: pgp-6.5.8 secret key keyID export bug? / rfc doesn't specify keyIDs
Cc: [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>

Adam writes:
> actually it looks like gnuPG does the same thing as PGP.
>
> I'm presuming the keyID includes the private key components for private
> keys, so the private key has a different keyID even though the gui doesn't
> display it that way, if you display the contents of the private key file.
>
> So I guess you have to compute the keyID rather than reading it in form the
> secret key file if you're working from a secret key and not a public key.

The keyID is not present as a field in key packets.  It must be computed
from the key data.  For DSA keys it is defined as the last 64 (or 32)
bits of the fingerprint, which is itself a hash of the data in the public
key packet.

Probably that packet-dump program you were using computes keyids
incorrectly for private key packets.  It is probably hashing too much
data.

Hal


Received: by above.proper.com (8.9.3/8.9.3) id TAA29732 for ietf-openpgp-bks; Fri, 23 Mar 2001 19:45:35 -0800 (PST)
Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA29728 for <[e-mail]>; Fri, 23 Mar 2001 19:45:33 -0800 (PST)
Received: by cypherpunks.ai (Postfix, from userid 1019) id 2CEDE94; Fri, 23 Mar 2001 23:45:07 -0400 (AST)
Date: Fri, 23 Mar 2001 23:45:07 -0400
From: Adam Back <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: pgp-6.5.8 secret key keyID export bug? / rfc doesn't specify keyIDs
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.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>

I wrote:

> (I was testing with gnuPG 1.0.4 also, and it seems to do the right thing.)

actually it looks like gnuPG does the same thing as PGP.

I'm presuming the keyID includes the private key components for private
keys, so the private key has a different keyID even though the gui doesn't
display it that way, if you display the contents of the private key file.

So I guess you have to compute the keyID rather than reading it in form the
secret key file if you're working from a secret key and not a public key.

Adam


Received: by above.proper.com (8.9.3/8.9.3) id TAA29389 for ietf-openpgp-bks; Fri, 23 Mar 2001 19:28:14 -0800 (PST)
Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA29385 for <[e-mail]>; Fri, 23 Mar 2001 19:28:12 -0800 (PST)
Received: by cypherpunks.ai (Postfix, from userid 1019) id 5F01694; Fri, 23 Mar 2001 23:27:45 -0400 (AST)
Date: Fri, 23 Mar 2001 23:27:45 -0400
From: Adam Back <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: pgp-6.5.8 secret key keyID export bug? / rfc doesn't specify keyIDs
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.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>

I notice that pgp-6.5.8 outputs (using pgpacket3.1.pl), when you export a
private DSA key:

> ---------------------------
> Packet Type:    Secret Key Packet
> Length: 443
> Version Byte:   4
> Key Created:    23 Mar 2001  00:32:07
> Algorithm:      17 (DSA)
> P:      0xFF1C014574D484878B11438147F1B6D763701B486BFBFED1CC151533CDEBC0B3871A5180B209195E28FB6B4F8C9DDC354CE97CF73ADD0B9AB7855F3AC5A915A9A5F75008ABD4FB0E751D3B31FBE63A8F8BC961FCA625B8F0F990B7EC989875A1119470C5DCA4C692C7687B901B86C0105A4A8AE2A56F373B3603C1970F7AB6D5
> Q:      0xFFF7C19017F4FDB1BA22D013835819FFBD290F91
> G:      0x3706F602DB508F8AC6B871EB266712859A2F52A90F311DA9D6033FE251E58BDDF7BFDF7EE52558E270677F19AF2AEAE4E1AF6E723B79382DB2DAB846FDB8A852630BC1A9B1E4B7CE185A8211B0F91CBF04C086DAA921F254B5C9A92FA1023D2AB4A472EFD524321D8D1920CCF9CE339BC11ED4FFE7CAC886503461B6CE9CD528
> Y:      0x13035892703E33CEA75C2E437444D5EC1E9CE5F1473442760A1C3EB34A15331EC6AF6673F5287C20FEE84B5193CD784214DAFF55AD09737E7A724AE18F8D2E1DA5EB1CB33A7F0B33D001EBD003C2F60D550EC6DC71ADD68457A5F34EEE10031875885622670DC9541E0F2DD5472B04A3C3AA5BA0EA856DFCA6CC862DA216EE1B
> Protection Algorithm: 0 (None).
> X:      0x009E3362E8C0A65C6921FCE2890727BC0DD4E1C8E83A
> Checksum:       0x0B64
> Key ID: 0xBF9829693FEB29C7


but the public key keyID is different (and correct):

---------------------------
Packet Type:	Public Key Packet
Length:	418
Version Byte:	4
Key Created:	23 Mar 2001  00:32:07
Algorithm:	17 (DSA)
P:
0xFF1C014574D484878B11438147F1B6D763701B486BFBFED1CC151533CDEBC0B3871A5180B209195E28FB6B4F8C9DDC354CE97CF73ADD0B9AB7855F3AC5A915A9A5F75008ABD4FB0E751D3B31FBE63A8F8BC961FCA625B8F0F990B7EC989875A1119470C5DCA4C692C7687B901B86C0105A4A8AE2A56F373B3603C1970F7AB6D5
Q:	0xFFF7C19017F4FDB1BA22D013835819FFBD290F91
G:
0x3706F602DB508F8AC6B871EB266712859A2F52A90F311DA9D6033FE251E58BDDF7BFDF7EE52558E270677F19AF2AEAE4E1AF6E723B79382DB2DAB846FDB8A852630BC1A9B1E4B7CE185A8211B0F91CBF04C086DAA921F254B5C9A92FA1023D2AB4A472EFD524321D8D1920CCF9CE339BC11ED4FFE7CAC886503461B6CE9CD528
Y:
0x13035892703E33CEA75C2E437444D5EC1E9CE5F1473442760A1C3EB34A15331EC6AF6673F5287C20FEE84B5193CD784214DAFF55AD09737E7A724AE18F8D2E1DA5EB1CB33A7F0B33D001EBD003C2F60D550EC6DC71ADD68457A5F34EEE10031875885622670DC9541E0F2DD5472B04A3C3AA5BA0EA856DFCA6CC862DA216EE1B
Key ID: 0xF77801127F715726

and the self-sigature made by that key identifies itself by a the same
correct keyID.

So a couple of problems:

- is pgp-6.5.8 using the keyID field on secret key packets
  for something else (checksum?), or is it a bug?

- rfc2440 does not mention the keyID which is part of the secret key and
  public key packets.  If you look in sections 5.5.2 and 5.5.3 there appears
  to be no mention of the keyID.  This seems like an error in the RFC.

(I was testing with gnuPG 1.0.4 also, and it seems to do the right thing.)

Adam


Received: by above.proper.com (8.9.3/8.9.3) id XAA02750 for ietf-openpgp-bks; Thu, 22 Mar 2001 23:54:06 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA02743 for <[e-mail]>; Thu, 22 Mar 2001 23:54:03 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2N7s1n13338 for [e-mail]; Fri, 23 Mar 2001 08:54:01 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Czech attack to PGP
Date: 23 Mar 2001 07:54:01 GMT
Organization: IKS GmbH Jena
Lines: 20
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

* [e-mail] wrote:
>Then there is the issue that if we are changing the packet format, maybe
>we should make other changes as well.

There is no need to do so.

>Then, if we're changing the secret key packet format, should the public
>key packet be changed as well,

There is not connection between the public and the secret key format.

>kind of opens a can of worms if we go this way.  On the other hand, given
>that any new key format won't be backwards-compatible, if there are other
>secret-key-specific changes this might be a good time to make them.

I oppose quick changes. OpenPGP needs a deep protocol analysis and a much
easier format. This can't be done in a few weeks.

Our short term solution should be: Encourage the implementors to choose
better storage formats and urge more integrity checks.


Received: by above.proper.com (8.9.3/8.9.3) id VAA16633 for ietf-openpgp-bks; Thu, 22 Mar 2001 21:26:12 -0800 (PST)
Received: from rcn.ihtfp.org ([e-mail] [135.222.65.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA16629 for <[e-mail]>; Thu, 22 Mar 2001 21:26:10 -0800 (PST)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id AAA25433; Fri, 23 Mar 2001 00:26:13 -0500
To: Taral <[e-mail]>
Cc: [e-mail]
Subject: Re: Question
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 Mar 2001 00:26:08 -0500
In-Reply-To: Taral's message of "Thu, 22 Mar 2001 23:23:40 -0600"
Message-ID: <[e-mail]>
Lines: 60
X-Mailer: Gnus v5.5/Emacs 20.3
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>

And this is one way in which MIME was broken to begin with, because
it didn't play nice with security.  With security multiparts, you
MUST NOT change the message in transit.  If you want to change it,
you must super-encode it, so that in the end you can return to the
original bit-stream of the original message.

-derek

Taral <[e-mail]> writes:

> --/9DWx/yDrRhgMJTb
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Mar 22, 2001 at 10:59:16PM -0500, Derek Atkins wrote:
> > The multipart/security RFC (please excuse me for not spewing the
> > number) specifically forbids MIME agents from re-calcuating the
> > _INTERNAL_ CTE of a message.  You may change the CTE of a message for
> > transport, but you must revert to the original CTE before security
> > decapsulation.
> >=20
> > In other words, sendmail may apply a radix64 to the message provided
> > that the receiving sendmail reverts the radix64 back to the original
> > form.  In other other words, multipart/security forbids the use of
> > this MIME feature.
> 
> This seems awfully strange. The whole point of MIME is to be able to
> be permissive in these kinds of things. Having read the MIME standards a
> few times, I would never have assumed that a multipart type would ever
> have special restrictions like this based on subtype. In fact,
> multipart/signed is not required to be implemented by agents, and they
> are _explicitly_ permitted to treated like multipart/mixed, in which the
> CTE can be changed if recoding is needed.
> 
> --=20
> Taral <[e-mail]>
> Please use PGP/GPG to send me mail.
> "Never ascribe to malice what can as easily be put down to stupidity."
> 
> --/9DWx/yDrRhgMJTb
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjq63dwACgkQ7rh4CE+nYElQrQCfat5GtKE0EzfT922bouIMunPi
> xEkAn3BOVqwFU8scRR6OVDwV7ZVqAEI9
> =0YMf
> -----END PGP SIGNATURE-----
> 
> --/9DWx/yDrRhgMJTb--

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.9.3/8.9.3) id VAA16591 for ietf-openpgp-bks; Thu, 22 Mar 2001 21:23:38 -0800 (PST)
Received: from dragon.taral.net ([e-mail] [66.68.22.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA16586 for <[e-mail]>; Thu, 22 Mar 2001 21:23:36 -0800 (PST)
Received: by dragon.taral.net (Postfix, from userid 1000) id 50AC512CE4; Thu, 22 Mar 2001 23:23:40 -0600 (CST)
Date: Thu, 22 Mar 2001 23:23:40 -0600
From: Taral <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: [e-mail]
Subject: Re: Question
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Mar 22, 2001 at 10:59:16PM -0500
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>

--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 22, 2001 at 10:59:16PM -0500, Derek Atkins wrote:
> The multipart/security RFC (please excuse me for not spewing the
> number) specifically forbids MIME agents from re-calcuating the
> _INTERNAL_ CTE of a message.  You may change the CTE of a message for
> transport, but you must revert to the original CTE before security
> decapsulation.
>=20
> In other words, sendmail may apply a radix64 to the message provided
> that the receiving sendmail reverts the radix64 back to the original
> form.  In other other words, multipart/security forbids the use of
> this MIME feature.

This seems awfully strange. The whole point of MIME is to be able to
be permissive in these kinds of things. Having read the MIME standards a
few times, I would never have assumed that a multipart type would ever
have special restrictions like this based on subtype. In fact,
multipart/signed is not required to be implemented by agents, and they
are _explicitly_ permitted to treated like multipart/mixed, in which the
CTE can be changed if recoding is needed.

--=20
Taral <[e-mail]>
Please use PGP/GPG to send me mail.
"Never ascribe to malice what can as easily be put down to stupidity."

--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq63dwACgkQ7rh4CE+nYElQrQCfat5GtKE0EzfT922bouIMunPi
xEkAn3BOVqwFU8scRR6OVDwV7ZVqAEI9
=0YMf
-----END PGP SIGNATURE-----

--/9DWx/yDrRhgMJTb--


Received: by above.proper.com (8.9.3/8.9.3) id TAA15492 for ietf-openpgp-bks; Thu, 22 Mar 2001 19:59:35 -0800 (PST)
Received: from rcn.ihtfp.org ([e-mail] [135.222.65.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA15488 for <[e-mail]>; Thu, 22 Mar 2001 19:59:33 -0800 (PST)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id WAA25292; Thu, 22 Mar 2001 22:59:21 -0500
To: Taral <[e-mail]>
Cc: [e-mail]
Subject: Re: Question
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 22 Mar 2001 22:59:16 -0500
In-Reply-To: Taral's message of "Thu, 22 Mar 2001 17:26:47 -0600"
Message-ID: <[e-mail]>
Lines: 57
X-Mailer: Gnus v5.5/Emacs 20.3
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>

The multipart/security RFC (please excuse me for not spewing the
number) specifically forbids MIME agents from re-calcuating the
_INTERNAL_ CTE of a message.  You may change the CTE of a message for
transport, but you must revert to the original CTE before security
decapsulation.

In other words, sendmail may apply a radix64 to the message provided
that the receiving sendmail reverts the radix64 back to the original
form.  In other other words, multipart/security forbids the use of
this MIME feature.

-derek

Taral <[e-mail]> writes:

> --tKW2IUtsqtDRztdT
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> [ Please Cc: me on messages, I am not on this list ]
> 
> I'm sure this has been asked before, but I'm going to ask it, because I
> have yet to locate a sufficient answer.
> 
> In the current PGP/MIME standard, it is specifically stated that
> signatures are calculated after the application of the CTE. However,
> RFC 2045 makes it clear that MTAs may re-encode bodies as necessary. The
> way signatures are currently calculated, this operation (which is
> perfectly valid under MIME) invalidates the signature. Can anyone
> explain why this would be a desirable situation?
> 
> --=20
> Taral <[e-mail]>
> Please use PGP/GPG to send me mail.
> "Never ascribe to malice what can as easily be put down to stupidity."
> 
> --tKW2IUtsqtDRztdT
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjq6ijcACgkQ7rh4CE+nYEkQ/gCeJMAPsXtQ5/j6LMxpEoEk9HWN
> BPsAoPLXQ1VMF8SC6WrmZU6kS5nbEMjX
> =snc9
> -----END PGP SIGNATURE-----
> 
> --tKW2IUtsqtDRztdT--

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.9.3/8.9.3) id QAA07900 for ietf-openpgp-bks; Thu, 22 Mar 2001 16:28:43 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA07891 for <[e-mail]>; Thu, 22 Mar 2001 16:28:41 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14gFRA-0007oY-00; Fri, 23 Mar 2001 01:28:16 +0100
To: [e-mail]
Cc: [e-mail]
Subject: Re: Czech attack to PGP
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 23 Mar 2001 01:28:16 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

[e-mail] writes:

> Then there is the issue that if we are changing the packet format, maybe
> we should make other changes as well.  Then, if we're changing the secret
> key packet format, should the public key packet be changed as well,
> which introduces interoperability and backwards-compatiblity problems.

It's certainly better to break compatibility explicitly than to
introduce a new interpretation of an existing data format (e.g. based
on packet length).  The former will result in clear error messages for
users of old software, the latter will cause obscure errors and
messages.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.9.3/8.9.3) id PAA06637 for ietf-openpgp-bks; Thu, 22 Mar 2001 15:55:54 -0800 (PST)
Received: from RELAY.beta2.freedom.net (relay.beta2.freedom.net [207.107.115.76]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA06633 for <[e-mail]>; Thu, 22 Mar 2001 15:55:53 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: (qmail 23551 invoked from network); 22 Mar 2001 23:55:52 -0000
Received: from unknown (207.107.115.85) by 0 with QMQP; 22 Mar 2001 23:55:52 -0000
Received: (qmail 11057 invoked from network); 22 Mar 2001 23:55:52 -0000
Received: from unknown (207.107.115.83) by 0 with QMQP; 22 Mar 2001 23:55:52 -0000
Received: from unknown (192.168.84.11) by 0 with SMTP; 22 Mar 2001 23:55:51 -0000
X-Freedom-Envelope-Sig: [e-mail] AQEN/97SMl6dI10KmFsERdtsBF7zIgdw6l1X+1y0/W7atydMQOzJHVNr
Date: Thu, 22 Mar 2001 15:52:06 -0800
Old-From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: Czech attack to PGP
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>

Florian Weimer, <[e-mail]>, writes:
> Hmm.  What about introducing a new secret key packet with a hash
> instead of a checksum? This approach seems to be much cleaner, and it
> doesn't cause surprising problems for the end user.

I think that is basically what I was suggesting, except using an HMAC
(which is a keyed hash).  This would be a new format for secret key
packets.  Then we'd have to work out the details in terms of what we do
with version numbers and such.

Then there is the issue that if we are changing the packet format, maybe
we should make other changes as well.  Then, if we're changing the secret
key packet format, should the public key packet be changed as well,
which introduces interoperability and backwards-compatiblity problems.
It kind of opens a can of worms if we go this way.  On the other hand,
given that any new key format won't be backwards-compatible, if there are
other secret-key-specific changes this might be a good time to make them.

Hal

________________________________________________________________________
Total Internet Privacy -- get your Freedom Nym at http://www.freedom.net



Received: by above.proper.com (8.9.3/8.9.3) id PAA04398 for ietf-openpgp-bks; Thu, 22 Mar 2001 15:26:45 -0800 (PST)
Received: from dragon.taral.net ([e-mail] [66.68.22.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA04392 for <[e-mail]>; Thu, 22 Mar 2001 15:26:44 -0800 (PST)
Received: by dragon.taral.net (Postfix, from userid 1000) id 4E65312CE4; Thu, 22 Mar 2001 17:26:47 -0600 (CST)
Date: Thu, 22 Mar 2001 17:26:47 -0600
From: Taral <[e-mail]>
To: [e-mail]
Subject: Question
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
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>

--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[ Please Cc: me on messages, I am not on this list ]

I'm sure this has been asked before, but I'm going to ask it, because I
have yet to locate a sufficient answer.

In the current PGP/MIME standard, it is specifically stated that
signatures are calculated after the application of the CTE. However,
RFC 2045 makes it clear that MTAs may re-encode bodies as necessary. The
way signatures are currently calculated, this operation (which is
perfectly valid under MIME) invalidates the signature. Can anyone
explain why this would be a desirable situation?

--=20
Taral <[e-mail]>
Please use PGP/GPG to send me mail.
"Never ascribe to malice what can as easily be put down to stupidity."

--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq6ijcACgkQ7rh4CE+nYEkQ/gCeJMAPsXtQ5/j6LMxpEoEk9HWN
BPsAoPLXQ1VMF8SC6WrmZU6kS5nbEMjX
=snc9
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--


Received: by above.proper.com (8.9.3/8.9.3) id MAA21239 for ietf-openpgp-bks; Thu, 22 Mar 2001 12:25:39 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21235 for <[e-mail]>; Thu, 22 Mar 2001 12:25:37 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012017.qualcomm.com [10.13.12.17]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2MKPXV24919; Thu, 22 Mar 2001 12:25:33 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100705b6e00c3468a0@[135.222.66.224]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
X-Priority: 2 (High)
Date: Thu, 22 Mar 2001 14:16:04 -0600
To: [e-mail] (Lutz Donnerhacke)
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Czech attack to PGP - keep the kimono closed
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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 7:49 PM +0000 3/22/01, Lutz Donnerhacke wrote:
>Ack. We should stress that private key files should not reside on shared
>media and that OpenPGP ist a transport message format, not a local storage
>recommendation. Implementations are free to choose anything else.

Yes, definitely, Lutz.  This has been mentioned in a number of 
different messages, but this is probably the single most important 
point, and worth singling it out.  Transferring secret key files 
makes them vulnerable to attack.  Vlastimil and Rosa have shown a 
particular way to attack them.

best,

-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA17605 for ietf-openpgp-bks; Thu, 22 Mar 2001 11:49:48 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17599 for <[e-mail]>; Thu, 22 Mar 2001 11:49:46 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2MJnl019959 for [e-mail]; Thu, 22 Mar 2001 20:49:47 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Czech attack to PGP
Date: 22 Mar 2001 19:49:47 GMT
Organization: IKS GmbH Jena
Lines: 85
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: belenus.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

* [e-mail] wrote:
>The RSA attack is the one Lutz called a "Bellcore" attack, based on the
>Eurocrypt 97 paper by Boneh et al at
>http://theory.stanford.edu/~dabo/papers/faults.ps.gz.

Yep. Thanks for the link. 'Bellcore attack' is the name in the German
smartcard hacking scene.

>one side of the signature is done wrong.  Specifically they change the
>last value in the secret key, "u", which is the inverse of p mod q.

Posted this yesterday: Yep possible, even to change the checksum.

>The DSA attack is quite different.  In this case they change the
>public parameters of the DSA key to weaken it but leave the private
>part alone.  They change p and g to be a group where discrete logs are
>easy, one where (p-1) has only small factors.  Then when the signature
>is calculated, they can find the secret k value by taking the discrete
>log of r, and from this they can calculate the user's secret key.

Great idea.

>whenever it decrypts RSA private key data, it does the following checks:
>
>   n = p*q
>   d*e mod p = 1
>   d*e mod q = 1
>   p*u mod q = 1
>
>This validates all of the private key data and makes sure it is consistent
>with the public key values.  In particular the last check prevents the

It makes sure, that is consistent in itself, but it does not say anything
about a prevented attack: Assume an attack able to modifiy the parameter q
to be equal 1. If have to sleep about this.

>Note that these checks are quite fast, just a few multiplies and
>divides, so they do not slow down the signature calculation by much,
>since it involves exponentiations.

They do not address probability attacks to errors in the MPI calculus. (Wait
for a bellcore scenario ... most customer PCs run far from there
specifications, so we have a real smartcard analogon). Thats why PGP263(i)n
does check against any miscalculations.

>  - Use CBC mode rather than CFB to encrypt private key components
>  - Use an HMAC to protect public and private key data
>  - Use PSS padding from PKCS-1 v 2.1 rather than the v 1.5 padding

I'd like to add: Throw away the bit gambling. Redesign from scratch.

>bit pattern into it.  They use this to attack RSA V4 keys.  However,
>CBC mode allows similar perturbations, but to the first block rather
>than the last block.  So this fix does not go to the heart of the problem
>and could still leave vulnerabilities.

Yep. This would be a HMAC.

>The last idea, to use PSS padding, also does not seem to fundamentally
>help.  It would still be possible to disrupt the CRC calculation.

We could prevent algebraic attacks by applying the P.1363 recommendation.

>Broadly speaking, because the attack requires write access to users'
>private keys, I don't think making changes is an urgent matter.

Ack. We should stress that private key files should not reside on shared
media and that OpenPGP ist a transport message format, not a local storage
recommendation. Implementations are free to choose anything else.

>Do we need to define a new packet format, V5 for keys?  Or could we keep
>the old format number and use the length difference of a 20-byte HMAC
>vs a 2-byte checksum to recognize which one is being used?

No more bit gamblings! Use v5 for secret keys. A public part to index and a
whole encrypted and hashed private part including the whole pulic key data
again.

>If we do add an HMAC, software could then work in a mode where old-format
>keys get the extra checks applied to carefully validate them, then
>get rewritten using the HMAC.  From then on the extra checks are not
>necessary and the HMAC alone will detect changes.  So we will retain
>fast performance, plus have security against tampered private key files.

I'm feeling bad.


Received: by above.proper.com (8.9.3/8.9.3) id LAA16724 for ietf-openpgp-bks; Thu, 22 Mar 2001 11:39:09 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16718 for <[e-mail]>; Thu, 22 Mar 2001 11:39:07 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14gAuv-0006wQ-00 for [e-mail]; Thu, 22 Mar 2001 20:38:41 +0100
To: [e-mail]
Subject: Re: Czech attack to PGP
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 22 Mar 2001 20:38:41 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 19
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

[e-mail] writes:

> Do we need to define a new packet format, V5 for keys?

A V5 key format could address the protocol error with key expiration,
too.

> Or could we keep the old format number and use the length difference
> of a 20-byte HMAC vs a 2-byte checksum to recognize which one is
> being used?

Hmm.  What about introducing a new secret key packet with a hash
instead of a checksum? This approach seems to be much cleaner, and it
doesn't cause surprising problems for the end user.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.9.3/8.9.3) id LAA16523 for ietf-openpgp-bks; Thu, 22 Mar 2001 11:32:14 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16519 for <[e-mail]>; Thu, 22 Mar 2001 11:32:12 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2MJWDP19243 for [e-mail]; Thu, 22 Mar 2001 20:32:13 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Czech attack to PGP
Date: 22 Mar 2001 19:32:12 GMT
Organization: IKS GmbH Jena
Lines: 14
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: belenus.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

* Florian Weimer wrote:
>[e-mail] writes:
>> whenever it decrypts RSA private key data, it does the following checks:
>>    n = p*q

Nope. I'd rejected this to do the more general check recommented in the
smarcard papers: Check the whole cryptosystem (at least the RSA part).
My n=p*q check was driven by a complete other reason: n is used to determine
the blocksize of the result.

>I'm sorry about that.

Yep. I told you it is a bad idea to check only the parts known to be
attackable. Assume an error in mpilib ...


Received: by above.proper.com (8.9.3/8.9.3) id LAA14793 for ietf-openpgp-bks; Thu, 22 Mar 2001 11:03:02 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14788 for <[e-mail]>; Thu, 22 Mar 2001 11:03:00 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14gALy-0006oJ-00 for [e-mail]; Thu, 22 Mar 2001 20:02:34 +0100
To: [e-mail]
Subject: Re: Czech attack to PGP
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 22 Mar 2001 20:02:34 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 18
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

[e-mail] writes:

> The commercial version of PGP, and possibly others, does extra checks on
> RSA private keys which prevent the RSA attack from working.  Specifically,
> whenever it decrypts RSA private key data, it does the following checks:
> 
>    n = p*q

I missed the attacks on the supposedly protected part of the secret
key packet, and n = p*q is the only check performed by GnuPG, so GnuPG
*is* vulnerable against these attacks, despite my claim that is not.

I'm sorry about that.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA14119 for ietf-openpgp-bks; Thu, 22 Mar 2001 10:55:12 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA14113 for <[e-mail]>; Thu, 22 Mar 2001 10:55:07 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA21545 for [e-mail]; Thu, 22 Mar 2001 10:51:30 -0800
Date: Thu, 22 Mar 2001 10:51:30 -0800
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Czech attack to PGP
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 sent this an hour ago but it has not appeared so I'm trying again...]

Links to English language versions of their paper and PowerPoint slides
are at http://www.i.cz/en/.

There are really two different attacks, one for RSA and one for DSA.
Both require modifying your secret key file.  Of course, for most users
this is not an issue.  Any attacker who could get to their secret key
file and modify it would also be able to modify their PGP executable or
public key file and weaken the program in any number of ways.  So the
practical impact of this attack is very low.

However it is very interesting theoretically.  Even though the attack
is relatively easy to see once the idea is raised (several people had
reconstructed the attack just from the press release in the last few
days), it is a new idea and may be applicable to other systems than
OpenPGP.

The RSA attack is the one Lutz called a "Bellcore" attack, based on the
Eurocrypt 97 paper by Boneh et al at
http://theory.stanford.edu/~dabo/papers/faults.ps.gz.
One of the attacks in this paper is against RSA done using the Chinese
Remainder Theorem.  (The authors of the Czech paper attributed the idea
to Arjen Lenstra.)  This optimization of RSA signature involves doing
the calculation twice, mod p and mod q, and then combining the result.
Boneh/Lenstra showed that if you could disrupt one side of this
calculation, the resulting signature would leak the key.

His group was looking at hardware faults, but the Czech group accomplishes
the same thing by perturbing some of the RSA secret parameters so that
one side of the signature is done wrong.  Specifically they change the
last value in the secret key, "u", which is the inverse of p mod q.
This disrupts the part of the CRT calculation which is mod q while
leaving the mod p alone, satisfying the requirement for the Boneh attack.
A simple subtraction and GCD will recover p from the result.

The DSA attack is quite different.  In this case they change the
public parameters of the DSA key to weaken it but leave the private
part alone.  They change p and g to be a group where discrete logs are
easy, one where (p-1) has only small factors.  Then when the signature
is calculated, they can find the secret k value by taking the discrete
log of r, and from this they can calculate the user's secret key.

The commercial version of PGP, and possibly others, does extra checks on
RSA private keys which prevent the RSA attack from working.  Specifically,
whenever it decrypts RSA private key data, it does the following checks:

   n = p*q
   d*e mod p = 1
   d*e mod q = 1
   p*u mod q = 1

This validates all of the private key data and makes sure it is consistent
with the public key values.  In particular the last check prevents the
Czech attack from working as a change to u will make this one fail.

Note that these checks are quite fast, just a few multiplies and
divides, so they do not slow down the signature calculation by much,
since it involves exponentiations.  Unfortunately such fast checks are
not possible for DSA keys.  To validate the parameters two exponentiations
are necessary, while only one exponentiation is used in a DSA signature.
Doing validations will therefore slow down DSA signing by a factor
of three.

The authors of the paper make several recommendations for changes to OpenPGP
to address these kinds of attacks.  They are:

  - Use CBC mode rather than CFB to encrypt private key components
  - Use an HMAC to protect public and private key data
  - Use PSS padding from PKCS-1 v 2.1 rather than the v 1.5 padding

The idea behind using CBC mode is that you can perturb the last block
of data encrypted in CFB in a predictable way; you can XOR any desired
bit pattern into it.  They use this to attack RSA V4 keys.  However,
CBC mode allows similar perturbations, but to the first block rather
than the last block.  So this fix does not go to the heart of the problem
and could still leave vulnerabilities.

The last idea, to use PSS padding, also does not seem to fundamentally
help.  It would still be possible to disrupt the CRC calculation.

The best idea seems to be to replace the current checksum with an HMAC.
This would cover both the private and public components; it would be keyed
based on the passphrase.  Then it would be impossible for an attacker
to alter private key data undetectably unless they knew the passphrase.

Broadly speaking, because the attack requires write access to users'
private keys, I don't think making changes is an urgent matter.
Users need to be careful to protect their private key files in any case.
For most users, if attackers can get at these files they could cause
many other sorts of problems.

However we may want to begin discussing a change to using HMAC in place of
checksum.  We need to agree on exactly what data is covered by the HMAC,
and how the key for the HMAC is calculated from the passphrase (generally
it is a good idea for MAC keys to be different from decryption keys).
Do we need to define a new packet format, V5 for keys?  Or could we keep
the old format number and use the length difference of a 20-byte HMAC
vs a 2-byte checksum to recognize which one is being used?

If we do add an HMAC, software could then work in a mode where old-format
keys get the extra checks applied to carefully validate them, then
get rewritten using the HMAC.  From then on the extra checks are not
necessary and the HMAC alone will detect changes.  So we will retain
fast performance, plus have security against tampered private key files.

Hal Finney


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA11203 for ietf-openpgp-bks; Thu, 22 Mar 2001 09:59:44 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA11199 for <[e-mail]>; Thu, 22 Mar 2001 09:59:42 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA20729 for [e-mail]; Thu, 22 Mar 2001 09:56:11 -0800
Date: Thu, 22 Mar 2001 09:56:11 -0800
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Czech attack to PGP
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>

Links to English language versions of their paper and PowerPoint slides
are at http://www.i.cz/en/.

There are really two different attacks, one for RSA and one for DSA.
Both require modifying your secret key file.  Of course, for most users
this is not an issue.  Any attacker who could get to their secret key
file and modify it would also be able to modify their PGP executable or
public key file and weaken the program in any number of ways.  So the
practical impact of this attack is very low.

However it is very interesting theoretically.  Even though the attack
is relatively easy to see once the idea is raised (several people had
reconstructed the attack just from the press release in the last few
days), it is a new idea and may be applicable to other systems than
OpenPGP.

The RSA attack is the one Lutz called a "Bellcore" attack, based on the
Eurocrypt 97 paper by Boneh et al at
http://theory.stanford.edu/~dabo/papers/faults.ps.gz.
One of the attacks in this paper is against RSA done using the Chinese
Remainder Theorem.  (The authors of the Czech paper attributed the idea
to Arjen Lenstra.)  This optimization of RSA signature involves doing
the calculation twice, mod p and mod q, and then combining the result.
Boneh/Lenstra showed that if you could disrupt one side of this
calculation, the resulting signature would leak the key.

His group was looking at hardware faults, but the Czech group accomplishes
the same thing by perturbing some of the RSA secret parameters so that
one side of the signature is done wrong.  Specifically they change the
last value in the secret key, "u", which is the inverse of p mod q.
This disrupts the part of the CRT calculation which is mod q while
leaving the mod p alone, satisfying the requirement for the Boneh attack.
A simple subtraction and GCD will recover p from the result.

The DSA attack is quite different.  In this case they change the
public parameters of the DSA key to weaken it but leave the private
part alone.  They change p and g to be a group where discrete logs are
easy, one where (p-1) has only small factors.  Then when the signature
is calculated, they can find the secret k value by taking the discrete
log of r, and from this they can calculate the user's secret key.

The commercial version of PGP, and possibly others, does extra checks on
RSA private keys which prevent the RSA attack from working.  Specifically,
whenever it decrypts RSA private key data, it does the following checks:

   n = p*q
   d*e mod p = 1
   d*e mod q = 1
   p*u mod q = 1

This validates all of the private key data and makes sure it is consistent
with the public key values.  In particular the last check prevents the
Czech attack from working as a change to u will make this one fail.

Note that these checks are quite fast, just a few multiplies and
divides, so they do not slow down the signature calculation by much,
since it involves exponentiations.  Unfortunately such fast checks are
not possible for DSA keys.  To validate the parameters two exponentiations
are necessary, while only one exponentiation is used in a DSA signature.
Doing validations will therefore slow down DSA signing by a factor
of three.

The authors of the paper make several recommendations for changes to OpenPGP
to address these kinds of attacks.  They are:

  - Use CBC mode rather than CFB to encrypt private key components
  - Use an HMAC to protect public and private key data
  - Use PSS padding from PKCS-1 v 2.1 rather than the v 1.5 padding

The idea behind using CBC mode is that you can perturb the last block
of data encrypted in CFB in a predictable way; you can XOR any desired
bit pattern into it.  They use this to attack RSA V4 keys.  However,
CBC mode allows similar perturbations, but to the first block rather
than the last block.  So this fix does not go to the heart of the problem
and could still leave vulnerabilities.

The last idea, to use PSS padding, also does not seem to fundamentally
help.  It would still be possible to disrupt the CRC calculation.

The best idea seems to be to replace the current checksum with an HMAC.
This would cover both the private and public components; it would be keyed
based on the passphrase.  Then it would be impossible for an attacker
to alter private key data undetectably unless they knew the passphrase.

Broadly speaking, because the attack requires write access to users'
private keys, I don't think making changes is an urgent matter.
Users need to be careful to protect their private key files in any case.
For most users, if attackers can get at these files they could cause
many other sorts of problems.

However we may want to begin discussing a change to using HMAC in place of
checksum.  We need to agree on exactly what data is covered by the HMAC,
and how the key for the HMAC is calculated from the passphrase (generally
it is a good idea for MAC keys to be different from decryption keys).
Do we need to define a new packet format, V5 for keys?  Or could we keep
the old format number and use the length difference of a 20-byte HMAC
vs a 2-byte checksum to recognize which one is being used?

If we do add an HMAC, software could then work in a mode where old-format
keys get the extra checks applied to carefully validate them, then
get rewritten using the HMAC.  From then on the extra checks are not
necessary and the HMAC alone will detect changes.  So we will retain
fast performance, plus have security against tampered private key files.

Hal Finney


Received: by above.proper.com (8.9.3/8.9.3) id JAA11119 for ietf-openpgp-bks; Thu, 22 Mar 2001 09:58:46 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11115 for <[e-mail]>; Thu, 22 Mar 2001 09:58:45 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14g9Ln-0006aU-00 for [e-mail]; Thu, 22 Mar 2001 18:58:19 +0100
To: [e-mail]
Subject: Re: Bellcore Attack
References: <5.0.0.25.2.20010322092502.03703b40@127.0.0.1> <5.0.0.25.2.20010322090310.035b4200@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010321175456.032d54d0@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010322090310.035b4200@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010322092502.03703b40@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010322093203.03674b80@127.0.0.1> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 22 Mar 2001 18:58:18 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 40
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

Lutz Donnerhacke <[e-mail]> writes:

> > >  PGP2.6.3(i)n is fixed against all those types of attacks (and I had
> > >a look on buffer overflows).
> 
> > you should mention that on the ietf open pgp list.
> 
> I posted the announcement some minutes ago to the usenet.
> OK. CC: ML
> 
> ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/pgp263in/

I've just decided that I won't implement a similar check for the DSA
case (actually, I've implemented it already, but I won't recommend its
use).  The situation is much too murky.  Maybe a relative proof of
security can be obtained, but I very much doubt it.  (Peter Gutmann
told me about a different attack against unprotected DSA parameters,
the whole situation doesn't look very promising at all.) IMHO, the
problem can only be addressed in a safe way if the format is changed.
Implementations can already do this on their own, of course, but
there's still the problem that the standard is really misleading in
this area.

Unfortunately, this is not the first problem due to the attempt to
minimize the amount of data which is cryptographically protected, a
rather questionable design goal.  It's not hard to spot the pattern in
the list of past problems with OpenPGP and OpenPGP-derived
protocols. :-(

BTW: With RSA keys, GnuPG is not as reliable as it could be (it
doesn't check the computed signatures and performs only a simple
consistency check), but it's not vulnerable to the described attack.
The situation is much better with RSA keys anyway because the secret
key packet contains all necessary information in the encrypted area.
I whish it were true for DSA as well. :-/

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.9.3/8.9.3) id HAA01139 for ietf-openpgp-bks; Thu, 22 Mar 2001 07:58:01 -0800 (PST)
Received: from excalibur.iks-jena.de ([e-mail] [217.17.192.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01134 for <[e-mail]>; Thu, 22 Mar 2001 07:57:59 -0800 (PST)
Received: from taranis.iks-jena.de (taranis.iks-jena.de [217.17.192.37]) by excalibur.iks-jena.de (8.11.3/8.10.1) with ESMTP id f2MFw0V09791; Thu, 22 Mar 2001 16:58:00 +0100
Received: (from lutz@localhost) by taranis.iks-jena.de (8.11.3/8.10.1) id f2MFt1M01885; Thu, 22 Mar 2001 16:55:01 +0100
Date: Thu, 22 Mar 2001 16:55:00 +0100
From: Lutz Donnerhacke <[e-mail]>
To: Rodney Thayer <[e-mail]>
Cc: [e-mail]
Subject: Re: Bellcore Attack
Message-ID: <[e-mail]>
References: <5.0.0.25.2.20010322092502.03703b40@127.0.0.1> <5.0.0.25.2.20010322090310.035b4200@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010321175456.032d54d0@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010322090310.035b4200@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010322092502.03703b40@127.0.0.1> <[e-mail]> <5.0.0.25.2.20010322093203.03674b80@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.2.20010322093203.03674b80@127.0.0.1>; from [e-mail] on Thu, Mar 22, 2001 at 09:32:23AM -0600
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>

> >  PGP2.6.3(i)n is fixed against all those types of attacks (and I had
> >a look on buffer overflows).

> you should mention that on the ietf open pgp list.

I posted the announcement some minutes ago to the usenet.
OK. CC: ML

ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/pgp263in/


Received: by above.proper.com (8.9.3/8.9.3) id EAA11324 for ietf-openpgp-bks; Thu, 22 Mar 2001 04:22:39 -0800 (PST)
Received: from excalibur.iks-jena.de ([e-mail] [217.17.192.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA11320 for <[e-mail]>; Thu, 22 Mar 2001 04:22:37 -0800 (PST)
Received: from taranis.iks-jena.de (taranis.iks-jena.de [217.17.192.37]) by excalibur.iks-jena.de (8.11.3/8.10.1) with ESMTP id f2MCMbV29371; Thu, 22 Mar 2001 13:22:37 +0100
Received: (from lutz@localhost) by taranis.iks-jena.de (8.11.3/8.10.1) id f2MCJdF01094; Thu, 22 Mar 2001 13:19:39 +0100
Date: Thu, 22 Mar 2001 13:19:39 +0100
From: Lutz Donnerhacke <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
Posted-To: de.comp.security.misc,sci.crypt
Subject: Re: Czech attack to PGP
References: <[e-mail]> <[e-mail]>
Organization: IKS GmbH Jena
Followup-To: sci.crypt
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 message has also been posted.]
* Florian Weimer wrote:
>They seem to, see http://www.i.cz/pdf/pgp/OpenPGP_attack_CZ.pdf.  It's

Great work.

>informative even if you cannot read Czech (there's one diagram showing
>the secret key packet modification, which is quite instructive).  Was

Yes, it is.

>The attack is rather obvious, I have to say.

Of course, every good idea is obvious afterwards.

>I'm still working on a fix.

Assuming a bellcore attack I suggested to check it against the public key,
but there is a problem: If the major modulus of the public key is shrinked
and access to the files is assumed, there is no real reason to modify the
public key accordingly in order to fool even all the certificate checks on
my own keys. So this solution does not work.

For RSA we can fix it by regenerating the public part from the encrypted
private ones and stop working if this check failes. Afterwards we should
check the signature by the verified public key. I'll do so for PGP2.6.3(i)n.

>The basic question is: Is it possible to create a set of public DSA
>parameters which are consistent with the secret one, without knowing the
>latter?

We could check if y = g**x mod p. If p and g are not trivial (check this!)
and x is assumed to be not published before this signing attempt, there
might be a chance to prevent a format modification.

OTOH, we do not relay on a modifiction anyway, the programms are free to
choose any secret key storage format the like.


Received: by above.proper.com (8.9.3/8.9.3) id DAA10097 for ietf-openpgp-bks; Thu, 22 Mar 2001 03:49:33 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA10089 for <[e-mail]>; Thu, 22 Mar 2001 03:49:31 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14g3aS-0005fu-00 for [e-mail]; Thu, 22 Mar 2001 12:49:04 +0100
To: [e-mail]
Subject: Re: Algorithm Specific Fields for DSA secret keys
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 22 Mar 2001 12:49:04 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 35
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

[e-mail] (Lutz Donnerhacke) writes:

> * Florian Weimer wrote:
> >Okay, I missed this one.  I thought the public key components were also
> >cryptographically protected.  May I assume that the i.cz attack is target
> >against the unprotected public key part of the secret key packet?  Such an
> >attack seems feasible.
> 
> If they do so, the attack will be /very/ interesting.

They seem to, see http://www.i.cz/pdf/pgp/OpenPGP_attack_CZ.pdf.  It's
informative even if you cannot read Czech (there's one diagram showing
the secret key packet modification, which is quite instructive).  Was
this information available to the Minneapolis meeting?  What were
their conclusions?

The attack is rather obvious, I have to say.  Before I read Hal's
reply, I assumed that all data needed for signature generation was
protected by the passphrase.  I was really surprised when I discovered
that it wasn't (at least in the DSA case, however, if you do RSA using
the Chinese Remainder theorem, it is), and I was far less surprised
when I finally found the paper and confirmed that the attack is
mounted against the unprotected portion of the secret key.

I'm still working on a fix.  The basic question is: Is it possible to
create a set of public DSA parameters which are consistent with the
secret one, without knowing the latter?  If the answer is yes, we have
to modify the OpenPGP format, otherwise, a consistency check is
sufficient to protect against this attack.  (The consistency check
performed by GnuPG is probably not sufficient.)

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.9.3/8.9.3) id CAA02664 for ietf-openpgp-bks; Thu, 22 Mar 2001 02:54:43 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA02659 for <[e-mail]>; Thu, 22 Mar 2001 02:54:41 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2MAseX00538 for [e-mail]; Thu, 22 Mar 2001 11:54:40 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Algorithm Specific Fields for DSA secret keys
Date: 22 Mar 2001 10:54:39 GMT
Organization: IKS GmbH Jena
Lines: 7
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

* Florian Weimer wrote:
>Okay, I missed this one.  I thought the public key components were also
>cryptographically protected.  May I assume that the i.cz attack is target
>against the unprotected public key part of the secret key packet?  Such an
>attack seems feasible.

If they do so, the attack will be /very/ interesting.


Received: by above.proper.com (8.9.3/8.9.3) id CAA02052 for ietf-openpgp-bks; Thu, 22 Mar 2001 02:47:42 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA02046 for <[e-mail]>; Thu, 22 Mar 2001 02:47:41 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14g2cc-0005Xv-00 for [e-mail]; Thu, 22 Mar 2001 11:47:14 +0100
To: [e-mail]
Subject: Re: Algorithm Specific Fields for DSA secret keys
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 22 Mar 2001 11:47:14 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 23
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

[e-mail] writes:

> If you look at the whole section, it says,
> 
> 5.5.3. Secret Key Packet Formats
> 
>    The Secret Key and Secret Subkey packets contain all the data of the
>    Public Key and Public Subkey packets, with additional algorithm-
>    specific secret key data appended, in encrypted form.
> 
>    The packet contains:
> 
>      - A Public Key or Public Subkey packet, as described above

Okay, I missed this one.  I thought the public key components were
also cryptographically protected.  May I assume that the i.cz attack
is target against the unprotected public key part of the secret key
packet?  Such an attack seems feasible.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.9.3/8.9.3) id AAA11607 for ietf-openpgp-bks; Thu, 22 Mar 2001 00:03:21 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA11595 for <[e-mail]>; Thu, 22 Mar 2001 00:03:19 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2M83I427365 for [e-mail]; Thu, 22 Mar 2001 09:03:18 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Bellcore Attack
Date: 22 Mar 2001 08:03:18 GMT
Organization: IKS GmbH Jena
Lines: 9
Message-ID: <[e-mail]>
References: <[e-mail]> <p04320401b6defa7ed7e3@[172.20.1.38]>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

* Jon Callas wrote:
>The gist, as much as we know of it now is that they claim that they can
>write into a V3 secret key (the PGP 2.6 format) in such a way as to force
>you to make signatures that the attacker can then forge. We don't know the

That seems resonable: Modifying the least significant in the last crypted
secret key component can be used (in conjunction with the chipher feedback
mode) to determine the necessary checksum fooling PGP integrity checks. It
might be possible to extend this to v4 keys too.


Received: by above.proper.com (8.9.3/8.9.3) id XAA10589 for ietf-openpgp-bks; Wed, 21 Mar 2001 23:58:15 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA10577 for <[e-mail]>; Wed, 21 Mar 2001 23:58:13 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2M7wBL27323 for [e-mail]; Thu, 22 Mar 2001 08:58:11 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Bellcore Attack
Date: 22 Mar 2001 07:58:11 GMT
Organization: IKS GmbH Jena
Lines: 5
Message-ID: <[e-mail]>
References: <[e-mail]> <5.0.0.25.2.20010321175456.032d54d0@127.0.0.1>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

* Rodney Thayer wrote:
>what is the reference to calling this a "Bellcore attack"?

I did. There was no reference, but only the Bellcore attack or a substantial
new type of attack seems a valid assumption to me.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA23431 for ietf-openpgp-bks; Wed, 21 Mar 2001 20:36:24 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA23427 for <[e-mail]>; Wed, 21 Mar 2001 20:36:23 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012097.qualcomm.com [10.13.12.97]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2M4aKV14821; Wed, 21 Mar 2001 20:36:21 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <a05100705b6df29654662@[135.222.66.224]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Wed, 21 Mar 2001 22:31:24 -0600
To: [e-mail]
From: John  W Noerenberg II <[e-mail]>
Subject: OpenPGP minutes
Cc: OpenPGP mailing list <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1226886708==_ma============"
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>

--============_-1226886708==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

We met on Tuesday afternoon, Mar 20th with the following agenda:

=85 Agenda bashing
=85 Pgp/MIME
=85 Openpgp oven cooking competition
=85 Pgp consortium
=85 Charter review
=85 Wg->fin_wait

Rod Thayer took down the minutes.  This message is derived from his notes.

There were no changes to the agenda so we proceeded with the remaining items=
=2E

The PGP/MIME draft is ready for WG Last Call.  The Chair expects the 
WG will be able to recommend the draft to the IESG within a month. 
John Noerenberg noticed a normative reference to the multiple 
signature draft.  He recommended removing the reference, but formally 
adopting multiple signatures as an additional work item.

The Chair is planning to sponsor an interoperability testing meeting 
in San Diego in late Spring or early Summer.  There are notes on the 
mailing list regarding a general plan for the meeting.  The principal 
goal of the meeting is to assess whether there are sufficiently 
interoperable implementations of RFC2440 to allow the WG to recommend 
RFC2440 advance to DRAFT status.  The workshop will also provide the 
opportunity to test PGP/MIME implementations and transport and 
network protocols which use PGP encryption and authentication.

The Chair announced that Phil Zimmerman is organizing a PGP 
Consortium for implementers and users.  The url for the consortium is 
http://www.openpgp.org.

Adopting multiple signatures as a work item will require a change to 
WG charter.  The WG members in attendance did not express a strong 
opinion in either direction. [Because of activity on the mailing list 
the Chair plans to request the IESG allow modification of the charter 
to add this item.]

Whether or not this item is added to our charter, we expect the WG to 
shut down by the next IETF meeting.

That completed the business of the meeting, and we adjourned.

-- 

john noerenberg
[e-mail]
   -------------------------------------------------------------------------=
-
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   -------------------------------------------------------------------------=
-
--============_-1226886708==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D""><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>OpenPGP minutes</title></head><body>
<div><font color=3D"#000000">We met on Tuesday afternoon, Mar 20th with
the following agenda:</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font face=3D"Charcoal" color=3D"#000000">=85</font><font
color=3D"#000000"> Agenda bashing</font></div>
<div><font face=3D"Charcoal" color=3D"#000000">=85</font><font
color=3D"#000000"> Pgp/MIME</font></div>
<div><font face=3D"Charcoal" color=3D"#000000">=85</font><font
color=3D"#000000"> Openpgp oven cooking competition</font></div>
<div><font face=3D"Charcoal" color=3D"#000000">=85</font><font
color=3D"#000000"> Pgp consortium<br>
<font face=3D"Charcoal">=85</font> Charter review<br>
<font face=3D"Charcoal">=85</font> Wg-&gt;fin_wait</font><br>
<font color=3D"#000000"></font></div>
<div><font color=3D"#000000">Rod Thayer took down the minutes.&nbsp;
This message is derived from his notes.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">There were no changes to the agenda so we
proceeded with the remaining items.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">The PGP/MIME draft is ready for WG Last
Call.&nbsp; The Chair expects the WG will be able to recommend the
draft to the IESG within a month.&nbsp; John Noerenberg noticed a
normative reference to the multiple signature draft.&nbsp; He
recommended removing the reference, but formally adopting multiple
signatures as an additional work item.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">The Chair is planning to sponsor an
interoperability testing meeting in San Diego in late Spring or early
Summer.&nbsp; There are notes on the mailing list regarding a general
plan for the meeting.&nbsp; The principal goal of the meeting is to
assess whether there are sufficiently interoperable implementations of
RFC2440 to allow the WG to recommend RFC2440 advance to DRAFT status.&nbsp;
The workshop will also provide the opportunity to test PGP/MIME
implementations and transport and network protocols which use PGP
encryption and authentication.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">The Chair announced that Phil Zimmerman is
organizing a PGP Consortium for implementers and users.&nbsp; The url
for the consortium is&nbsp; http://www.openpgp.org.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">Adopting multiple signatures as a work item
will require a change to WG charter.&nbsp; The WG members in
attendance did not express a strong opinion in either direction.
[Because of activity on the mailing list the Chair plans to request
the IESG allow modification of the charter to add this
item.]</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">Whether or not this item is added to our
charter, we expect the WG to shut down by the next IETF
meeting.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">That completed the business of the meeting,
and we adjourned.</font></div>
<div><tt><br></tt></div>
<x-sigsep><pre>
-- 
</pre></x-sigsep>
<div><br>
john noerenberg<br>
[e-mail]<br>
&nbsp;
---------------------------------------------------------------------<span
></span>-----<br>
&nbsp; Peace of mind isn't at all superficial, really.&nbsp; It's the
whole thing.<br>
&nbsp; That which produces it is good maintenance; that which disturbs
it<br>
&nbsp; is poor maintenance.<br>
&nbsp; -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig,
1974<br>
&nbsp;
---------------------------------------------------------------------<span
></span>-----</div>
</body>
</html>
--============_-1226886708==_ma============--


Received: by above.proper.com (8.9.3/8.9.3) id UAA23425 for ietf-openpgp-bks; Wed, 21 Mar 2001 20:36:21 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA23419 for <[e-mail]>; Wed, 21 Mar 2001 20:36:16 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012097.qualcomm.com [10.13.12.97]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2M4aCV14815; Wed, 21 Mar 2001 20:36:13 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <a05100703b6df2800f5c5@[135.222.66.224]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Wed, 21 Mar 2001 21:58:32 -0600
To: [e-mail] (Lutz Donnerhacke)
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Bellcore Attack
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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 10:59 AM +0000 3/21/01, Lutz Donnerhacke wrote:
>According to the current Comp.Risks Digest, a Bellcore attack seems possible
>due to the OpenPGP secret key format.

Yes, Lutz.  There has been a fair amount of discussion here in 
Minneapolis regarding the discovery by the Czech researchers.  I'll 
leave the detailed analysis to others to publish, but at this point 
it appears this attack does not appear to pose a significant threat 
to the integrity of information encrypted with PGP.

-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.9.3/8.9.3) id SAA19845 for ietf-openpgp-bks; Wed, 21 Mar 2001 18:27:13 -0800 (PST)
Received: from acm.org ([192.88.122.192]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19841 for <[e-mail]>; Wed, 21 Mar 2001 18:27:12 -0800 (PST)
Received: from acm.org (IDENT:jim@suitcase [127.0.0.1]) by acm.org (8.11.0/8.11.0) with ESMTP id f2M2Nt207631 for <[e-mail]>; Wed, 21 Mar 2001 18:23:55 -0800
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2001 18:23:55 -0800
From: Jim Gillogly <[e-mail]>
Organization: Banzai Institute
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0-ac8 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Bellcore Attack
References: <5.0.0.25.2.20010321175456.032d54d0@127.0.0.1>
Content-Type: text/plain; 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>

Rodney Thayer wrote:

> what is the reference to calling this a "Bellcore attack"?

"On the importance of Checking Cryptographic Protocols for Faults"
  Dan Boneh, Richard A. DeMillo, Richard J. Lipton, Bellcore 1997.

See http://citeseer.nj.nec.com/correct/21216, for example.
They break RSA using one bogus signature and the Chinese
Remainder Theorem.  This was the inspiration for the whole
field of differential fault analysis.

-- 
	Jim Gillogly
	Highday, 30 Rethe S.R. 2001, 02:18
	12.19.8.1.5, 12 Chicchan 8 Cumku, Seventh Lord of Night


Received: by above.proper.com (8.9.3/8.9.3) id SAA19624 for ietf-openpgp-bks; Wed, 21 Mar 2001 18:12:35 -0800 (PST)
Received: from limbo.net (IDENT:[e-mail] [209.209.9.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19619 for <[e-mail]>; Wed, 21 Mar 2001 18:12:32 -0800 (PST)
Received: from opcenter2.tillerman.to (IDENT:[e-mail] [216.240.42.201]) by limbo.net (8.9.3/8.9.0) with ESMTP id SAA01350; Wed, 21 Mar 2001 18:12:29 -0800
Message-Id: <5.0.0.25.2.20010321175456.032d54d0@127.0.0.1>
X-Sender: rodney@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 21 Mar 2001 17:55:33 -0600
To: [e-mail] (Lutz Donnerhacke)
From: Rodney Thayer <[e-mail]>
Subject: Re: Bellcore Attack
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain
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

what is the reference to calling this a "Bellcore attack"?

At 10:59 AM 3/21/01 +0000, you wrote:
>According to the current Comp.Risks Digest, a Bellcore attack seems possible
>due to the OpenPGP secret key format.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA+AwUBOrk/dT/0TyQ4fTjtEQJCAwCYs4tMm8AOn5tMs5W1BAzirS1nsgCeJ0MD
LfPL6N1FmNMYXg9VeXNWM8A=
=a4KE
-----END PGP SIGNATURE-----



Received: by above.proper.com (8.9.3/8.9.3) id QAA15422 for ietf-openpgp-bks; Wed, 21 Mar 2001 16:51:33 -0800 (PST)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA15418 for <[e-mail]>; Wed, 21 Mar 2001 16:51:31 -0800 (PST)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id QAA06408; Wed, 21 Mar 2001 16:51:34 -0800 (PST)
Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id QAA06400; Wed, 21 Mar 2001 16:51:32 -0800 (PST)
Mime-Version: 1.0
X-Sender: jon@63.73.97.162
Message-Id: <p04320401b6defa7ed7e3@[172.20.1.38]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 21 Mar 2001 16:51:25 -0800
To: [e-mail] (Lutz Donnerhacke), [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Bellcore Attack
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>

You can see the press release at <http://www.i.cz/en/onas/tisk4.html>.
There are also things in Czech on their web site. Supposedly, the details
will be published tomorrow.

The gist, as much as we know of it now is that they claim that they can
write into a V3 secret key (the PGP 2.6 format) in such a way as to force
you to make signatures that the attacker can then forge. We don't know the
details yet. They only want to talk to reporters, not to technical people.
All the details I have are ones I wheedled out of reporters. I sent mail to
the contact on the press release yesterday who said that we have to wait
like everyone else. Some mail today going directly to the cryptographers
involved got a reply that said they'll publish tomorrow. So we'll see.

	Jon


Received: by above.proper.com (8.9.3/8.9.3) id PAA12697 for ietf-openpgp-bks; Wed, 21 Mar 2001 15:57:41 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA12691 for <[e-mail]>; Wed, 21 Mar 2001 15:57:38 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA12957; Wed, 21 Mar 2001 15:54:04 -0800
Date: Wed, 21 Mar 2001 15:54:04 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Algorithm Specific Fields for DSA secret keys
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>

If you look at the whole section, it says,

5.5.3. Secret Key Packet Formats

   The Secret Key and Secret Subkey packets contain all the data of the
   Public Key and Public Subkey packets, with additional algorithm-
   specific secret key data appended, in encrypted form.

   The packet contains:

     - A Public Key or Public Subkey packet, as described above

     - One octet indicating string-to-key usage conventions.  0
       indicates that the secret key data is not encrypted.  255
       indicates that a string-to-key specifier is being given.  Any
       other value is a symmetric-key encryption algorithm specifier.

     - [Optional] If string-to-key usage octet was 255, a one-octet
       symmetric encryption algorithm.

     - [Optional] If string-to-key usage octet was 255, a string-to-key
       specifier.  The length of the string-to-key specifier is implied
       by its type, as described above.

     - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

     - Encrypted multi-precision integers comprising the secret key
       data. These algorithm-specific fields are as described below.

     - Two-octet checksum of the plaintext of the algorithm-specific
       portion (sum of all octets, mod 65536).

and then it goes on to explain the algorithm-specific fields mentioned
in the second to last paragraph.  But note that the very first entry
is a whole Public Key packet.  This has the p, q, g and y values.
Then come the other entries: string-to-key usage octet, encryption octet,
string-to-key specifier, iv, and then the algorithmic-specific private
fields you saw.  Finally a checksum.

Hal


Received: by above.proper.com (8.9.3/8.9.3) id PAA09774 for ietf-openpgp-bks; Wed, 21 Mar 2001 15:17:35 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA09769 for <[e-mail]>; Wed, 21 Mar 2001 15:17:34 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14frqm-0004eh-00 for [e-mail]; Thu, 22 Mar 2001 00:17:08 +0100
To: [e-mail]
Subject: Algorithm Specific Fields for DSA secret keys
From: Florian Weimer <[e-mail]>
Date: 22 Mar 2001 00:17:08 +0100
Message-ID: <[e-mail]>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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>

>From section 5.5.3:

|       Algorithm Specific Fields for DSA secret keys:
|
|       - MPI of DSA secret exponent x.

And that's it.

As far as I can tell, implementations do not follow the RFC (GnuPG,
for example, stores p, q, g, u, and finally x, in this order).

Has anybody got an explanation?

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.9.3/8.9.3) id CAA13064 for ietf-openpgp-bks; Wed, 21 Mar 2001 02:59:20 -0800 (PST)
Received: from grannus.iks-jena.de ([e-mail] [217.17.192.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA13058 for <[e-mail]>; Wed, 21 Mar 2001 02:59:17 -0800 (PST)
Received: (from news@localhost) by grannus.iks-jena.de (8.11.3/8.10.1) id f2LAxG915988 for [e-mail]; Wed, 21 Mar 2001 11:59:16 +0100
To: [e-mail]
Path: lutz
From: [e-mail] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Bellcore Attack
Date: 21 Mar 2001 10:59:16 GMT
Organization: IKS GmbH Jena
Lines: 2
Message-ID: <[e-mail]>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (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>

According to the current Comp.Risks Digest, a Bellcore attack seems possible
due to the OpenPGP secret key format.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA13985 for ietf-openpgp-bks; Tue, 20 Mar 2001 23:14:12 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA13977 for <[e-mail]>; Tue, 20 Mar 2001 23:14:11 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012034.qualcomm.com [10.13.12.34]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2L7E4V09165; Tue, 20 Mar 2001 23:14:06 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <a05100600b6dd999e3551@[135.222.66.224]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 20 Mar 2001 22:11:06 -0600
To: Thomas Roessler <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: draft-ietf-openpgp-mime: normative reference to multiple signature draft
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1226963646==_ma============"
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>

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

There's a normative reference in Sec 5 to draft-ietf-multsig-00.txt. 
In order to advanced to PROPOSED, we'd either have to be ready to 
advance the multsig draft, or eliminate the reference.  What I 
propose is that we eliminate the specific reference here, and advance 
multiple signatures independently.  This way involves the fewest 
dependencies.

Here's the specific text:

To encapsulate multiple signatures with possibly different hash 
algorithms, the method specified in [8] should be used.

[8] in the references is "draft-ietf-openpgp-multsig-02.txt". 
Probably simplest is to delete the sentence, and reference [8].

The multiple signatures draft looks pretty straight-forward.  Unless 
I hear loud objections, I'll ask the IESG if we can modify our 
charter to include it in our work items.  There hasn't been much 
discussion of this draft for some time.  However, because it's not on 
our charter, we have to change the charter before I can submit it for 
consideration as PROPOSED, and I do want to allow some time for Last 
Call after it's on our charter.

Because pgp/mime will be ready shortly to advance, I'd rather not 
have to wait for approval to change our charter before pgp/mime can 
advance.  Once we have both multsig and pgp/mime at PROPOSED, if both 
are ready to advance to DRAFT, we can restore the reference in 
pgp/mime to multsig.


-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------
--============_-1226963646==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=""><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft-ietf-openpgp-mime: normative reference to
multip</title></head><body>
<div>There's a normative reference in Sec 5 to
draft-ietf-multsig-00.txt.&nbsp; In order to advanced to PROPOSED,
we'd either have to be ready to advance the multsig draft, or
eliminate the reference.&nbsp; What I propose is that we eliminate the
specific reference here, and advance multiple signatures
independently.&nbsp; This way involves the fewest dependencies.</div>
<div><br></div>
<div>Here's the specific text:</div>
<div><br></div>
<blockquote>To encapsulate multiple signatures with possibly different
hash algorithms, the method specified in [8] should be
used.</blockquote>
<div><br></div>
<div>[8] in the references is
&quot;draft-ietf-openpgp-multsig-02.txt&quot;.&nbsp; Probably simplest
is to delete the sentence, and reference [8].</div>
<div><br></div>
<div>The multiple signatures draft looks pretty straight-forward.&nbsp;
Unless I hear loud objections, I'll ask the IESG if we can modify our
charter to include it in our work items.&nbsp; There hasn't been much
discussion of this draft for some time.&nbsp; However, because it's
not on our charter, we have to change the charter before I can submit
it for consideration as PROPOSED, and I do want to allow some time for
Last Call after it's on our charter.</div>
<div><br></div>
<div>Because pgp/mime will be ready shortly to advance, I'd rather not
have to wait for approval to change our charter before pgp/mime can
advance.&nbsp; Once we have both multsig and pgp/mime at PROPOSED, if
both are ready to advance to DRAFT, we can restore the reference in
pgp/mime to multsig.</div>
<div><tt><br></tt></div>
<div><tt><br></tt></div>
<x-sigsep><pre>
-- 
</pre></x-sigsep>
<div><br>
john noerenberg<br>
[e-mail]<br>
&nbsp;
---------------------------------------------------------------------<span
></span>-----<br>
&nbsp; Peace of mind isn't at all superficial, really.&nbsp; It's the
whole thing.<br>
&nbsp; That which produces it is good maintenance; that which disturbs
it<br>
&nbsp; is poor maintenance.<br>
&nbsp; -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig,
1974<br>
&nbsp;
---------------------------------------------------------------------<span
></span>-----</div>
</body>
</html>
--============_-1226963646==_ma============--


Received: by above.proper.com (8.9.3/8.9.3) id XAA13927 for ietf-openpgp-bks; Tue, 20 Mar 2001 23:13:58 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA13917 for <[e-mail]>; Tue, 20 Mar 2001 23:13:57 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012034.qualcomm.com [10.13.12.34]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2L7E0V09153 for <[e-mail]>; Tue, 20 Mar 2001 23:14:00 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <a05100601b6ddd3bbb677@[135.222.66.224]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 20 Mar 2001 21:55:34 -0600
To: [e-mail]
From: John  W Noerenberg II <[e-mail]>
Subject: WG Last Call - draft-ietf-openpgp-mime
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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 the Last Call for WG comments on draft-ietf-openpgp-mime. 
Please carefully review the current draft (-05), and provide comments 
to the editors if you detect any errors or omissions.  I will end 
Last Call on April 3rd.  If there are no substantial changes or 
objections to the draft, I will request our Area Directors submit -06 
incorporating Last Call comments as soon as possible after that date 
for promotion to PROPROSED status.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA11737 for ietf-openpgp-bks; Tue, 20 Mar 2001 11:53:28 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11732 for <[e-mail]>; Tue, 20 Mar 2001 11:53:26 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012064.qualcomm.com [10.13.12.64]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2KJrQV23176 for <[e-mail]>; Tue, 20 Mar 2001 11:53:26 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <a05100600b6dd5e177d4d@[135.222.66.224]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 20 Mar 2001 13:37:46 -0600
To: OpenPGP mailing list <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Today's agenda
Content-Type: multipart/alternative; boundary="============_-1227004487==_ma============"
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>

--============_-1227004487==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

Please pardon me for not publishing our agenda for today's meeting 
earlier.  this is how I plan to spend our hour today:

Agenda bashing (5 min)
PGP/MIME Last Call (15 min)
OpenPGP Oven Cooking Competition (10m)
PGP Consortium (10 min)
Charter review (0-15min)
WG =C6 Fin_Wait (5 min)

As I read the PGP/MIME draft, and looking at the comments on this 
mailing list, I don't see any serious obstacles to declaring WG Last 
Call for the draft (modulo my note below).  But I'll allow a brief 
discussion to be sure I'm not misunderstanding consensus.

The Oven Cooking Competition is the work we need to do to advance 
2440 to DRAFT status.  It will also enable us to do most of the 
verification work we'll need for DRAFT status on PGP/MIME (which is 
getting a little ahead of ourselves, but I don't think this is a big 
deal in this case).

I promised Phil I would mention his idea about a PGP Consortium, and 
take the opportunity for those of us in Minneapolis to register an 
opinion.

The charter review is necessary because our charter doesn't include 
milestones for PGP/MIME, curiously enough.  Also we need to determine 
what to do about multiple signatures draft on which the PGP/MIME 
draft depends. PGP/MIME may not be able to advanced to PROPOSED 
status if it contains this reference.  Updating the milestones to 
reflect where we stand on PGP/MIME is a no-brainer, but adding 
Multiple Sigs will require IESG approval to expand our scope.  I'll 
be looking for a hum today on how desirable this is, as well as 
comments from the list.

It's entirely possible we'll get through all of this in less than an 
hour.  My apologies for not arranging for an MBone room to enable 
those not here to participate "live."

best,

-- 

john noerenberg
[e-mail]
   ----------------------------------------------------------------------
   Perfect authentication would mean that others know for certain all the
   facts about you.  Happiness comes from others knowing a good deal less.
   -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999
   ----------------------------------------------------------------------
--============_-1227004487==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D""><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Today's agenda</title></head><body>
<div>Please pardon me for not publishing our agenda for today's
meeting earlier.&nbsp; this is how I plan to spend our hour
today:</div>
<div><br></div>
<ul>
<li>Agenda bashing (5 min)
<li>PGP/MIME Last Call (15 min)
<li>OpenPGP Oven Cooking Competition (10m)
<li>PGP Consortium (10 min)
<li>Charter review (0-15min)
<li>WG<font face=3D"Charcoal"> =C6</font> Fin_Wait (5 min)</ul>
<div><br></div>
<div>As I read the PGP/MIME draft, and looking at the comments on this
mailing list, I don't see any serious obstacles to declaring WG Last
Call for the draft (modulo my note below).&nbsp; But I'll allow a
brief discussion to be sure I'm not misunderstanding consensus.</div>
<div><br></div>
<div>The Oven Cooking Competition is the work we need to do to advance
2440 to DRAFT status.&nbsp; It will also enable us to do most of the
verification work we'll need for DRAFT status on PGP/MIME (which is
getting a little ahead of ourselves, but I don't think this is a big
deal in this case).</div>
<div><br></div>
<div>I promised Phil I would mention his idea about a PGP Consortium,
and take the opportunity for those of us in Minneapolis to register an
opinion.</div>
<div><br></div>
<div>The charter review is necessary because our charter doesn't
include milestones for PGP/MIME, curiously enough.&nbsp; Also we need
to determine what to do about multiple signatures draft on which the
PGP/MIME draft depends. PGP/MIME may not be able to advanced to
PROPOSED status if it contains this reference.&nbsp; Updating the
milestones to reflect where we stand on PGP/MIME is a no-brainer, but
adding Multiple Sigs will require IESG approval to expand our scope.&nbsp;
I'll be looking for a hum today on how desirable this is, as well as
comments from the list.</div>
<div><br></div>
<div>It's entirely possible we'll get through all of this in less than
an hour.&nbsp; My apologies for not arranging for an MBone room to
enable those not here to participate &quot;live.&quot;</div>
<div><br></div>
<div>best,</div>
<div><tt><br></tt></div>
<x-sigsep><pre>
-- 
</pre></x-sigsep>
<div><br>
john noerenberg<br>
[e-mail]<br>
&nbsp;
----------------------------------------------------------------------<br
>
&nbsp; Perfect authentication would mean that others know for certain
all the<br>
&nbsp; facts about you.&nbsp; Happiness comes from others knowing a
good deal less.<br>
&nbsp; -- Lawrence Lessig, &quot;Code And Other Laws of
Cyberspace&quot;, 1999<br>
&nbsp;
----------------------------------------------------------------------</div
>
</body>
</html>
--============_-1227004487==_ma============--


Received: by above.proper.com (8.9.3/8.9.3) id JAA05315 for ietf-openpgp-bks; Tue, 20 Mar 2001 09:33:19 -0800 (PST)
Received: from hotmail.com (oe2.law14.hotmail.com [64.4.20.106]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05309 for <[e-mail]>; Tue, 20 Mar 2001 09:33:18 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Mar 2001 09:32:50 -0800
X-Originating-IP: [193.95.161.82]
From: "Donald" <[e-mail]>
To: <[e-mail]>
Subject: key flags and subkeys
Date: Tue, 20 Mar 2001 17:36:35 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0043_01C0B164.4F463120"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Mar 2001 17:32:50.0679 (UTC) FILETIME=[C97EE870:01C0B163]
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 is a multi-part message in MIME format.

------=_NextPart_000_0043_01C0B164.4F463120
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Nothing is said about whether the key flags of a certification
is valid for that main key or for main key plus subkeys as an item.
PGP don't even have a mechanism for doing any kind of certification
of a subkey.

I do know that a subkey may be exchanged/added at a later stage than the
certification is made, and in particular is not input to a certification
signature, but I still want to make a statement like:

"The main key (that I sign) may be used for signature creation but
not for further certification. All valid subkeys may be used for
encryption of communication and storage"


/Donald

------=_NextPart_000_0043_01C0B164.4F463120
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Nothing is said about whether the key =
flags of a=20
certification<BR>is valid for that main key or for main key plus subkeys =
as an=20
item.<BR>PGP don't even have a mechanism for doing any kind of=20
certification<BR>of a subkey.<BR><BR>I do know that a subkey may be=20
exchanged/added at a later stage than the<BR>certification is made, and =
in=20
particular is not input to a certification<BR>signature, but I still =
want to=20
make a statement like:<BR><BR>"The main key (that I sign) may be used =
for=20
signature creation but<BR>not for further certification. All valid =
subkeys may=20
be used for<BR>encryption of communication and=20
storage"<BR><BR><BR>/Donald</FONT></DIV></BODY></HTML>

------=_NextPart_000_0043_01C0B164.4F463120--


Received: by above.proper.com (8.9.3/8.9.3) id GAA16246 for ietf-openpgp-bks; Tue, 20 Mar 2001 06:03:58 -0800 (PST)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA16241 for <[e-mail]>; Tue, 20 Mar 2001 06:03:55 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin172.pg11-nt.frankfurt.nikoma.de [213.54.42.172]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id PAA95988 for <[e-mail]>; Tue, 20 Mar 2001 15:03:43 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 32C122ED15; Tue, 20 Mar 2001 14:54:52 +0100 (CET)
Date: Tue, 20 Mar 2001 14:54:52 +0100
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: editorial commnets for openpgp-mime-05
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
User-Agent: Mutt/1.3.16i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Mar 20, 2001 at 10:11:20PM +0900
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 2001-03-20 22:11:20 +0900, Kazu Yamamoto wrote:

> I read openpgp-mime-05 for the meeting today. I think this version
> is quite reasonable.

> Here are editorial commnets for openpgp-mime-05:

Thanks.  I fixed that in the version of the document which resides
here.

-- 
Thomas Roessler			    <[e-mail]>


Received: by above.proper.com (8.9.3/8.9.3) id FAA14177 for ietf-openpgp-bks; Tue, 20 Mar 2001 05:11:21 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14172 for <[e-mail]>; Tue, 20 Mar 2001 05:11:19 -0800 (PST)
Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id WAA09052 for <[e-mail]>; Tue, 20 Mar 2001 22:11:19 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA11262 for <[e-mail]>; Tue, 20 Mar 2001 22:11:19 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA21917 for <[e-mail]>; Tue, 20 Mar 2001 22:11:18 +0900 (JST)
Date: Tue, 20 Mar 2001 22:11:20 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: editorial commnets for openpgp-mime-05
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
X-Mailer: Mew version 1.95b115 on Emacs 21.0 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; 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>

Hi all,

I read openpgp-mime-05 for the meeting today. I think this version
is quite reasonable.

Here are editorial commnets for openpgp-mime-05:

(1) page 3, note:

Two "From" should be "From ". The last SPC is very important since
MTAs don't convert a line started with "From" (not "From ") to
">From".

(2) page 6

There are two item (4). (4) and (5) should be (5) and (6),
respectively.

--Kazu


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id WAA29417 for ietf-openpgp-bks; Mon, 19 Mar 2001 22:24:31 -0800 (PST)
Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA29412 for <[e-mail]>; Mon, 19 Mar 2001 22:24:29 -0800 (PST)
Received: from [192.168.1.102] ([64.230.35.74]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010320062401.TJGU24361.tomts7-srv.bellnexxia.net@[192.168.1.102]>; Tue, 20 Mar 2001 01:24:01 -0500
Date: Tue, 20 Mar 2001 01:23:17 -0500
From: Robert Guerra <[e-mail]>
To: John W Noerenberg II <[e-mail]>
cc: [e-mail]
Subject: Re: Compatibility testing goals and planning
Message-ID: <2417597.3194040197@[192.168.1.102]>
In-Reply-To: <a05100603b6dc64969960@[135.222.66.224]>
X-Mailer: Mulberry/2.0.8 (MacOS)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

John , Rodney & JON :

I think this a wonderfull idea whose time has come.

I'm involved in agreat deal of PGP training to english and non-english 
audiences and am particularly interested in how different implementations 
handle non USA ASCII text. If this aspect of testing might be of interest, 
please do let me know..as more than happy to help

Regards,

Robert
ps.


--On Monday, March 19, 2001 7:50 PM -0600 John W Noerenberg II 
<[e-mail]> wrote:

> Earlier this month I proposed an interoperability testing meeting for
> OpenPGP.  A number of people have responded they are interested in
> participating, and I've given some more thought to what we want to
> accomplish.  Rod Thayer and I had the opportunity to discuss it further
> today, and a plan is beginning to take shape.
>
> The OpenPGP Oven-Cooking Competition (in deference to a local Minneapolis
> company who feels another name impinges their reputation) is intended to
> test compliance with 2440 in a variety of scenarios. I'll provide a
> compliance matrix for the 2440 requirements that implementers can use as
> a guide.  The matrix will be reviewed both by Rod and by Jon Callas to
> make sure I haven't missed anything important, or misstated anything.
> And, of course, it will be published to this list as soon as possible for
> your review.  Uses of OpenPGP we anticipate testing are PGP/MIME, TLS
> over OpenPGP, and IPSec over OpenPGP.  We'll verify interoperation of key
> generation, signing and verification.  We're considering ways to verify
> key server interoperability.  However, there are no published protocols
> for this.  So I'm not sure what we can accomplish in this area.  We'd
> like to test implementations of the AES algorithms, as well as the
> mandated algorithms in 2440.   Execution speed isn't nearly as important
> as correct execution of the protocols and underlying algorithms. But bear
> in mind that I don't expect the meeting to last more than 2 days. <grin>
>
> Rod will create a more detailed test plan which we'll publish for
> comments on the list.  I'd like to aim at holding the Oven-Cooking
> Competition sometime during June or July so that we can publish our
> status on 2440 in time for the London meeting.  Some people have
> indicated they won't be able to participate in person, so one of the
> things I'll arrange is a means for people to also test remotely. However,
> I want to emphasize how valuable face-to-face meetings are for
> interoperability testing.  We'll be able to solve problems interactively,
> and discover issues that otherwise may take a long time to surface.
>
> These are my general goals for the meeting.  Please comment and offer
> suggestions.  That's the best way to insure this little confab serves
> your needs as implementers and users of OpenPGP.
>
> --
>
> john noerenberg
> [e-mail]
>
> --------------------------------------------------------------------------
>    Peace of mind isn't at all superficial, really.  It's the whole thing.
>    That which produces it is good maintenance; that which disturbs it
> is poor maintenance.
>    -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
>
> --------------------------------------------------------------------------



Robert Guerra <[e-mail]>
WWW: http://www.geocities.com/rguerra/



Received: by above.proper.com (8.9.3/8.9.3) id RAA24786 for ietf-openpgp-bks; Mon, 19 Mar 2001 17:51:11 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA24782 for <[e-mail]>; Mon, 19 Mar 2001 17:51:10 -0800 (PST)
Received: from [135.222.66.224] (vpnap-g1-012029.qualcomm.com [10.13.12.29]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2K1pCV07012 for <[e-mail]>; Mon, 19 Mar 2001 17:51:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100603b6dc64969960@[135.222.66.224]>
X-Mailer: Eudora [Macintosh version 5.1-0319010029]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 19 Mar 2001 19:50:49 -0600
To: OpenPGP mailing list <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Compatibility testing goals and planning
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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>

Earlier this month I proposed an interoperability testing meeting for 
OpenPGP.  A number of people have responded they are interested in 
participating, and I've given some more thought to what we want to 
accomplish.  Rod Thayer and I had the opportunity to discuss it 
further today, and a plan is beginning to take shape.

The OpenPGP Oven-Cooking Competition (in deference to a local 
Minneapolis company who feels another name impinges their reputation) 
is intended to test compliance with 2440 in a variety of scenarios. 
I'll provide a compliance matrix for the 2440 requirements that 
implementers can use as a guide.  The matrix will be reviewed both by 
Rod and by Jon Callas to make sure I haven't missed anything 
important, or misstated anything.  And, of course, it will be 
published to this list as soon as possible for your review.  Uses of 
OpenPGP we anticipate testing are PGP/MIME, TLS over OpenPGP, and 
IPSec over OpenPGP.  We'll verify interoperation of key generation, 
signing and verification.  We're considering ways to verify key 
server interoperability.  However, there are no published protocols 
for this.  So I'm not sure what we can accomplish in this area.  We'd 
like to test implementations of the AES algorithms, as well as the 
mandated algorithms in 2440.   Execution speed isn't nearly as 
important as correct execution of the protocols and underlying 
algorithms. But bear in mind that I don't expect the meeting to last 
more than 2 days. <grin>

Rod will create a more detailed test plan which we'll publish for 
comments on the list.  I'd like to aim at holding the Oven-Cooking 
Competition sometime during June or July so that we can publish our 
status on 2440 in time for the London meeting.  Some people have 
indicated they won't be able to participate in person, so one of the 
things I'll arrange is a means for people to also test remotely. 
However, I want to emphasize how valuable face-to-face meetings are 
for interoperability testing.  We'll be able to solve problems 
interactively, and discover issues that otherwise may take a long 
time to surface.

These are my general goals for the meeting.  Please comment and offer 
suggestions.  That's the best way to insure this little confab serves 
your needs as implementers and users of OpenPGP.

-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.9.3/8.9.3) id BAA21919 for ietf-openpgp-bks; Mon, 19 Mar 2001 01:57:51 -0800 (PST)
Received: from sheridan.uel.ac.uk (sheridan.uel.ac.uk [161.76.9.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA21911 for <[e-mail]>; Mon, 19 Mar 2001 01:57:49 -0800 (PST)
Received: from bkstud1.uel.ac.uk (bkstud1.uel.ac.uk [161.76.88.9]) by sheridan.uel.ac.uk (8.9.3+Sun/8.9.3) with ESMTP id JAA20825 for <[e-mail]>; Mon, 19 Mar 2001 09:57:47 GMT
Message-Id: <[e-mail]>
Received: from BKSTUD1/SpoolDir by bkstud1.uel.ac.uk (Mercury 1.48); 19 Mar 01 10:01:55 GMT0BST
Received: from SpoolDir by BKSTUD1 (Mercury 1.48); 19 Mar 01 10:01:46 GMT0BST
From: "Nalaka Thusitha Illuppella" <[e-mail]>
Organization: University Of East London
To: [e-mail]
Date: Mon, 19 Mar 2001 10:01:43 GMT0BST
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: tiger hash algorithm
X-mailer: Pegasus Mail for Win32 (v3.12b)
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>

Dear Sir,

I am a M.Sc student, studying for University of East London, 
Please email me the tiger hash algorithm.

Thanks
Nalaka



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA13467 for ietf-openpgp-bks; Mon, 12 Mar 2001 19:00:23 -0800 (PST)
Received: from magicn.com ([210.123.89.142]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA13455 for <[e-mail]>; Mon, 12 Mar 2001 19:00:21 -0800 (PST)
From: [e-mail]
Received: from mail.eunet.sk ([63.24.177.98]) by magicn.com  with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 13 Mar 2001 11:55:31 +0900
Message-ID: <00000ba30d5b$000046c4$[e-mail]>
To: <[e-mail]>
Subject: Tires of Cable TV raising there rates!!!
Date: Mon, 12 Mar 2001 20:45:52 -0600
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [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>

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2>
<FONT color=3D"#000000"> Tired of Cable TV raising their rates!!!<BR>
   Get Satellite TV<BR>
   YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S<BR>
   YES ---YOU CAN GET LOCAL STATIONS<BR>
   Order Dish Network System with a one year plan, get FREE two receivers<=
BR>
   and the 18" Dish with FREE basic professional installation.<BR>
<BR>
   Why Bother? For $40.99 Get both receivers and the Top 100 Stations!<BR>
   With only one receiver and the Dish $35.99  Local Channels add $5.00<BR=
>
<BR>
   You will be charged a one time $49.99 fee when you order which includes=
<BR>
   your  first months service for FREE.<BR>
   THAT S IT!<BR>
   FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT...<BR>
   YOU'LL LOVE IT.<BR>
   Ready? Order by phone [phone] or e-mail us [e-mail]<B=
R>
<BR>
   REQUIREMENT- 1. One year service commitment.<BR>
   2. Major credit Card<BR>
   3. Southwest exposure to the sky.<BR>
<BR>
   to be remove from future mailings e-mail us with the word "remove" in t=
he  subject lineat --- [e-mail]<BR>
<BR>
   Headquarters:<BR>
   470 State Highway 10 West<BR>
   Ledgewood, New Jersey 07852-0338<BR>
   [phone]<BR>
   www.1800technostores.com<BR>
<BR>
</FONT></FONT><p><p><p><p><p><p><p><p><p><p>








<p><FONT face=3D"MS Sans Serif"><p><FONT size=3D2><p><FONT color=3D"#00000=
0"> Tired of Cable TV raising their rates!!!<BR><p>   Get Satellite TV<BR>=
<p><p><p><p><p><p><p></BODY></HTML>




Received: by above.proper.com (8.9.3/8.9.3) id RAA09708 for ietf-openpgp-bks; Mon, 12 Mar 2001 17:10:29 -0800 (PST)
Received: from mailserver.iwill.net (IDENT:[e-mail] [203.74.176.35]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09704 for <[e-mail]>; Mon, 12 Mar 2001 17:10:27 -0800 (PST)
From: [e-mail]
Received: from ns.opentec.com.mx (1Cust194.tnt34.dfw9.da.uu.net [63.62.253.194]) by mailserver.iwill.net (8.9.3/8.8.7) with SMTP id IAA19275; Tue, 13 Mar 2001 08:01:53 +0800
Message-ID: <000006ed3c2a$0000478e$[e-mail]>
To: <[e-mail]>
Subject: Tired of Cable TV raising there rates!!!!
Date: Mon, 12 Mar 2001 17:06:28 -0600
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [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>

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2>
<FONT color=3D"#000000"> Tired of Cable TV raising their rates!!!<BR>
Get Satellite TV<BR>
YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S<BR>
YES ---YOU CAN GET LOCAL STATIONS<BR>
Order Dish Network System with a one year plan, get FREE two receivers and=
<BR>
the 18" Dish with FREE basic professional installation.<BR>
<BR>
Why Bother?  For $40.99 Get both receivers and the Top 100 Stations!<BR>
With only one receiver and the Dish $35.99<BR>
Local Channels add $5.00<BR>
<BR>
You will be charged a one time $49.99 fee when you order which includes yo=
ur<BR>
first months service for FREE.<BR>
THAT S IT!<BR>
FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT...<BR>
YOU'LL LOVE IT.<BR>
Ready?   Order by phone [phone]<BR>
or e-mail us  [e-mail]<BR>
<BR>
REQUIREMENT- 1. One year service commitment.<BR>
2. Major credit Card<BR>
3. Southwest exposure to the sky.<BR>
<BR>
to be remove from future mailings e-mail us with the word "remove" in the<=
BR>
subject line at ----   [e-mail] <BR>
<BR>
Headquarters:<BR>
470 State Highway 10 West<BR>
Ledgewood, New Jersey 07852-0338<BR>
[phone]<BR>
www.1800technostores.com<BR>
<BR>
<BR>
<BR>
</FONT></FONT><p><p><p><p><p><p><p><p><p><p>



<p><FONT face=3D"MS Sans Serif"><p><FONT size=3D2><p><FONT color=3D"#00000=
0"> Tired of Cable TV raising their rates!!!<BR><p>Get Satellite TV<BR><p>=
YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S<BR><p>YES ---YOU =
CAN GET LOCAL STATIONS<BR><p>Order Dish Network System with a one year pla=
n, get FREE two receivers and<BR><p><p><p><p><p><p></BODY></HTML>




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA19311 for ietf-openpgp-bks; Tue, 6 Mar 2001 17:01:16 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA19307 for <[e-mail]>; Tue, 6 Mar 2001 17:01:15 -0800 (PST)
Received: from [129.46.77.86] (dhcp990305211402.qualcomm.com [129.46.77.86]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f2711Gx10409 for <[e-mail]>; Tue, 6 Mar 2001 17:01:17 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a0510011cb6c9e29935b4@[129.46.77.86]>
In-Reply-To: <a05100100b6c05c88332f@[199.106.117.178]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <a05100100b6c05c88332f@[199.106.117.178]>
X-Mailer: Eudora [Macintosh version 5.1-0306010811]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 6 Mar 2001 17:01:05 -0800
To: [e-mail]
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME? - Mtg in Mpls
Content-Type: multipart/alternative; boundary="============_-1228195617==_ma============"
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>

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

At 11:30 AM -0800 2/26/01, John  W Noerenberg II wrote:
>I'm gonna schedule an hour in Minneapolis for OpenPGP.  Main thing 
>on the list is to deal with PGP/MIME.  If not enough of us are going 
>to show, I'll cancel.  But let's get on the agenda.


1415-1515 Afternoon Sessions II
APP     simple          SIP for Instant Messaging and Presence 
Leveraging Extensions BOF
INT     multi6          How Should We Multihome In IPv6 BOF
OPS     hubmib          Ethernet Interfaces and Hub MIB WG
RTG     idmr            Inter-Domain Multicast Routing WG
SEC     openpgp         An Open Specification for Pretty Good Privacy WG
SEC     hip             Host Identity Payload BOF
TSV     ippm            IP Performance WG

We have our slot on Tuesday.  I'm open to suggestions for our agenda, 
and for confirmations on whether you'll attend.
--============_-1228195617==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=""><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Finalizing OpenPGP/MIME? - Mtg in
Mpls</title></head><body>
<div>At 11:30 AM -0800 2/26/01, John&nbsp; W Noerenberg II
wrote:</div>
<blockquote type="" cite>I'm gonna schedule an hour in Minneapolis for
OpenPGP.&nbsp; Main thing on the list is to deal with PGP/MIME.&nbsp;
If not enough of us are going to show, I'll cancel.&nbsp; But let's
get on the agenda.</blockquote>
<div><br></div>
<div><br></div>
<div>1415-1515 Afternoon Sessions II<br>
APP&nbsp;&nbsp;&nbsp;&nbsp;
simple&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP for
Instant Messaging and Presence Leveraging Extensions BOF<br>
INT&nbsp;&nbsp;&nbsp;&nbsp;
multi6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How
Should We Multihome In IPv6 BOF<br>
OPS&nbsp;&nbsp;&nbsp;&nbsp;
hubmib&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ethernet
Interfaces and Hub MIB WG<br>
RTG&nbsp;&nbsp;&nbsp;&nbsp;
idmr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Inter-Domain Multicast Routing WG<br>
SEC&nbsp;&nbsp;&nbsp;&nbsp;
openpgp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Open
Specification for Pretty Good Privacy WG<br>
SEC&nbsp;&nbsp;&nbsp;&nbsp;
hip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Host Identity Payload BOF</div>
<div>TSV&nbsp;&nbsp;&nbsp;&nbsp;
ippm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IP Performance WG</div>
<div><font face="Charcoal" color="#000000"><br></font></div>
<div>We have our slot on Tuesday.&nbsp; I'm open to suggestions for
our agenda, and for confirmations on whether you'll attend.</div>
</body>
</html>
--============_-1228195617==_ma============--


Received: by above.proper.com (8.9.3/8.9.3) id LAA16932 for ietf-openpgp-bks; Mon, 5 Mar 2001 11:42:29 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16927 for <[e-mail]>; Mon, 5 Mar 2001 11:42:28 -0800 (PST)
Received: from [129.46.77.86] (dhcp990305211402.qualcomm.com [129.46.77.86]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f25JgS020060; Mon, 5 Mar 2001 11:42:28 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100109b6c996ce6701@[129.46.77.86]>
X-Mailer: Eudora [Macintosh version 5.1-030401]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 5 Mar 2001 11:38:51 -0800
To: OpenPGP mailing list <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: interoperability testing of OpenPGP
Cc: "Philip R. Zimmermann" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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 investigating the possibility of hosting an openpgp 
interoperability testing workshop (there's another name for this, but 
Pillsbury seems to think it is improper for other organizations to 
use it) at Qualcomm in our San Diego facilities.  I'd like to know 
how many people would be interested in participating, particularly 
those willing to come in person.  Please respond to me personally 
(rather than litter the mailing list).  I'll summarize and report 
back.

Phil Zimmerman and I have discussed this, and it would be in 
connection with the OpenPGP Consortium he is organizing.  This has 
particular value for this WG, since it will help us assess where we 
stand w/r/t DRAFT status for rfc2440.  I am hopeful there will be 
several willing and able to participate!

best,
-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.9.3/8.9.3) id LAA16286 for ietf-openpgp-bks; Mon, 5 Mar 2001 11:28:55 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16281 for <[e-mail]>; Mon, 5 Mar 2001 11:28:54 -0800 (PST)
Received: from [129.46.77.86] (dhcp990305211402.qualcomm.com [129.46.77.86]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f25JSp016412; Mon, 5 Mar 2001 11:28:51 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100108b6c996bc62e7@[129.46.77.86]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <a05100100b6c97a5db888@[199.106.106.131]> <[e-mail]>
X-Mailer: Eudora [Macintosh version 5.1-030401]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 5 Mar 2001 11:17:25 -0800
To: Thomas Roessler <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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 7:16 PM +0100 3/5/01, Thomas Roessler wrote:
>
>That's perfectly compatible with draft-05: Trailing white space will
>be protected by the quoted-printable encoding of the flowed text, so
>there is _no_ trailing whitespace in the signed material as the hash
>algorithm sees it.

Well done.


Received: by above.proper.com (8.9.3/8.9.3) id KAA12967 for ietf-openpgp-bks; Mon, 5 Mar 2001 10:17:36 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12963 for <[e-mail]>; Mon, 5 Mar 2001 10:17:33 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin4.pg5-nt.frankfurt.nikoma.de [213.54.36.4]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id TAA52030 for <[e-mail]>; Mon, 5 Mar 2001 19:17:22 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 33EB82ED15; Mon,  5 Mar 2001 19:16:08 +0100 (CET)
Date: Mon, 5 Mar 2001 19:16:08 +0100
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <a05100100b6c97a5db888@[199.106.106.131]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.16i
In-Reply-To: <a05100100b6c97a5db888@[199.106.106.131]>; from [e-mail] on Mon, Mar 05, 2001 at 09:28:14AM -0800
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 2001-03-05 09:28:14 -0800, John W Noerenberg II wrote:

> Have you considered the implications of format=flowed (rfc2646)?
> Specifically:

> 4.6.  Digital Signatures and Encryption
> 
>     If a message is digitally signed or encrypted it is important that
>     cryptographic processing use the on-the-wire Format=Flowed format.
>     That is, during generation the message SHOULD be prepared for
>     transmission, including addition of soft line breaks, space-stuffing,
>     and [Quoted-Printable] encoding (to protect soft line breaks) before
>     being digitally signed or encrypted; similarly, on receipt the
>     message SHOULD have the signature verified or be decrypted before
>     [Quoted-Printable] decoding and removal of stuffed spaces, soft line
>     breaks and quote marks, and reflowing.

That's perfectly compatible with draft-05: Trailing white space will
be protected by the quoted-printable encoding of the flowed text, so
there is _no_ trailing whitespace in the signed material as the hash
algorithm sees it.

-- 
Thomas Roessler			    <[e-mail]>
This message may  have been certified to  be possibly virus-free.


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA10568 for ietf-openpgp-bks; Mon, 5 Mar 2001 09:29:38 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10562 for <[e-mail]>; Mon, 5 Mar 2001 09:29:37 -0800 (PST)
Received: from [129.46.77.86] (dhcp990305211402.qualcomm.com [129.46.77.86]) by mage.qualcomm.com (8.11.2/8.11.2/1.0) with ESMTP id f25HTC009843; Mon, 5 Mar 2001 09:29:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100100b6c97a5db888@[199.106.106.131]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Eudora [Macintosh version 5.1-030401]
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 5 Mar 2001 09:28:14 -0800
To: [e-mail]
From: John  W Noerenberg II <[e-mail]>
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: multipart/alternative; boundary="============_-1228309142==_ma============"
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>

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

At 3:59 PM -0800 2/13/01, [e-mail] wrote:
>Isn't the real, operational issue here a question of whether trailing
>white space should be hashed?  The choices are to say yes, or no, or it
>depends on the type byte in the signature.

Have you considered the implications of format=flowed (rfc2646)?  Specifically:

4.6.  Digital Signatures and Encryption

    If a message is digitally signed or encrypted it is important that
    cryptographic processing use the on-the-wire Format=Flowed format.
    That is, during generation the message SHOULD be prepared for
    transmission, including addition of soft line breaks, space-stuffing,
    and [Quoted-Printable] encoding (to protect soft line breaks) before
    being digitally signed or encrypted; similarly, on receipt the
    message SHOULD have the signature verified or be decrypted before
    [Quoted-Printable] decoding and removal of stuffed spaces, soft line
    breaks and quote marks, and reflowing.


-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------
--============_-1228309142==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=""><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: PGP/MIME implementors: text mode vs. binary
mode?</title></head><body>
<div>At 3:59 PM -0800 2/13/01, [e-mail] wrote:</div>
<blockquote type="" cite>Isn't the real, operational issue here a
question of whether trailing<br>
white space should be hashed?&nbsp; The choices are to say yes, or no,
or it<br>
depends on the type byte in the signature.</blockquote>
<div><br></div>
<div>Have you considered the implications of format=flowed (rfc2646)?&nbsp;
Specifically:</div>
<div><br></div>
<blockquote>4.6.&nbsp; Digital Signatures and Encryption</blockquote>
<blockquote><br></blockquote>
<blockquote>&nbsp;&nbsp; If a message is digitally signed or encrypted
it is important that</blockquote>
<blockquote>&nbsp;&nbsp; cryptographic processing use the on-the-wire
Format=Flowed format.</blockquote>
<blockquote>&nbsp;&nbsp; That is, during generation the message SHOULD
be prepared for</blockquote>
<blockquote>&nbsp;&nbsp; transmission, including addition of soft line
breaks, space-stuffing,</blockquote>
<blockquote>&nbsp;&nbsp; and [Quoted-Printable] encoding (to protect
soft line breaks) before</blockquote>
<blockquote>&nbsp;&nbsp; being digitally signed or encrypted;
similarly, on receipt the</blockquote>
<blockquote>&nbsp;&nbsp; message SHOULD have the signature verified or
be decrypted before</blockquote>
<blockquote>&nbsp;&nbsp; [Quoted-Printable] decoding and removal of
stuffed spaces, soft line</blockquote>
<blockquote>&nbsp;&nbsp; breaks and quote marks, and
reflowing.</blockquote>
<div><br></div>
<div><tt><br></tt></div>
<x-sigsep><pre>
-- 
</pre></x-sigsep>
<div><br>
john noerenberg<br>
[e-mail]<br>
&nbsp;
---------------------------------------------------------------------<span
></span>-----<br>
&nbsp; Peace of mind isn't at all superficial, really.&nbsp; It's the
whole thing.<br>
&nbsp; That which produces it is good maintenance; that which disturbs
it<br>
&nbsp; is poor maintenance.<br>
&nbsp; -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig,
1974<br>
&nbsp;
---------------------------------------------------------------------<span
></span>-----</div>
</body>
</html>
--============_-1228309142==_ma============--


Received: by above.proper.com (8.9.3/8.9.3) id KAA23381 for ietf-openpgp-bks; Sat, 3 Mar 2001 10:28:33 -0800 (PST)
Received: from mail.kelyan.it (mail.kelyan.it [213.26.197.120]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23371 for <[e-mail]>; Sat, 3 Mar 2001 10:28:32 -0800 (PST)
From: [e-mail]
Received: from mailhost.ggtech.com ([206.216.141.97] unverified) by mail.kelyan.it with Microsoft SMTPSVC(5.0.2195.1600); Sat, 3 Mar 2001 19:15:11 +0100
Message-ID: <000019f63781$0000332a$[e-mail]>
To: <[e-mail]>
Subject: Brand New  Email Pager FR-EE   1203
Date: Sat, 03 Mar 2001 12:04:53 -0600
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [e-mail]
X-OriginalArrivalTime: 03 Mar 2001 18:15:11.0734 (UTC) FILETIME=[E30F6160:01C0A40D]
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>

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2>
<FONT color=3D"#000000"> Brand New Pager for FR-EE!<BR>
<BR>
No long term contract<BR>
No big prepayment of airtime<BR>
No credit check<BR>
<BR>
Put Free pagers on your kids - Give one to your loved ones - For FR-EE<BR>
<BR>
Here at Paging America we are excited to be offering you this exclusive, t=
op of the line, full featured pager in your choice<BR>
of color for FR-EE. This side viewable display pager is one of the smalles=
t and lightest pagers on the market today.<BR>
<BR>
<BR>
Call 877-699-8545 to be Guaranteed Your FR-EE Pager Today<BR>
<BR>
<BR>
Your pager will hold up to 20 numeric messages. It has 9 musi alerts and s=
ilent vibration. New FLEX technology provides three<BR>
times the battery life. Also, message time and date stamping and smart ala=
rm so you can set a daily or weekly reminder.<BR>
This pager comes in black, teal and blue. <BR>
<BR>
To receive your free pager all we ask is that you allow us to provide you =
with the monthly  airtime cancelable at any time.<BR>
There is no long term contract.<BR>
 Just call the toll free number and we'll ship your Free pager to you imme=
diately in your choice of color already programmed with<BR>
a local telephone number for your town. <BR>
<BR>
Make this easy phone call and we will deliver your pager immediately.<BR>
<BR>
<BR>
Call 877-699-8545 to get in on this exciting offer today<BR>
<BR>
<BR>
</FONT></FONT><p><p><p><p><p><p><p><p><p><p>




<p><FONT face=3D"MS Sans Serif"><p><p><p><p><p><p><p><p><p><p></BODY></HTML>




Received: by above.proper.com (8.9.3/8.9.3) id DAA24641 for ietf-openpgp-bks; Fri, 2 Mar 2001 03:46:06 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA24637 for <[e-mail]>; Fri, 2 Mar 2001 03:46:04 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25605; Fri, 2 Mar 2001 06:46:03 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-mime-05.txt
Date: Fri, 02 Mar 2001 06:46:03 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-05.txt
	Pages		: 13
	Date		: 01-Mar-01
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-mime-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-mime-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-mime-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--