Re: ASN.1 OID for TIGER/192

[David Shaw <[e-mail]>]

On Mon, Sep 30, 2002 at 01:17:08PM -0400, Derek Atkins wrote:
> David Shaw <[e-mail]> writes:
> 
> > I'm not for or against using TIGER in OpenPGP, but my feeling is that
> > if we are going to include TIGER, then we should do it intentionally,
> > with all due care taken.
> 
> At some level, too many ciphers can spoil the security-system...  Not
> that I'm saying TIGER is insecure, but at some level you need to limit
> the posibilities for real-world interoperation.
> 
> Also note that reserving a number for TIGER but _not_ putting it into
> the standard is different than actually calling TIGER a required cipher.

I have no problem with assigning a number for TIGER (or rather,
continuing to use the existing one) and not making it a required
algorithm.  In fact, I think it should be a completely optional part
of the standard.  However, if TIGER is present in the standard at all
as a possibility, it still impacts to a degree even those
implementations that don't implement it.

So to clarify: I'm not for or against including TIGER as an optional
part of the standard, but if it is included, it would be nice to have
some thought first.  Of course, TIGER is *already* an optional part of
the standard, but since it was lacking an OID until recently, the
question of it actually being used was somewhat moot.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8UHVwe01881 for ietf-openpgp-bks; Mon, 30 Sep 2002 10:31:58 -0700 (PDT)
Received: from claude.kendall.corp.akamai.com (fw01.cmbrmaks.akamai.com [80.67.64.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UHVvv01874 for <[e-mail]>; Mon, 30 Sep 2002 10:31:57 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.corp.akamai.com (8.11.6/8.11.6) id g8UHVIi06021; Mon, 30 Sep 2002 13:31:18 -0400
Date: Mon, 30 Sep 2002 13:31:18 -0400
From: David Shaw <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: [e-mail]
Subject: Re: ASN.1 OID for TIGER/192
Message-ID: <[e-mail]>
Mail-Followup-To: Derek Atkins <[e-mail]>, [e-mail]
References: <[e-mail]> <20020927155054.GB17939@stonewall> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 30, 2002 at 01:17:08PM -0400, Derek Atkins wrote:
> David Shaw <[e-mail]> writes:
> 
> > I'm not for or against using TIGER in OpenPGP, but my feeling is that
> > if we are going to include TIGER, then we should do it intentionally,
> > with all due care taken.
> 
> At some level, too many ciphers can spoil the security-system...  Not
> that I'm saying TIGER is insecure, but at some level you need to limit
> the posibilities for real-world interoperation.
> 
> Also note that reserving a number for TIGER but _not_ putting it into
> the standard is different than actually calling TIGER a required cipher.

I have no problem with assigning a number for TIGER (or rather,
continuing to use the existing one) and not making it a required
algorithm.  In fact, I think it should be a completely optional part
of the standard.  However, if TIGER is present in the standard at all
as a possibility, it still impacts to a degree even those
implementations that don't implement it.

So to clarify: I'm not for or against including TIGER as an optional
part of the standard, but if it is included, it would be nice to have
some thought first.  Of course, TIGER is *already* an optional part of
the standard, but since it was lacking an OID until recently, the
question of it actually being used was somewhat moot.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8UHJun01377 for ietf-openpgp-bks; Mon, 30 Sep 2002 10:19:56 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UHJtv01372 for <[e-mail]>; Mon, 30 Sep 2002 10:19:55 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA16707; Mon, 30 Sep 2002 13:19:56 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA12420; Mon, 30 Sep 2002 13:17:08 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA18525; Mon, 30 Sep 2002 13:17:08 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA00193; Mon, 30 Sep 2002 13:17:08 -0400 (EDT)
To: David Shaw <[e-mail]>
Cc: [e-mail]
From: Derek Atkins <[e-mail]>
Subject: Re: ASN.1 OID for TIGER/192
References: <[e-mail]> <20020927155054.GB17939@stonewall> <[e-mail]>
Date: 30 Sep 2002 13:17:08 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 21
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>

David Shaw <[e-mail]> writes:

> I'm not for or against using TIGER in OpenPGP, but my feeling is that
> if we are going to include TIGER, then we should do it intentionally,
> with all due care taken.

At some level, too many ciphers can spoil the security-system...  Not
that I'm saying TIGER is insecure, but at some level you need to limit
the posibilities for real-world interoperation.

Also note that reserving a number for TIGER but _not_ putting it into
the standard is different than actually calling TIGER a required cipher.

> David

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8UGtMF29063 for ietf-openpgp-bks; Mon, 30 Sep 2002 09:55:22 -0700 (PDT)
Received: from claude.kendall.corp.akamai.com (fw01.cmbrmaks.akamai.com [80.67.64.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UGtLv29056 for <[e-mail]>; Mon, 30 Sep 2002 09:55:21 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.corp.akamai.com (8.11.6/8.11.6) id g8UGtHG04008 for [e-mail]; Mon, 30 Sep 2002 12:55:17 -0400
Date: Mon, 30 Sep 2002 12:55:17 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: ASN.1 OID for TIGER/192
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <20020927155054.GB17939@stonewall>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020927155054.GB17939@stonewall>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Sep 27, 2002 at 03:50:54PM +0000, Brian M. Carlson wrote:

> I think it would be the height of silliness to have an algorithm in
> the standard and prohibit its use. In fact, it is like revoking your
> signature on someone's key: it is a vote of no confidence, a statement
> that it is worthless. 

Of course, but OpenPGP is sensitive to the strengths of all of its
hash algorithms (as noted in the "Security Considerations" section).
If TIGER was put into the standard with less care because it couldn't
be used anyway without an OID, then now is an appropriate time to
decide whether it should be in the standard or not.  Mind you, I don't
know the history here - there could have been significant care taken.

I'm not for or against using TIGER in OpenPGP, but my feeling is that
if we are going to include TIGER, then we should do it intentionally,
with all due care taken.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8UBITB10666 for ietf-openpgp-bks; Mon, 30 Sep 2002 04:18:29 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UBIRv10662 for <[e-mail]>; Mon, 30 Sep 2002 04:18:27 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17vzss-00078V-00; Mon, 30 Sep 2002 14:42:46 +0200
Received: from wk by alberti.g10code.de with local (Exim 3.35 #1 (Debian)) id 17vyWd-0007tJ-00; Mon, 30 Sep 2002 13:15:43 +0200
To: [e-mail]
Cc: [e-mail]
Subject: Re: ASN.1 OID for TIGER/192
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-Request-PGP: finger://[e-mail]
X-PGP-KeyID:   621CC013
X-FSFE-Info:  http://fsfeurope.org
Date: Mon, 30 Sep 2002 13:15:42 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Mon, 30 Sep 2002 10:17:49 +0200")
Message-ID: <[e-mail]>
Lines: 15
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 30 Sep 2002 10:17:49 +0200, disastry  said:

>> >       1.3.6.1.4.1.11591.12.2

> so the full ASN string is:
>   0x30, 0x29, 0x30, 0x0D, 0x06, 0x09, 0x2B, 0x06, 0x01, 0x04,
>   0x01, 0xDA, 0x47, 0x0C, 0x02, 0x05, 0x00, 0x04, 0x18
> right?

I calculated the same.


Shalom-Salam,

   Werner



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8U8NU224833 for ietf-openpgp-bks; Mon, 30 Sep 2002 01:23:30 -0700 (PDT)
Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8U8NRv24820 for <[e-mail]>; Mon, 30 Sep 2002 01:23:28 -0700 (PDT)
Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id <[e-mail]>; Mon, 30 Sep 2002 10:17:49 0200
Message-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 10:17:49 +0200
From: [e-mail]
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: ASN.1 OID for TIGER/192
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Brian M. Carlson wrote:
>
> On Fri, Sep 27, 2002 at 08:55:50AM -0400, David Shaw wrote:
> >
> > Hello,
> >
> > In 2440 and in all the 2440bis drafts, the TIGER/192 hash is not fully
> > usable as it has no OID.  Werner Koch and I, with the cooperation of
> > TIGER's authors, recently arranged an OID for it:

finally :)

> >
> >       1.3.6.1.4.1.11591.12.2

so the full ASN string is:
  0x30, 0x29, 0x30, 0x0D, 0x06, 0x09, 0x2B, 0x06, 0x01, 0x04,
  0x01, 0xDA, 0x47, 0x0C, 0x02, 0x05, 0x00, 0x04, 0x18
right?

I'm going to change PGP 2.6.3ia-multi06 to support this.

> > It would be good to put this in 2440bis so TIGER will be usable.
>
> I agree. All we have left now is to get one for HAVAL-5-160.

so do I (, and HAVAL-5-256...)

> > I have a sneaking suspicion that this may raise the question whether
> > TIGER should be in the standard at all, as so long as it did not have
> > an OID, the question was moot.  I have no strong feelings on this
> > point, but if we are not going to allow the use of TIGER, then perhaps
> > we should remove it from the standard altogether or explicitly
> > disallow its use as the current halfway state is confusing now that
> > there is an OID available.
>
> I think that we should keep it in, although my opinion may be unpopular.
> Few implementations allow the use of TIGER, and so those people who wish
> to use it can use one of those implementations. It is useful for (gasp!)
> Elgamal signatures,

and RSA signatures!

> because it provides a larger hash algorithm and
> therefore the hash algorithm is no longer the weakest link.

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPZfsdjBaTVEuJQxkEQNFqACfQPHA3inLqW8AyR2Zwd3CTziN4FMAoI86
014cl6dB/XakNb9qWePXcu0f
=m/nq
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RJNKm25723 for ietf-openpgp-bks; Fri, 27 Sep 2002 12:23:20 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8RJNJv25717 for <[e-mail]>; Fri, 27 Sep 2002 12:23:19 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Fri, 27 Sep 2002 12:16:20 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8RJNGE3008148; Fri, 27 Sep 2002 12:23:16 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TM7RD0SB>; Fri, 27 Sep 2002 12:23:15 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: Trevor Perrin <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject:  RE: security fixes (KDF, MDC->MAC)?
Date:  Fri, 27 Sep 2002 12:23:04 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

Fixed a typo-

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>
>5.13.
>[...]    Unlike the Symmetrically Encrypted Data Packet, no
>   special CFB resynchronization is done after encrypting this prefix
>   data.
>
>doesn't this prevent converting packet 18 to 9 ?
>

It doesn't completely prevent the JKS attack.  The attacker can still copy
the first two blocks of ciphertext from a packet 18 to 9, and the check
bytes will decrypt appropriately, but the remainder of the second block will
be scrambled.

So this will probably leave a malformed packet header, but there's a chance
the header might still work, depending on how strict the parsing code is
(for example, what if the packet tag gets randomly set to 11 for Literal
Data, but the length is wrong?).  The attacker can flip bits in the
remainder of the second block and keep submitting guesses to a decryption
oracle, until he stumbles on a packet header that makes the attack work.  

The attacker may also learn information from observing the oracle which lets
him reconstruct the keystream bytes that the ciphertext is being XOR'd with.
For example, if the oracle says "Error: packet tag 62 not supported", the
attacker can reconstruct the keystream bits that correspond to the packet
tag, and thus gain the ability to control its value.


Trevor


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RJGoc24750 for ietf-openpgp-bks; Fri, 27 Sep 2002 12:16:50 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8RJGmv24744 for <[e-mail]>; Fri, 27 Sep 2002 12:16:48 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Fri, 27 Sep 2002 12:09:50 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8RJGjE3007976; Fri, 27 Sep 2002 12:16:46 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TM7RD0RV>; Fri, 27 Sep 2002 12:16:44 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject:  RE: security fixes (KDF, MDC->MAC)?
Date:  Fri, 27 Sep 2002 12:16:37 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>
>5.13.
>[...]    Unlike the Symmetrically Encrypted Data Packet, no
>   special CFB resynchronization is done after encrypting this prefix
>   data.
>
>doesn't this prevent converting packet 18 to 9 ?
>

It doesn't completely prevent the JKS attack.  The attacker can still copy
the first two blocks of ciphertext from a packet 18 to 9, and the check
bytes will decrypt appropriately, but the remainder of the second block will
be scrambled.

So this will probably leave a malformed packet header, but there's a chance
the header might still work, depending on how strict the parsing code is
(for example, what if the packet tag gets randomly set to 9, but the length
is wrong?).  The attacker can flip bits in the remainder of the second block
and keep submitting guesses to a decryption oracle, until he stumbles on a
packet header that makes the attack work.  

The attacker may also learn information from observing the oracle which lets
him reconstruct the keystream bytes that the ciphertext is being XOR'd with.
For example, if the oracle says "Error: packet tag 62 not supported", the
attacker can reconstruct the keystream bits that correspond to the packet
tag, and thus gain the ability to control its value.


Trevor


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RFonq12298 for ietf-openpgp-bks; Fri, 27 Sep 2002 08:50:49 -0700 (PDT)
Received: from mail.hal-pc.org (mail.hal-pc.org [206.180.145.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RFomv12294 for <[e-mail]>; Fri, 27 Sep 2002 08:50:48 -0700 (PDT)
Received: from [24.167.56.115] (HELO stonewall) by mail.hal-pc.org (CommuniGate Pro SMTP 3.5.9) with SMTP id 21391875 for [e-mail]; Fri, 27 Sep 2002 10:50:49 -0500
Received: by stonewall (sSMTP sendmail emulation); Fri, 27 Sep 2002 15:50:54 +0000
From: "Brian M. Carlson" <[e-mail]>
Date: Fri, 27 Sep 2002 15:50:54 +0000
To: [e-mail]
Subject: Re: ASN.1 OID for TIGER/192
Message-ID: <20020927155054.GB17939@stonewall>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Operating-System: Linux stonewall 2.4.18-k7 
Content-Conversion: prohibited
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>

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

On Fri, Sep 27, 2002 at 08:55:50AM -0400, David Shaw wrote:
>=20
> Hello,
>=20
> In 2440 and in all the 2440bis drafts, the TIGER/192 hash is not fully
> usable as it has no OID.  Werner Koch and I, with the cooperation of
> TIGER's authors, recently arranged an OID for it:
>=20
> 	1.3.6.1.4.1.11591.12.2
>=20
> It would be good to put this in 2440bis so TIGER will be usable.

I agree. All we have left now is to get one for HAVAL-5-160.

> I have a sneaking suspicion that this may raise the question whether
> TIGER should be in the standard at all, as so long as it did not have
> an OID, the question was moot.  I have no strong feelings on this
> point, but if we are not going to allow the use of TIGER, then perhaps
> we should remove it from the standard altogether or explicitly
> disallow its use as the current halfway state is confusing now that
> there is an OID available.

I think that we should keep it in, although my opinion may be unpopular.
Few implementations allow the use of TIGER, and so those people who wish
to use it can use one of those implementations. It is useful for (gasp!)
Elgamal signatures, because it provides a larger hash algorithm and
therefore the hash algorithm is no longer the weakest link. (Please note
that TIGER is probably more widely implemented than SHA2, if I had to
guess.)

I think it would be the height of silliness to have an algorithm in
the standard and prohibit its use. In fact, it is like revoking your
signature on someone's key: it is a vote of no confidence, a statement
that it is worthless.=20


--=20
Brian M. Carlson <[e-mail]> <http://decoy.wox.org/~bmc> 0x560553=
E7
To thine own self be true.  (If not that, at least make some money.)

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQFKBAEBAwA0BQI9lH5eLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w
Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT5zayCAClWugHkk7EsIIdWyLkc3SZGSGS
NQfu+VqjMr97o0vVtnEE7D2WXCaNanxxlbAwVvQUmcEEMOD1v1mjiJIbgAfx3NsA
7dVKftDl2V0/CrEo9IUU0kAK24CjjY086uKxzKwJ6IjTrNFGFl+ipatT7pSCSQUC
diGApcw5EljFGGTBir66rQQIP+KP6v3QW1MkDtqo43igBsYlNrZo7ebLrpW0WnWn
Ro5ZG4Vfze11bypbxC0WAoERbs1GAgYNOSoiJMNOTOe745rz9ry8zuJMQLecRj/v
VLL8oBi32pmhXHGRdT9dufWWmklXdLkaYHxcg9t/s/0ypNxfnPlCvjxxyNaz
=lGRj
-----END PGP SIGNATURE-----
Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--nmemrqcdn5VTmUEE--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RECMC05771 for ietf-openpgp-bks; Fri, 27 Sep 2002 07:12:22 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RECKv05764 for <[e-mail]>; Fri, 27 Sep 2002 07:12:21 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17ux9t-000843-00; Fri, 27 Sep 2002 17:36:01 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17uvnt-0001xm-00; Fri, 27 Sep 2002 16:09:13 +0200
To: [e-mail]
Subject: Re: security fixes (KDF, MDC->MAC)?
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-Request-PGP: finger://[e-mail]
X-PGP-KeyID:   621CC013
X-FSFE-Info:  http://fsfeurope.org
Date: Fri, 27 Sep 2002 16:09:13 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Fri, 27 Sep 2002 10:05:51 +0200")
Message-ID: <[e-mail]>
Lines: 15
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 27 Sep 2002 10:05:51 +0200, disastry  said:

> doesn't this prevent converting packet 18 to 9 ?

Yes.

Even more important is that we push users towards using the MDC feature
so that we eventually can make the "no MDC used" warning an
error. (well, with an option to ignore it so that old message can still
be decrypted)


Shalom-Salam,

   Werner



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8RCtsT01321 for ietf-openpgp-bks; Fri, 27 Sep 2002 05:55:54 -0700 (PDT)
Received: from claude.kendall.corp.akamai.com (bgp424106bgs.union01.nj.comcast.net [68.36.190.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RCtrv01316 for <[e-mail]>; Fri, 27 Sep 2002 05:55:53 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.corp.akamai.com (8.11.6/8.11.6) id g8RCtoI14105 for [e-mail]; Fri, 27 Sep 2002 08:55:50 -0400
Date: Fri, 27 Sep 2002 08:55:50 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: ASN.1 OID for TIGER/192
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hello,

In 2440 and in all the 2440bis drafts, the TIGER/192 hash is not fully
usable as it has no OID.  Werner Koch and I, with the cooperation of
TIGER's authors, recently arranged an OID for it:

	1.3.6.1.4.1.11591.12.2

It would be good to put this in 2440bis so TIGER will be usable.

I have a sneaking suspicion that this may raise the question whether
TIGER should be in the standard at all, as so long as it did not have
an OID, the question was moot.  I have no strong feelings on this
point, but if we are not going to allow the use of TIGER, then perhaps
we should remove it from the standard altogether or explicitly
disallow its use as the current halfway state is confusing now that
there is an OID available.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8R8BBm02806 for ietf-openpgp-bks; Fri, 27 Sep 2002 01:11:11 -0700 (PDT)
Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8R8B9v02795 for <[e-mail]>; Fri, 27 Sep 2002 01:11:10 -0700 (PDT)
Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id <[e-mail]>; Fri, 27 Sep 2002 10:05:51 0200
Message-ID: <[e-mail]>
Date: Fri, 27 Sep 2002 10:05:51 +0200
From: [e-mail]
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: security fixes (KDF, MDC->MAC)?
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> Hello OpenPGP,
> 
> Is there interest in fixing the security flaws discussed in the recent
> "security analysis" thread? -
> 
> (1) the Integrity Protected Data and MDC Packets fail to stop Schneier et
> al's attack, because the ciphertext blocks can be pasted into a
> non-integrity protected packet (ie ciphertext from a tag 18 packet can be
> placed in a tag 9 packet, evading the MDC).

5.13.
[...]    Unlike the Symmetrically Encrypted Data Packet, no
   special CFB resynchronization is done after encrypting this prefix
   data.

doesn't this prevent converting packet 18 to 9 ?

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPZP1EjBaTVEuJQxkEQOATQCgyqK8s+ckQ9Rdvv0gcMf7yro4TacAnjhj
iKE3L05dk1Crh2gv2pEMGkUL
=ZK80
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8QJIAO01218 for ietf-openpgp-bks; Thu, 26 Sep 2002 12:18:10 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8QJI8v01212 for <[e-mail]>; Thu, 26 Sep 2002 12:18:08 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Thu, 26 Sep 2002 12:11:13 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8QJI6E3032303 for <[e-mail]>; Thu, 26 Sep 2002 12:18:06 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TM7RD9BB>; Thu, 26 Sep 2002 12:18:05 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject:  security fixes (KDF, MDC->MAC)?
Date:  Thu, 26 Sep 2002 12:18:01 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

Hello OpenPGP,

Is there interest in fixing the security flaws discussed in the recent
"security analysis" thread? -

(1) the Integrity Protected Data and MDC Packets fail to stop Schneier et
al's attack, because the ciphertext blocks can be pasted into a
non-integrity protected packet (ie ciphertext from a tag 18 packet can be
placed in a tag 9 packet, evading the MDC).

(2) Once an attack like above recovered the prefix data, forgeries are
possible:
http://www.imc.org/ietf-openpgp/mail-archive/msg05804.html

One fix (due to John Kane) would be a version 2 of the integrity-protected
packet (tag 18).  This new version would use a key derivation function (KDF)
to derive separate encryption and authentication keys.  The authentication
key would be used by a new MAC packet (say tag 20), which would be just like
the MDC packet but use HMAC-SHA1 instead of SHA1.

Version = Integrity Protected Data Packet Version Number (2)
EncKey  = KDF(SessionKey, Version, 0)
AuthKey = KDF(SessionKey, Version, 1)

Since the encryption key is now the result of a version-dependent KDF,
downgrade attacks like (1) are prevented.

Since the MAC depends on the AuthKey which an attacker doesn't know,
forgeries (2) are prevented.

So what do people think?  Is a fix like this worth it?

Trevor


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8PB5p320507 for ietf-openpgp-bks; Wed, 25 Sep 2002 04:05:51 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PB5ov20499 for <[e-mail]>; Wed, 25 Sep 2002 04:05:50 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 8BD2E2C93; Wed, 25 Sep 2002 13:05:49 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8PB5l604730; Wed, 25 Sep 2002 13:05:47 +0200 (MEST)
Date: Wed, 25 Sep 2002 13:05:47 +0200
From: Bodo Moeller <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Sep 24, 2002 at 04:05:32PM -0700
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 Tue, Sep 24, 2002 at 04:05:32PM -0700, Jon Callas wrote:
> Bodo Moeller <[e-mail]>:

>> As I pointed out, you can use *self-signature* expiration (subpacket
>> type 3) for many purposes, and use *key* expiration (subpacket type 9)
>> for cases where you really want the key to expire [...] such that the
>> bad guy cannot unexpire the key.  What speaks against this?

> They mean separate things. A signature expiration on a self-signature
> expires the validity of that signature. If you have, for example, a key with
> two user names, expiration of that signature effectively expires that user
> id. They key expiration makes the whole key expire. If you did it with
> signature expirations, you'd have to manage every user id separately.


Now it all fits together.  It turns out that you can have it your way
and I can have it mine.


In your scenario, you need to set key expiration times in *direct-key*
self-signatures, and you want key lifetime to be extensible by
re-signing.

In my scenario, if you want expiration that cannot be undone, you set
a key expiration time in each *certification* self-signature.

All the time, you were talking about key expiration time sub-packets
in direct-key signatures while I was talking about key expiration time
sub-packets in certification signatures.  It's only the latter type of
expiration that should carry over into certifications by others.


Earlier I described my proposal like this:

     When Bob signs a certificate for Alice's key (which presumably he
     does only when Alice has told him that she considers her key
     valid), he looks at all valid self-signatures and finds the one
     for with key expiry is the furthest away.  This determines is the
     maximum validity he should use for his certification (unless
     Alice tells him otherwise).

This procedure should be changed as follows.  To determine the maximum
validity for his certification, Bob takes into account any key
expiration times found in *certification* self-signatures for the
respective user ID; not the key expiration times found in *direct-key*
self-signatures (these are relevant only for determining if the key is
currently valid).


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8P9Rwp12466 for ietf-openpgp-bks; Wed, 25 Sep 2002 02:27:58 -0700 (PDT)
Received: from freemail.agrinet.ch (freemail.agrinet.ch [212.28.134.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P9Rvv12462 for <[e-mail]>; Wed, 25 Sep 2002 02:27:57 -0700 (PDT)
Received: from syydelaervli.fortytwo.ch (81.6.8.94) by freemail.agrinet.ch (NPlex 5.1.056) id 3D90B8E300002037 for [e-mail]; Wed, 25 Sep 2002 11:27:45 +0200
Received: from atlas.acter.ch (unknown [212.126.160.108]) by syydelaervli.fortytwo.ch (Postfix) with ESMTP id 3A1ED995E for <[e-mail]>; Wed, 25 Sep 2002 11:27:44 +0200 (CEST)
Received: by atlas.acter.ch (Postfix, from userid 1047) id 435509793; Wed, 25 Sep 2002 11:27:43 +0200 (CEST)
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Adrian von Bidder <[e-mail]>
To: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DMOpxz2+S0m3DbTh4Afa"
X-Mailer: Ximian Evolution 1.0.8 
Date: 25 Sep 2002 11:27:43 +0200
Message-Id: <1032946063.6116.75.camel@atlas>
Mime-Version: 1.0
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>

--=-DMOpxz2+S0m3DbTh4Afa
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-09-24 at 16:37, Derek Atkins wrote:
> [...]If the
> attacker controls the keyserver and can remove revocations then
> obviously this doesn't work, but I don't think an attacker can control
> that many data points.

Depending on the attack scenario, it might suffice when one person does
not see a revocation certificate during a limited timeframe (while they
send some vital documents encrypted to the compromised key).

This only requires control of the network connection of one machine for
a specific time. Absolutely feasible.

cheers
-- vbi

--=20
secure email with gpg                           http://fortytwo.ch/gpg

NOTICE: subkey signature! request key 92082481 from keyserver.kjsl.com

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

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

iEYEABECAAYFAj2RgY8ACgkQKqpm2L3fmXqgYACfQteGqwFVke3x7TEsEc/18Sfj
VsIAn0klW45xn3g9Y3jjNiMQmv/TpDSI
=u0tA
-----END PGP SIGNATURE-----

--=-DMOpxz2+S0m3DbTh4Afa--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8P8JeI04330 for ietf-openpgp-bks; Wed, 25 Sep 2002 01:19:40 -0700 (PDT)
Received: from mail.glueckkanja.com (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P8Jcv04323 for <[e-mail]>; Wed, 25 Sep 2002 01:19:39 -0700 (PDT)
Content-Class: urn:content-classes:message
Subject: RE: Comments on ECC draft
Date: Wed, 25 Sep 2002 10:19:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on ECC draft
thread-index: AcJj9uMz10Bl4TTZQJ2HIsZWPnEZHgAcvhWg
From: "Dominikus Scherkl" <[e-mail]>
To: "Len Sassaman" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8P8Jev04327
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>

> Obviously, people's animosity for Certicom is going to
> get in the way of cleanly standardizing this.


> But, as long as ECC remains undefined in RFC2440bis
> and its successor, I wouldn't consider an implementation
> of ECC in OpenPGP to be violating the standard.

Of course not. That's why we insist for its addition
to the standard.

> If you're planning on putting it in CryptoEx,
> I'll be happy to make sure we interoperate with you.
We won't until it's part of the standard.
We've fully implemented all the mathematics, but integrating
it now will be about the same efford as to change it
after a different protocol is suddenly part of RFC 2440.

> I do agree, though, that your draft should pick a
> curve and stick with it, so that all the OpenPGP-ECC
> implementations are interoperable.

I don't think a single curve would be enough, because
it may have undiscovered weaknesses - and the curves
mentioned in my draft are already in use with other
standards, so I think it's a minimum requirement for
an implementation to support these.

But I agree that adding more curves should not be allowed
to everyone - new curves should be added to the standard
if they become nessessary (and that will be done VERY seldom).

to the draft:
Should I reduce my comments to domain parameters to
those nessessary to understand the format in which the
required curves are encoded? Or may I omit them at all?


By the way: I'm somewhat concerned about my mail to you
still not appeared on the list (and got no error report).
Is there something I must do before my mails are accepted?!?

-- 
Dominikus Scherkl
[e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8P1vwT25347 for ietf-openpgp-bks; Tue, 24 Sep 2002 18:57:58 -0700 (PDT)
Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P1vuv25342 for <[e-mail]>; Tue, 24 Sep 2002 18:57:56 -0700 (PDT)
Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id KAA22132; Wed, 25 Sep 2002 10:57:54 +0900
Message-Id: <[e-mail]>
From: Hironobu SUZUKI <[e-mail]>
To: Rodney Thayer <[e-mail]>
cc: [e-mail]
Subject: Re: Why ECC? 
In-reply-to: Your message of "Tue, 24 Sep 2002 07:58:55 MST." <5.1.1.6.2.20020924075702.01e32650@127.0.0.1> 
Date: Wed, 25 Sep 2002 10:57:54 +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>

> Why do we want ECC in OpenPGP?
> 

I'm not againts ECC in OpenPGP in the future.

If someone want to use strong public key cryptography protection as
well as RSA-2048, ECC-193 is good choice.  But I don't need it today.

I think if RSA-1024 is broken easily, a quantum computer must be. In
future, developed quantum computation technique will also break ECC
because problems are in almost same domain of number theorem.

Anyway, I'd like think about it tomorrow, not today.

Regards,

-- 
Hironobu SUZUKI
E-Mail: [e-mail]
URL: http://h2np.net




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OKbI910141 for ietf-openpgp-bks; Tue, 24 Sep 2002 13:37:18 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OKb9v10136 for <[e-mail]>; Tue, 24 Sep 2002 13:37:17 -0700 (PDT)
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 QAA23396 for <[e-mail]>; Tue, 24 Sep 2002 16:23:40 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id QAA23312 for <[e-mail]>; Tue, 24 Sep 2002 16:37:01 -0400 (EDT)
Message-ID: <00e401c26409$cff7c500$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "OpenPGP" <[e-mail]>
References: <00c001c263fb$a8d70480$[e-mail]> <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Tue, 24 Sep 2002 16:34:40 -0400
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-----
Hash: SHA1

From: "David Shaw" <[e-mail]>
> Whoah - I am not proposing that.  My comments were in the context of
> how a potential v5 key format could work (and as a side note on how
> GnuPG handles a v3 key with a v4 selfsig).  That's all.  As I see it,
> without an expiration date *in the key packet*, there is no true
> "hard" expiration date.  I agree with Jon's analysis.

OK... sorry about that.  I agree that a new key format could address this
if anyone cared enough.  (I don't.  Revocation is good enough... which
leads me to wonder how PGP/GnuPG would treat a post-dated revocation,
but that's another unnecessary digression. :-)

> GnuPG 1.0.6 is fairly old now.

It may be old in a CVS sense.  There's a lot of it out there, though...
it's in the RedHat 7.2AS and 7.3 releases, for example.  It was the
only official Windows build for a *long* time.

My point was not that GnuPG was wrong in any way, simply that some
widely installed versions wouldn't support the hard/soft distinction,
should we choose to make one now.

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

iQA/AwUBPZDMXVMkvpTT8vCGEQKmgwCfV/3TIKd4/fu1ew7Hrds3xme14y0AnRyF
gicmzX5IReIG1bHkdVmxXSDz
=UCC3
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OJcmh08721 for ietf-openpgp-bks; Tue, 24 Sep 2002 12:38:48 -0700 (PDT)
Received: from claude.kendall.corp.akamai.com (fw01.cmbrmaks.akamai.com [80.67.64.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OJclv08717 for <[e-mail]>; Tue, 24 Sep 2002 12:38:47 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.corp.akamai.com (8.11.6/8.11.6) id g8OJcjM21245 for [e-mail]; Tue, 24 Sep 2002 15:38:45 -0400
Date: Tue, 24 Sep 2002 15:38:44 -0400
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <00c001c263fb$a8d70480$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00c001c263fb$a8d70480$[e-mail]>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
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 Tue, Sep 24, 2002 at 02:53:23PM -0400, Michael Young wrote:

> A moment ago, I agreed with Jon's assertion that:
> > >Key expirations are not "my" system. They're the way the OpenPGP works. If
> > I agree with Jon's analysis.  Certainly, key expirations as they
> > are defined now are rewriteable.  His example (periodically
> 
> Sigh.  Perhaps I shouldn't have been quite so quick to agree.
> The last few drafts have included language on rewriting self-signatures,
> but I can't find any in the "original" (http://www.ietf.org/rfc/rfc2440.txt).
> This makes it a little hard to assert that this is just "how OpenPGP works".
> 
> BUT... this is "how GnuPG works" with respect to the act of
> rewriting, and it may just be "how PGP and GnuPG work" with
> respect to interpreting multiple expiration times.
> 
> Bodo an David have proposed using the key-expiration[9] and
> (self-)signature-expiration[3] subpackets as "hard" and "soft"
> flavors.  One could implement Jon's "rolling expiration"
> scenarios with the self-signatures.

Whoah - I am not proposing that.  My comments were in the context of
how a potential v5 key format could work (and as a side note on how
GnuPG handles a v3 key with a v4 selfsig).  That's all.  As I see it,
without an expiration date *in the key packet*, there is no true
"hard" expiration date.  I agree with Jon's analysis.

> Alas, neither PGP(6.5) nor GnuPG(1.0.6) generates a signature-
> expiration[3] subpacket.  GnuPG's expiration-changing function
> operates on the key-expiration[9] subpacket.

GnuPG 1.0.6 is fairly old now.  More recent versions allow the
(determined) user to generate themselves an expiring self-signature
(via subpacket 3).  When that self-signature expires, the user ID it
binds (not the key) becomes invalid.  Of course, you then end up with
a key with no valid user IDs.  This is as per 5.2.3.3. "Notes on
Self-Signatures" in bis-06.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OItfR05509 for ietf-openpgp-bks; Tue, 24 Sep 2002 11:55:41 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OItcv05494 for <[e-mail]>; Tue, 24 Sep 2002 11:55:38 -0700 (PDT)
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 OAA28560 for <[e-mail]>; Tue, 24 Sep 2002 14:42:13 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA22848 for <[e-mail]>; Tue, 24 Sep 2002 14:55:35 -0400 (EDT)
Message-ID: <00c001c263fb$a8d70480$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "OpenPGP" <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Tue, 24 Sep 2002 14:53:23 -0400
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-----
Hash: SHA1

A moment ago, I agreed with Jon's assertion that:
> >Key expirations are not "my" system. They're the way the OpenPGP works. If
> I agree with Jon's analysis.  Certainly, key expirations as they
> are defined now are rewriteable.  His example (periodically

Sigh.  Perhaps I shouldn't have been quite so quick to agree.
The last few drafts have included language on rewriting self-signatures,
but I can't find any in the "original" (http://www.ietf.org/rfc/rfc2440.txt).
This makes it a little hard to assert that this is just "how OpenPGP works".

BUT... this is "how GnuPG works" with respect to the act of
rewriting, and it may just be "how PGP and GnuPG work" with
respect to interpreting multiple expiration times.

Bodo an David have proposed using the key-expiration[9] and
(self-)signature-expiration[3] subpackets as "hard" and "soft"
flavors.  One could implement Jon's "rolling expiration"
scenarios with the self-signatures.

Alas, neither PGP(6.5) nor GnuPG(1.0.6) generates a signature-
expiration[3] subpacket.  GnuPG's expiration-changing function
operates on the key-expiration[9] subpacket.

When presented with two key-expiration versions, GnuPG appears to
accept the update (and throws away the old signature?).  PGP accepts
the update, and reports the new expiration time, but shows both
signatures.  Both PGP and GnuPG accept the new expiration time
for the purposes of encrypting; GnuPG ignores the expiration on
the main key, and accepts the one on the subkey.

I know that the specification need not be bound by quirks in
implementations, but as a practical matter, it doesn't feel
right to buck them here.  So, I come back to agreeing with Jon,
not just because the spec says so lately, but because the
implementations do, too.

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

iQA/AwUBPZC0nFMkvpTT8vCGEQL2IgCgsGbliVkzPb3mmB5IZQQ7wSp5AWAAnRhs
GXhshIQB2eBBVXJ63M2/m2lb
=xqJI
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OIetd04439 for ietf-openpgp-bks; Tue, 24 Sep 2002 11:40:55 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OIerv04426 for <[e-mail]>; Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
Received: by thetis.deor.org (Postfix, from userid 500) id E7F2E45026; Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id D398348023; Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
Date: Tue, 24 Sep 2002 11:40:53 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: Michael Young <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
In-Reply-To: <003d01c263f1$f92f73e0$[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 24 Sep 2002, Michael Young wrote:

> Given that this is how they work, I'd really like to see language
> in the expiration time section noting that they may be rewritten,
> and that as such, they do not have any revocation-like effects.
> Yes, this appears elsewhere, but someone reading the spec may
> not put the pieces together, and make assumptions on how
> expirations work (based on other systems or their intuition).
> I can draft something if you'd like.

This is what I was asking for in my previous message. In the case that
expired keys can be brought back from the dead, (which is the current
behavior), we need to make it clear that expirations are merely an
indication that the key may no longer be in use, and have no security
properties.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OHjvx01627 for ietf-openpgp-bks; Tue, 24 Sep 2002 10:45:57 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OHjuv01623 for <[e-mail]>; Tue, 24 Sep 2002 10:45:56 -0700 (PDT)
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 NAA27454 for <[e-mail]>; Tue, 24 Sep 2002 13:32:27 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA22492 for <[e-mail]>; Tue, 24 Sep 2002 13:45:49 -0400 (EDT)
Message-ID: <003d01c263f1$f92f73e0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "OpenPGP" <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Tue, 24 Sep 2002 13:44:02 -0400
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-----
Hash: SHA1

>Key expirations are not "my" system. They're the way the OpenPGP works. If
> 
I agree with Jon's analysis.  Certainly, key expirations as they
are defined now are rewriteable.  His example (periodically
pushing the expiration out to account for possible LOSS) is
quite reasonable.  It MIGHT HAVE been reasonable to include
a form of irrevocable expiration that acts as an automatic
revocation (possibly in addition to the revocable, advisory
kind), but that's just not the way it works now.

Given that this is how they work, I'd really like to see language
in the expiration time section noting that they may be rewritten,
and that as such, they do not have any revocation-like effects.
Yes, this appears elsewhere, but someone reading the spec may
not put the pieces together, and make assumptions on how
expirations work (based on other systems or their intuition).
I can draft something if you'd like.

> We've even had discussions here for years about re-writing
> self-sigs and what you should do, and how you should interpret them, and
> what happens when you have things like a designated revoker.

This is another digression, but...

While I strongly believe in the ability to rewrite self-signatures, I
wouldn't go as far as to require that *all* subpackets be treated the
same in this regard.  For some, it might make sense for new values to
replace the old (preferences); here, I have argued that the old
self-signature should be revoked, but that didn't seem to catch on.
For some, new values may be additive; revocation keys have this
flavor -- they make no sense if they can be removed.
My point is simply that we shouldn't take the rewriting behavior
for key expiration as a general principle, or vice versa.

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

iQA/AwUBPZCkW1MkvpTT8vCGEQJYDQCfcGO5NQc0AL3oI/ElDcJxzJ/BLpcAn1Ad
Pp5Wp92lT4bFdDaU+n6r2pbp
=oiVp
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OH5a129315 for ietf-openpgp-bks; Tue, 24 Sep 2002 10:05:36 -0700 (PDT)
Received: from claude.kendall.corp.akamai.com (fw01.cmbrmaks.akamai.com [80.67.64.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OH5Zv29311 for <[e-mail]>; Tue, 24 Sep 2002 10:05:35 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.corp.akamai.com (8.11.6/8.11.6) id g8OH5Wb15311 for [e-mail]; Tue, 24 Sep 2002 13:05:32 -0400
Date: Tue, 24 Sep 2002 13:05:32 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
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 Tue, Sep 24, 2002 at 06:08:17PM +0200, [e-mail] wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> 
> Bodo Moeller wrote:
> > Of course the one problem we cannot avoid is that the legitimate owner
> > of the key cannot keep the key alive indefinitely.  This is because
> > this "problem" is exactly the security feature that me and Florian
> > Weimer and Derek Atkins want to have: we don't want the bad guy to be
> > able to unexpire the key if he gets hold of the secret key.
> 
> so set key expiration in direct key signature. there can be only
> one direct key signature. direct key signature is self signature (5.2.3.3)
> so key expiration can be set in it. (though most PGP implementations may
> not recognize key expiration in direct key signature....)

It is not true that there can be only one direct key signature.  In
fact, in certain cases you pretty much must have more than one.  For
example, if you have multiple designated revokers which are all
sensitive.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OGmJL28528 for ietf-openpgp-bks; Tue, 24 Sep 2002 09:48:19 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OGmHv28522 for <[e-mail]>; Tue, 24 Sep 2002 09:48:17 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8OGmDNF026227; Wed, 25 Sep 2002 04:48:13 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA76653; Wed, 25 Sep 2002 04:48:13 +1200 (NZST) (sender [e-mail])
Date: Wed, 25 Sep 2002 04:48:13 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why ECC?
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:
>At 03:18 AM 9/25/2002 +1200, Peter Gutmann wrote:
>>Because it already contains every algorithm anyone could think of anyway, 
>>and a few more for implementors to ignore wouldn't matter?
>
>I took Peter's comment as a joke, a jab at the load of things already there.

It was intended as a joke, although you have to be quite careful here because
these things tend to come true - PKIX is currently busy standardising something
which started as a joke by Bob Jueneman some years ago and which I suggested as
an April 1 RFC more recently.  Hmm, there's a thought:

<loudly>
Next thing you know I'll walk out the door and trip over the brand-new Sun 
15K which someone left there for me.
</loudly>

Peter (ever hopeful).


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OGDha26429 for ietf-openpgp-bks; Tue, 24 Sep 2002 09:13:43 -0700 (PDT)
Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8OGDev26424 for <[e-mail]>; Tue, 24 Sep 2002 09:13:42 -0700 (PDT)
Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id <[e-mail]>; Tue, 24 Sep 2002 18:08:17 0200
Message-ID: <[e-mail]>
Date: Tue, 24 Sep 2002 18:08:17 +0200
From: [e-mail]
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Bodo Moeller wrote:
> Of course the one problem we cannot avoid is that the legitimate owner
> of the key cannot keep the key alive indefinitely.  This is because
> this "problem" is exactly the security feature that me and Florian
> Weimer and Derek Atkins want to have: we don't want the bad guy to be
> able to unexpire the key if he gets hold of the secret key.

so set key expiration in direct key signature. there can be only
one direct key signature. direct key signature is self signature (5.2.3.3)
so key expiration can be set in it. (though most PGP implementations may
not recognize key expiration in direct key signature....)

5.2.3.6. Key expiration time
   (4 octet time field)
   The validity period of the key.  This is the number of seconds after
   the key creation time that the key expires.  If this is not present
   or has a value of zero, the key never expires. This is found only on
                                                          ^^^^^^^^^^^^^
   a self-signature.
   ^^^^^^^^^^^^^^^^   

5.2.3.3. Notes on Self-Signatures
   A self-signature is a binding signature made by the key the
   signature refers to. There are three types of self-signatures, the
   certification signatures (types 0x10-0x13), the direct-key signature
                                               ^^^^^^^^^^^^^^^^^^^^^^^^
   (type 0x1f), and the subkey binding signature (type 0x18).

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPZBxrDBaTVEuJQxkEQPdiwCgsuV/1HKjEyJLLFe7QFGWNfg205sAoJyi
0yuLte8T0wJyyBPh3A+g62dr
=BtSp
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OGBBl26133 for ietf-openpgp-bks; Tue, 24 Sep 2002 09:11:11 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OGB9v26125 for <[e-mail]>; Tue, 24 Sep 2002 09:11:09 -0700 (PDT)
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 LAA14936 for <[e-mail]>; Tue, 24 Sep 2002 11:57:43 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id MAA21897 for <[e-mail]>; Tue, 24 Sep 2002 12:11:05 -0400 (EDT)
Message-ID: <001301c263e4$be29d0e0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <5.1.1.6.2.20020924082608.028bd5f8@127.0.0.1>
Subject: Re: Why ECC?
Date: Tue, 24 Sep 2002 12:09:20 -0400
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-----
Hash: SHA1

> At 03:18 AM 9/25/2002 +1200, Peter Gutmann wrote:
> >Because it already contains every algorithm anyone could think of anyway, 
> >and a
> >few more for implementors to ignore wouldn't matter?

I took Peter's comment as a joke, a jab at the load of things already there.

From: "Rodney Thayer" <[e-mail]>
> -- we alread have DSA for that.  (Well if we want to claim RSA and DSA are
> structurally related we don't but that's not the question at hand)

If we're going to fantasize about future breakthroughs, we could also
speculate that ECC and the integer DLP problems will be structurally related.

> The second thing we're doing is violating the "it should be implementable"
> principle.  These RFC's are supposed to be buildable by normal mortals.

I agree with this sentiment.  Interoperability for the masses is
important.  It's also fine to have a place for experimenters to
play, but there shouldn't be much pressure to get such things into
the specification.

> So, I come back to my question -- why do we want ECC?  If there isn't
> a requirement it fulfills it shouldn't be in the standard -- it just
> takes up space and causes problems.

At least in the last proposal I read, it takes up a LOT of space.
There were a dozen representation options.  It seemed quite unlikely
that anyone would implement more than a small subset.  Good luck
finding other interoperable implementations.

I'd be very happy for this to remain a separate document.

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

iQA/AwUBPZCOLlMkvpTT8vCGEQKD7ACg1px3nQlElzbI/jzOjsdNvOIF9CoAoIg5
XgV8+vrU/RjspqiKWoZejBkp
=kDhI
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OFZ9O23546 for ietf-openpgp-bks; Tue, 24 Sep 2002 08:35:09 -0700 (PDT)
Received: from yancy.pkiclue.com (IDENT:[e-mail] [209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OFZ7v23542 for <[e-mail]>; Tue, 24 Sep 2002 08:35:07 -0700 (PDT)
Received: from rt-dt.pkiclue.com (IDENT:root@LOCALHOST [127.0.0.1]) by yancy.pkiclue.com (8.9.3/8.9.3) with ESMTP id IAA22293 for <[e-mail]>; Tue, 24 Sep 2002 08:35:04 -0700
Message-Id: <5.1.1.6.2.20020924082608.028bd5f8@127.0.0.1>
X-Sender: pkiclue@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Tue, 24 Sep 2002 08:30:28 -0700
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: Re:  Why ECC?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
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 03:18 AM 9/25/2002 +1200, Peter Gutmann wrote:
>Rodney Thayer <[e-mail]> writes:
>
> >Why do we want ECC in OpenPGP?
>
>Because it already contains every algorithm anyone could think of anyway, 
>and a
>few more for implementors to ignore wouldn't matter?

Well as I see it there's the "lifeboat" principle.  If someone, somewhere,
publishes a 3-line perl script that breaks 2048 bit RSA, we'd like to have
a second public key algorithm in the protocol spec so we could switch over.

This has two problems:

-- the powers that be in the IETF tend to spit in your eye when you propose
this class of logic.  Been there, tried that.  They assume RSA is immortal.

-- we alread have DSA for that.  (Well if we want to claim RSA and DSA are
structurally related we don't but that's not the question at hand)

The second thing we're doing is violating the "it should be implementable"
principle.  These RFC's are supposed to be buildable by normal mortals.
Adding 80,000 bells and whistles is stupid -- we get specs that are
hard to implement, hard to interoperate, and hard to read (for things
like security flaws).

So, I come back to my question -- why do we want ECC?  If there isn't
a requirement it fulfills it shouldn't be in the standard -- it just
takes up space and causes problems.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OFIf423248 for ietf-openpgp-bks; Tue, 24 Sep 2002 08:18:41 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OFIdv23244 for <[e-mail]>; Tue, 24 Sep 2002 08:18:39 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8OFIVNF024748; Wed, 25 Sep 2002 03:18:31 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA52964; Wed, 25 Sep 2002 03:18:31 +1200 (NZST) (sender [e-mail])
Date: Wed, 25 Sep 2002 03:18:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Why ECC?
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 <[e-mail]> writes:

>Why do we want ECC in OpenPGP?

Because it already contains every algorithm anyone could think of anyway, and a
few more for implementors to ignore wouldn't matter?

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OF8OQ22878 for ietf-openpgp-bks; Tue, 24 Sep 2002 08:08:24 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OF8Mv22872 for <[e-mail]>; Tue, 24 Sep 2002 08:08:22 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 353B52C91; Tue, 24 Sep 2002 17:08:23 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8OF8L304462; Tue, 24 Sep 2002 17:08:21 +0200 (MEST)
Date: Tue, 24 Sep 2002 17:08:20 +0200
From: Bodo Moeller <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Sep 24, 2002 at 10:37:06AM -0400
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 Tue, Sep 24, 2002 at 10:37:06AM -0400, Derek Atkins wrote:

> Before you go putting words in my mouth...

I didn't.  You wrote:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
From: Derek Atkins <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt

> Please point out an advantage of *key* expiration over
> *self-signature* expiration in that scenario.

A bad guy gets a copy of my private key..  If there is a key
expiration then they cannot keep it alive indefinitely.  Or is key
compromise not an attack you care about? ;)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

So apparently you think that key expiration should be final while
self-signature expiration is not.  If you have a different
interpretation of what you wrote, I'd like to hear it.


> [...]                            I agree with Jon that you need to
> separate out the "this key is alive" from "this key is dead".  The
> "Keepalives" are self-signatures with limited lifetimes.

This is exactly what I am saying: use self-signatures with limited
lifetime (subpacket type 3) if you want to be able to keep the key
alive by re-signing later.  And use self-signatures with a key
expiration time (subpacket type 9) only if you want the key to finally
expire by then.

We have these two different subpacket types, so why not use them?!


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OF5L222674 for ietf-openpgp-bks; Tue, 24 Sep 2002 08:05:21 -0700 (PDT)
Received: from yancy.pkiclue.com (IDENT:[e-mail] [209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OF5Kv22669 for <[e-mail]>; Tue, 24 Sep 2002 08:05:20 -0700 (PDT)
Received: from rt-dt.pkiclue.com (IDENT:root@LOCALHOST [127.0.0.1]) by yancy.pkiclue.com (8.9.3/8.9.3) with ESMTP id IAA22183 for <[e-mail]>; Tue, 24 Sep 2002 08:05:08 -0700
Message-Id: <5.1.1.6.2.20020924075702.01e32650@127.0.0.1>
X-Sender: pkiclue@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Tue, 24 Sep 2002 07:58:55 -0700
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: Why ECC?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
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 07:02 PM 9/24/2002 +1200, Peter Gutmann wrote:

>Len Sassaman <[e-mail]> writes:
>
> >OpenSSL now has ECC in it
>
>That's not certain yet, the licensing terms are such that it can't be used
>under the OpenSSL license unless Sun re-release it unencumbered.
>
> >and there is an ECC in TLS draft being proposed
>
>... by the same group who did the OpenSSL implementation.  Hardly an
>overwhelming argument.


Why do we want ECC in OpenPGP?

Why do we want to start using a class of algorithm that is patent encumbered?

Having corporations show up at working group meetings and threaten implementors
with patent infringement is a pain.

I don't see a requirement to add this.

A separate document describing it would of course be perfectly reasonable.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OEbRl21753 for ietf-openpgp-bks; Tue, 24 Sep 2002 07:37:27 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OEbQv21749 for <[e-mail]>; Tue, 24 Sep 2002 07:37:26 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA00219; Tue, 24 Sep 2002 10:37:24 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA15537; Tue, 24 Sep 2002 10:37:12 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26516; Tue, 24 Sep 2002 10:37:06 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA13920; Tue, 24 Sep 2002 10:37:06 -0400 (EDT)
To: Bodo Moeller <[e-mail]>
Cc: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
From: Derek Atkins <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: 24 Sep 2002 10:37:06 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 99
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8OEbQv21750
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>

Before you go putting words in my mouth...

There are two opposing forces here. On the one had I want to be able
to continue using my key indefinitely (re-keying is a PitA).  On the
other hand, if it gets compromised I want to kill it (and make sure
the attacker cannot un-kill it).  The third case is where the user
loses their private key.

To make all three of these work, I agree with Jon that you need to
separate out the "this key is alive" from "this key is dead".  The
"Keepalives" are self-signatures with limited lifetimes.  I don't mind
re-signing my own key every year (or whatever period I want to
re-assert myself).  Note that this time period should not affect the
time period with which Alice asserts my key -- Alice should decide how
often they want to re-verify my key, I shouldn't dictate that to
Alice.

The "this key is dead" is necessarily a revocation.  If you go under
the assumption that data can only be added to a key and never removed,
then once you see a revocation anything else doesn't matter.  If the
attacker controls the keyserver and can remove revocations then
obviously this doesn't work, but I don't think an attacker can control
that many data points.

All I except from the system is that an attacker who gains access to
your private key cannot make it live longer than YOU want it to.

-derek

Bodo Moeller <[e-mail]> writes:

> As I pointed out, you can use *self-signature* expiration (subpacket
> type 3) for many purposes, and use *key* expiration (subpacket type 9)
> for cases where you really want the key to expire in the sense that
> Derek and others expect key expiration to work (namely such that the
> bad guy cannot unexpire the key).  What speaks against this?
> 
> For version 3 keys, key expiration carries over into certifications,
> and many users expect similar security properties for version 4 keys.
> 
> Notably, even Derek expected this, and still you refuse to even
> mention this bug/feature/misunderstanding in the Security
> Considerations of the specification.
> 
> 
> 
> >                             Lastly, I claim that if you want to kill a key,
> > there is a mechanism for that -- revocation. [...]
> > Expiration is not revocation. Do not expect it to solve the problem of
> > revocation. Likewise, revocation is not expiration. Revocation is
> > irrevocable. Expiration can be undone. This is the design of the language of
> > the system. The present behavior is in my opinion the correct and desirable
> > one.
> 
> I already commented on this:
> 
> < Compared with key expiry (and I mean final expiry that cannot simply
> < be undone by anyone who has gotten hold of the secret key), revocation
> < is somewhat of a kludge.  In some situations it is the best you can
> < do, but the problem is that the semantics is not monotonous.  This may
> < be fun for AI people, but security folks should be worried about the
> < ramifications of denial of service attacks (nothing guarantees that
> < the revocation reaches everyone who should know about it).
> 
> If it's not clear what I mean with this I should probably formalize
> the concepts and write a paper about the issue unless someone has
> already done something like that.  Some keywords: formal proof
> systems, default logic.
> 
> You say "revocation is irrevocable".  This is true in a sense, but
> revocation is not as reliable as expiration that cannot be undone.
> 
> You say "expiration can be undone", but we also need some kind of
> expiration that cannot be undone.  OpenPGP distinguishes between key
> expiration and signature expiration, so we can use key expiration if
> we want expiration that cannot be undone, and self-signature
> expiration if we want expiration that can be undone.
> 
> 
> 
> A signing key has become invalid in the fullest sense only if you can
> publish the corresponding secret key without causing any problems.
> PKIs should offer entities a way to state that their keys are to be
> considered invalid after some specific point of time.  Revocation does
> not do this job very well because revocation packets may be
> suppressed, so the invalidity date must be covered by the
> certifications instead.
> 
> 
> -- 
> Bodo Möller <[e-mail]>
> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
> * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
> * Tel. [phone], Fax [phone]

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OD2mK16302 for ietf-openpgp-bks; Tue, 24 Sep 2002 06:02:48 -0700 (PDT)
Received: from localhost.localdomain (walrus.ne.client2.attbi.com [65.96.217.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OD2lv16298 for <[e-mail]>; Tue, 24 Sep 2002 06:02:47 -0700 (PDT)
Received: (from dshaw@localhost) by localhost.localdomain (8.11.6/8.11.6) id g8OD2ao00387 for [e-mail]; Tue, 24 Sep 2002 09:02:36 -0400
Date: Tue, 24 Sep 2002 09:02:36 -0400
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]> <00d101c2634b$1b4e2b80$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
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 Tue, Sep 24, 2002 at 10:58:38AM +0200, Bodo Moeller wrote:

> < By default GnuPG uses the expiration date of the self-signature as the
> < one for a key signature.  This is on Florian Weimer's request and afaik
> < is sufficient for him and his use of the PGP PKI.
> 
> I hope Werner meant the *key* expiration date from the self-signature,
> not the *signature* expiration date from the self-signature.  These
> are different packet types.  Key expiration dates may be present only
> in self-signatures according to the OpenPGP specification, so they
> should be translated into signature expiration dates when certifying
> keys; see Florians request at
> <URL:http://lists.gnupg.org/pipermail/gnupg-devel/2001-July/006196.html>:

It is the key expiration date (i.e. subpacket 9, not subpacket 3).  I
want to point out that this is not something that GnuPG forces on the
user.  If a key has an expiration date, GnuPG prompts the user "This
key is due to expire on x/x/x.  Do you want your signature do expire
at the same time? (Y/n)".  If the signing user says "yes" (the
default), then that happens.  If the signing user says no, then they
are free to pick any expiration time, or none at all.  I think that is
the most appropriate solution here as the signer is still free to do
whatever they like.

In an ideal world (which we are not in), I think that a solution that
would solve all the concerns here is to define a v5 key format.  It
could contain an expiration date as part of the key, just like in v3
keys.  The expiration date in the key is the "hard" expiration.  The
user can shorten, but not extend, this via the "soft" expiration date
given in the self-signature.  (Incidentally, this is what GnuPG does
when it encounters v3 keys with v4 self-signatures.)  Of course, a new
key format would be brutal for interoperability, so is not a good
solution.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OBJ1v09624 for ietf-openpgp-bks; Tue, 24 Sep 2002 04:19:01 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OBIxv09616 for <[e-mail]>; Tue, 24 Sep 2002 04:18:59 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id A95B42C91; Tue, 24 Sep 2002 13:18:59 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8OBIwa03843; Tue, 24 Sep 2002 13:18:58 +0200 (MEST)
Date: Tue, 24 Sep 2002 13:18:57 +0200
From: Bodo Moeller <[e-mail]>
To: Michael Young <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Message-ID: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]> <00b701c2633a$6c5a37a0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <00b701c2633a$6c5a37a0$[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 03:50:06PM -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 23, 2002 at 03:50:06PM -0400, Michael Young wrote:

> Certifications are statements about the ownership of a key, not its
> lifetime; it should be legal to make a certification that will outlast
> the key's (CURRENT) expiration time.

Legal?  Of course; the signer may have out-of-band information that a
long certification validity period is OK.  But by default, the current
key expiration time should not be exceeded.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8OAZCc05330 for ietf-openpgp-bks; Tue, 24 Sep 2002 03:35:12 -0700 (PDT)
Received: from mail.glueckkanja.com (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OAZAv05322 for <[e-mail]>; Tue, 24 Sep 2002 03:35:11 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Comments on ECC draft
Date: Tue, 24 Sep 2002 12:35:05 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: Comments on ECC draft
thread-index: AcJjTjiZaGHl8GkrR6Gx2zu+saQuiQATRJJQAAZxx3A=
From: "Dominikus Scherkl" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8OAZCv05327
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hello.

> I'd like to bring this up again before the next revision of 
> the draft. How close are we to consensus on the ECC semantics?

Really?
Indeed I thought there isn't anybody interessted in this...
what a very positive surprise.

> On Wed, 5 Sep 2001 [e-mail] wrote:
> 
> > We have been looking at the ECC issue and have a few 
> > comments on the proposed draft by Dominikus Scherkl and
> > Christoph Fausak.
> >
> > Broadly speaking it looks very good.

As the IEEE has changed it's proposed standard P1363 to allow
for an additionaly point-compression method with no patents
on it (I worked hardly on this), we should have no problem
with this topic.
But I don't know about the current status of other pending
patents. (Looking at Annex G of IEEE P1363a/D10.8 may be a good
idea, but most of the patents mentioned there cover other parts
of that proposed standard).

I will soon submit an updated version of my (long ago expired)
draft soon...

> I'm not against ECC in OpenPGP, but given how close 2440bis 
> is to last call, perhaps the ECC specification could go in a
> companion RFC?
This way is what I intended with my draft.
And I think there's no need to hurry, too, but

> > OpenSSL now has ECC in it, and there is an ECC in TLS draft 
> > being proposed
> That's not certain yet, [and the TLS draft is]
> ... by the same group who did the OpenSSL implementation.

do we realy need to be the last to add ECC to our standard ?

Best regards,
-- 
Dominikus Scherkl
[e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O9LWj29532 for ietf-openpgp-bks; Tue, 24 Sep 2002 02:21:32 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O9LUv29528 for <[e-mail]>; Tue, 24 Sep 2002 02:21:30 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 2101C2C8E; Tue, 24 Sep 2002 11:21:30 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8O9LTb03640; Tue, 24 Sep 2002 11:21:29 +0200 (MEST)
Date: Tue, 24 Sep 2002 11:21:28 +0200
From: Bodo Moeller <[e-mail]>
To: Len Sassaman <[e-mail]>
Cc: Michael Young <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Message-ID: <[e-mail]>
References: <00d101c2634b$1b4e2b80$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 04:44:23PM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 23, 2002 at 04:44:23PM -0700, Len Sassaman wrote:

> Wasn't the original suggestion that keys expire at the earliest expiration
> time, and later expiration dates be ignored?

No, that was not my proposal.  This was a suggestion by Richie Laager,
but actually it's incompatible with some details of my proposal:
it's okay for me to let key lifetime be extensible, it's just that
certifications should be valid only for the currently defined lifetime
of the key (during certification) so that all certifications become
worthless if the user lets the key expire.

It would be safer to have a fixed key expiry date as in version 3 keys
(but to have it covered by the fingerprint, unlike version 3).
However, I want compatibility with the version 4 format, and this
makes extensible key lifetime acceptable within my proposal.


>                                              That would address the
> problem.

But not actually solve it: in general you cannot rely on seeing all
packets that are available on some keyserver, or that someone tries to
send to some keyserver (cf. my remarks on non-monotonous proof systems
elsewhere in this thread; this is essentially the same problem as with
revocation).  The "earliest expiration time" according to your keyring
may not be the actual earliest expiration time.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O8wgd27027 for ietf-openpgp-bks; Tue, 24 Sep 2002 01:58:42 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O8wev27020 for <[e-mail]>; Tue, 24 Sep 2002 01:58:40 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 3B7142C8E; Tue, 24 Sep 2002 10:58:40 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8O8wcs03623; Tue, 24 Sep 2002 10:58:38 +0200 (MEST)
Date: Tue, 24 Sep 2002 10:58:38 +0200
From: Bodo Moeller <[e-mail]>
To: Michael Young <[e-mail]>
Cc: OpenPGP <[e-mail]>, Werner Koch <[e-mail]>
Subject: Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <00d101c2634b$1b4e2b80$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <00d101c2634b$1b4e2b80$[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 05:49:34PM -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 23, 2002 at 05:49:34PM -0400, Michael Young wrote:
> "Len Sassaman" <[e-mail]>:

>> The question I see is this: are key expiration dates a "mandate" or a
>> "suggestion" to third parties by the key owner?

> More precisely, are expiration times rewriteable?
> 
> I'm afraid that the answer has to be YES.  The specification has
> clearly said so for a while now, and at least one implementation
> (GnuPG) offers this capability.  If we change the rules now,
> anyone who has taken advantage of it (or set a short expiration
> time with the expectation that they can change it) will be
> seriously disappointed.

Actually, they won't!

My proposal was: When Bob signs a certificate for Alice's key (which
presumably he does only when Alice has told him that she considers her
key valid), he looks at all valid self-signatures and finds the one
for with key expiry is the furthest away.  This determines is the
maximum validity he should use for his certification (unless Alice
tells him otherwise).

So if your key has a short expiration time, you can extend it, and new
certifications will use the new expiration time.



You mentioned GnuPG.  Note that GnuPG apparently already handles key
expiration in a safe way during certification:

< From: Werner Koch <[e-mail]>
< To: Jon Callas <[e-mail]>
< Cc: Bodo Moeller <[e-mail]>,
< 	OpenPGP <[e-mail]>
< Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
< Date: Sat, 21 Sep 2002 11:59:22 +0200

< By default GnuPG uses the expiration date of the self-signature as the
< one for a key signature.  This is on Florian Weimer's request and afaik
< is sufficient for him and his use of the PGP PKI.

I hope Werner meant the *key* expiration date from the self-signature,
not the *signature* expiration date from the self-signature.  These
are different packet types.  Key expiration dates may be present only
in self-signatures according to the OpenPGP specification, so they
should be translated into signature expiration dates when certifying
keys; see Florians request at
<URL:http://lists.gnupg.org/pipermail/gnupg-devel/2001-July/006196.html>:

< [My patch] is a bit more complicated because it also works around the
< protocol error in RFC 2440 related to V4 key expiration (V4 key
< expiration time is not covered by certificates because it is only
< contained in the self signature, not in the key material, in contrast
< to V3 keys): If the key to be signed is a V4 key with an expiration
< time set, a V4 signature is made which expires at that time, too (or
< even earlier).


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O8cVH24550 for ietf-openpgp-bks; Tue, 24 Sep 2002 01:38:31 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O8cTv24546 for <[e-mail]>; Tue, 24 Sep 2002 01:38:30 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 358872C8E; Tue, 24 Sep 2002 10:38:29 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8O8cRA03610; Tue, 24 Sep 2002 10:38:27 +0200 (MEST)
Date: Tue, 24 Sep 2002 10:38:26 +0200
From: Bodo Moeller <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 10:29:07PM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 23, 2002 at 10:29:07PM -0700, Jon Callas wrote:

> Now, as Bodo has suggested, there's a potential ambiguity here. In short,
> what does it mean if Alice signs your key with no expiration (or one that is
> after Ta)? Bodo suggests that this is a flaw. I claim it is not. If Alice
> had wished to time-limit her certification, she should have, and it's not
> for us to tell her how to do it.
>
> I further claim that while this may be somewhat counterintuitive, it is a
> useful and desirable feature, for someone to have different expirations on a
> key depending on situation.

As I pointed out, you can use *self-signature* expiration (subpacket
type 3) for many purposes, and use *key* expiration (subpacket type 9)
for cases where you really want the key to expire in the sense that
Derek and others expect key expiration to work (namely such that the
bad guy cannot unexpire the key).  What speaks against this?

For version 3 keys, key expiration carries over into certifications,
and many users expect similar security properties for version 4 keys.

Notably, even Derek expected this, and still you refuse to even
mention this bug/feature/misunderstanding in the Security
Considerations of the specification.



>                             Lastly, I claim that if you want to kill a key,
> there is a mechanism for that -- revocation. [...]
> Expiration is not revocation. Do not expect it to solve the problem of
> revocation. Likewise, revocation is not expiration. Revocation is
> irrevocable. Expiration can be undone. This is the design of the language of
> the system. The present behavior is in my opinion the correct and desirable
> one.

I already commented on this:

< Compared with key expiry (and I mean final expiry that cannot simply
< be undone by anyone who has gotten hold of the secret key), revocation
< is somewhat of a kludge.  In some situations it is the best you can
< do, but the problem is that the semantics is not monotonous.  This may
< be fun for AI people, but security folks should be worried about the
< ramifications of denial of service attacks (nothing guarantees that
< the revocation reaches everyone who should know about it).

If it's not clear what I mean with this I should probably formalize
the concepts and write a paper about the issue unless someone has
already done something like that.  Some keywords: formal proof
systems, default logic.

You say "revocation is irrevocable".  This is true in a sense, but
revocation is not as reliable as expiration that cannot be undone.

You say "expiration can be undone", but we also need some kind of
expiration that cannot be undone.  OpenPGP distinguishes between key
expiration and signature expiration, so we can use key expiration if
we want expiration that cannot be undone, and self-signature
expiration if we want expiration that can be undone.



A signing key has become invalid in the fullest sense only if you can
publish the corresponding secret key without causing any problems.
PKIs should offer entities a way to state that their keys are to be
considered invalid after some specific point of time.  Revocation does
not do this job very well because revocation packets may be
suppressed, so the invalidity date must be covered by the
certifications instead.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O7kf114243 for ietf-openpgp-bks; Tue, 24 Sep 2002 00:46:41 -0700 (PDT)
Received: from mail.glueckkanja.com (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O7kcv14233 for <[e-mail]>; Tue, 24 Sep 2002 00:46:40 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on ECC draft
Date: Tue, 24 Sep 2002 09:46:28 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on ECC draft
thread-index: AcJjTjiZaGHl8GkrR6Gx2zu+saQuiQATRJJQ
From: "Dominikus Scherkl" <[e-mail]>
To: "Len Sassaman" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8O7kfv14239
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'd like to bring this up again before the next revision of 
> the draft. How close are we to consensus on the ECC semantics?

Really?
Indeed I thought there isn't anybody interessted in this...
what a very positive surprise.

> On Wed, 5 Sep 2001 [e-mail] wrote:
> 
> > We have been looking at the ECC issue and have a few comments on the
> > proposed draft by Dominikus Scherkl and Christoph Fausak.
> >
> > Broadly speaking it looks very good.

As the IEEE has changed it's proposed standard P1363 to allow
for an additionaly point-compression method with no patents
on it (I worked hardly on this), we should have no problem
with this topic.
But I don't know about the current status of other pending
patents.

I will soon submit an updated version of my (long ago expired)
draft soon...

> I'm not against ECC in OpenPGP, but given how close 2440bis is to last
> call, perhaps the ECC specification could go in a companion RFC?
This way is what I intended with my draft.
And I think there's no need to hurry, too, but

> > OpenSSL now has ECC in it, and there is an ECC in TLS draft 
> > being proposed
> That's not certain yet, [and the TLS draft is]
> ... by the same group who did the OpenSSL implementation.

do we realy need to be the last to add ECC to our standard ?

-- 
Dominikus Scherkl
[e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O7bGS12987 for ietf-openpgp-bks; Tue, 24 Sep 2002 00:37:16 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O7bFv12981 for <[e-mail]>; Tue, 24 Sep 2002 00:37:15 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id EB9362C8E; Tue, 24 Sep 2002 09:37:13 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8O7bCM03590; Tue, 24 Sep 2002 09:37:12 +0200 (MEST)
Date: Tue, 24 Sep 2002 09:37:12 +0200
From: Bodo Moeller <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on ECC draft
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Sep 24, 2002 at 07:02:44PM +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>

On Tue, Sep 24, 2002 at 07:02:44PM +1200, Peter Gutmann wrote:
> Len Sassaman <[e-mail]> writes:

>> OpenSSL now has ECC in it

> That's not certain yet, the licensing terms are such that it can't be used
> under the OpenSSL license unless Sun re-release it unencumbered.

Sun has nothing to do with the OpenSSL ECC implementation for GF(p).
ECC over GF(2^m) is due to Sun and is specifically "licensed pursuant
to the OpenSSL open source license".  There's an additional covenant
regarding patents, but nothing patent-encumbered should be enabled in
the default configuration (if you want GF(2^m) ECC to be faster, you
can set a compiler switch; in this case you have to accept the Sun
covenant).


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O73jx08714 for ietf-openpgp-bks; Tue, 24 Sep 2002 00:03:45 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O73gv08703 for <[e-mail]>; Tue, 24 Sep 2002 00:03:43 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g8O72mNF017872; Tue, 24 Sep 2002 19:02:48 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA39132; Tue, 24 Sep 2002 19:02:44 +1200 (NZST) (sender [e-mail])
Date: Tue, 24 Sep 2002 19:02:44 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Comments on ECC draft
Cc: [e-mail], [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>

Len Sassaman <[e-mail]> writes:

>OpenSSL now has ECC in it

That's not certain yet, the licensing terms are such that it can't be used
under the OpenSSL license unless Sun re-release it unencumbered.

>and there is an ECC in TLS draft being proposed 

... by the same group who did the OpenSSL implementation.  Hardly an
overwhelming argument.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8O5TJ325872 for ietf-openpgp-bks; Mon, 23 Sep 2002 22:29:19 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O5TDv25868 for <[e-mail]>; Mon, 23 Sep 2002 22:29:16 -0700 (PDT)
Received: from [67.194.145.196] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Mon, 23 Sep 2002 22:29:03 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Mon, 23 Sep 2002 22:29:07 -0700
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Actually, this has digressed.

Key expirations are not "my" system. They're the way the OpenPGP works. If
you create a key with an expiration and hand it to Alice, she'll think if
expires at that time. Call it Ta. You can turn right around, and lop off
that user name, re-create the user name and self-sig with another expiration
time on it and hand it to Bob (call that Tb). This works today. It's the way
it works. We've even had discussions here for years about re-writing
self-sigs and what you should do, and how you should interpret them, and
what happens when you have things like a designated revoker.

Now, as Bodo has suggested, there's a potential ambiguity here. In short,
what does it mean if Alice signs your key with no expiration (or one that is
after Ta)? Bodo suggests that this is a flaw. I claim it is not. If Alice
had wished to time-limit her certification, she should have, and it's not
for us to tell her how to do it.

I further claim that while this may be somewhat counterintuitive, it is a
useful and desirable feature, for someone to have different expirations on a
key depending on situation. Lastly, I claim that if you want to kill a key,
there is a mechanism for that -- revocation.

Now it has also been claimed that if someone were to steal your private key,
they could re-write your self-signature, and even un-expire a key. Yeah.
They can do a lot worse, too. In the immortal words words of Julie Brown's
blonde, "So what?"

Discussing what someone can do with a purloined key loses track of the real
issue. When you design a security system, among the things you need to
consider are the security of the system, but also its safety and
reliability.

Security systems and reliability systems are not the same. In fact, they are
frequently at odds with each other. For example, if you build a building,
you might put bars on windows as part of security. But you might also make
it so they can be opened from the inside as a safety and reliability issue
-- as a way of battling fire. Note that improving the safety characteristics
of the building may be orthogonal to its security aspects, or they may be in
direct opposition to it.

Key expirations are a reliability feature. Revocations are a security
feature. If you think a key has been compromised, revoke it! Don't expire
it! We even have a nifty "reason for revocation" feature. Revoking a key
with a reason of key compromise is a drastic and perhaps ironically
irrevocable step. It means that nothing about the key can be relied upon.

However, the reliability aspects of PGP certificates are under-used, and
needed. There is, for example, a whole swarm of keys out there in some
unknown state. Some are in use, some aren't, some are in an unknown state. I
have at least of each, myself.

In the past, various people have discussed handing this issue by explicitly
or implicitly expiring them. Some people have asserted that one should never
create a key that doesn't have a reasonable expiration time on it.

The problem with that idea is many-fold. One is there's no good way to know
what a reasonable time is. One year? Two? More? Less? Worse, if you expire
your key, there's no good way to transfer your old certification information
to the new key. So all that work you went through to get your key signed by
cool people has to be redone.

Long ago, perhaps before we started OpenPGP, I was of the opinion that there
had to be an "I used to be" statement in the language. This is difficult to
do correctly. I never came up with a decent design for it. Part of what shut
me up on it was the realization that with V4 keys putting expiration into a
self-sig and not the key packet, you can use something I call "rolling
validity" where you keep extending the expiration of your key until you
decide not to, or revoke it. This solves all sorts of reliability issues in
OpenPGP. Yes, it does nothing for security. It's not supposed to, it's a
reliability feature, not a security one. It *does* however solve the problem
of someone creating a key, putting it on a public keyserver, and then losing
the password a day later.

It helps me manage which keys are active, by making it so that if I put too
short an expiry on my key, I don't lose that nifty Phil Zimmermann sig on
it. Laugh if you want, but it is that very issue (perhaps not with PRZ
himself, but the broader issue) that keeps people from putting time limits
on their keys. If you guess wrong, you hurt yourself.

Expiration is not revocation. Do not expect it to solve the problem of
revocation. Likewise, revocation is not expiration. Revocation is
irrevocable. Expiration can be undone. This is the design of the language of
the system. The present behavior is in my opinion the correct and desirable
one.

    Jon



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NNiOY18521 for ietf-openpgp-bks; Mon, 23 Sep 2002 16:44:24 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NNiMv18517 for <[e-mail]>; Mon, 23 Sep 2002 16:44:22 -0700 (PDT)
Received: by thetis.deor.org (Postfix, from userid 500) id 1FEBC45028; Mon, 23 Sep 2002 16:44:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 0819C48023; Mon, 23 Sep 2002 16:44:23 -0700 (PDT)
Date: Mon, 23 Sep 2002 16:44:23 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: Michael Young <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
In-Reply-To: <00d101c2634b$1b4e2b80$[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 23 Sep 2002, Michael Young wrote:

> Bodo originally suggested that clients abide by expiration times when
> creating new certifications.  That alone may not prevent a compromised
> key from being misused.  Yes, it would work for certifications prior
> to the compromise, and for new ones where the signer gets the key
> *directly* from the owner, but that still doesn't cover all cases.

Wasn't the original suggestion that keys expire at the earliest expiration
time, and later expiration dates be ignored? That would address the
problem.

Jon's request is also solved, too, by using signature expirations as long
as keys without self-signatures are treated as invalid keys.

> The problem is that fingerprints don't include the expiration time.

I agree this is a problem.

> This may be another fair argument for allowing rewriting.  If you
> really wanted irrevocable expiration times, you'd want to hash them
> into the fingerprint material, but it's way too late for that.

I think there are several things that are put into self-sig rather than
the key that shouldn't be. I also think that having the "signing only" and
"encrypt only" flags in the self sig, and not in the key, is also a
mistake. (I feel guilty about this, since I think I was the one who
suggested PGP 7 do things as the spec recommends. I now think that's
broken.) :(

Attributes of the key that intended to be permanent really should be so.

> > The question I see is this: are key expiration dates a "mandate" or a
> > "suggestion" to third parties by the key owner?
>
> More precisely, are expiration times rewriteable?
>
> I'm afraid that the answer has to be YES.  The specification has
> clearly said so for a while now, and at least one implementation
> (GnuPG) offers this capability.  If we change the rules now,
> anyone who has taken advantage of it (or set a short expiration
> time with the expectation that they can change it) will be
> seriously disappointed.

In that case, expiration dates don't seem to mean what everyone thinks
they mean.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NMvRe17550 for ietf-openpgp-bks; Mon, 23 Sep 2002 15:57:27 -0700 (PDT)
Received: from claude.kendall.corp.akamai.com (fw01.cmbrmaks.akamai.com [80.67.64.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NMvQv17546 for <[e-mail]>; Mon, 23 Sep 2002 15:57:26 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.corp.akamai.com (8.11.6/8.11.6) id g8NMvIe25702 for [e-mail]; Mon, 23 Sep 2002 18:57:18 -0400
Date: Mon, 23 Sep 2002 18:57:18 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Comments on ECC draft
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
User-Agent: Mutt/1.5.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 23, 2002 at 03:01:12PM -0700, Len Sassaman wrote:
> 
> I'd like to bring this up again before the next revision of the draft. How
> close are we to consensus on the ECC semantics?
> 
> OpenSSL now has ECC in it, and there is an ECC in TLS draft being proposed
> in the IETF. It is worth nailing this down, I think.

I'm not against ECC in OpenPGP, but given how close 2440bis is to last
call, perhaps the ECC specification could go in a companion RFC?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NM1NM16394 for ietf-openpgp-bks; Mon, 23 Sep 2002 15:01:23 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NM1Bv16387 for <[e-mail]>; Mon, 23 Sep 2002 15:01:12 -0700 (PDT)
Received: by thetis.deor.org (Postfix, from userid 500) id 1294545044; Mon, 23 Sep 2002 15:01:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id E679548023; Mon, 23 Sep 2002 15:01:12 -0700 (PDT)
Date: Mon, 23 Sep 2002 15:01:12 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Comments on ECC draft
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
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>

I'd like to bring this up again before the next revision of the draft. How
close are we to consensus on the ECC semantics?

OpenSSL now has ECC in it, and there is an ECC in TLS draft being proposed
in the IETF. It is worth nailing this down, I think.


On Wed, 5 Sep 2001 [e-mail] wrote:

>
> We have been looking at the ECC issue and have a few comments on the
> proposed draft by Dominikus Scherkl and Christoph Fausak.
>
> Broadly speaking it looks very good.  Obviously a lot of care and effort
> has gone into the work.  It seems to be timely to address the issue of
> elliptic curve support as there is interest in this technology from a
> number of areas.
>
> Our main concern is the number of variations proposed.  Experience with
> OpenPGP and other standards suggests that having a multitude of options
> does not lead to interoperability and security.  It is better to focus
> on a small number of options that will be used and tested.
>
> In looking at the various forms of elliptic curves, we can separate
> consideration of the coordinate field (the field from which the X and
> Y coordinates are taken) from the curve group.  Rather than describing
> each curve choice as a particular coordinate field and elliptic curve,
> we would rather specify a limited set of coordinate fields, and then to
> define curves using that set.
>
> Especially when implementing the binary (characteristic 2) fields,
> to get good performance it is necessary to optimize the code for the
> particular field size and basis.  Knowing the polynomial you can hard-code
> the necessary shifts, xors, and array offsets and do the arithmetic
> very fast.  Code which treats these values as variables will be much
> less efficient. As efficiency is much of the motivation for going to EC
> technology, we should try to preserve it.
>
> Therefore we recommend choosing a limited set of field sizes, and for each
> one choosing a single coordinate basis.  This will let all implementers
> optimize their code for the fields that are actually in use.
>
> As candidates for the specific fields to use, we recommend
> the selections from NIST [fips186-2], used as ECC groups in IKE
> [draft-ietf-ipsec-ike-ecc-groups-03]. These fields are being deployed
> and are in use in some environments. They provide for efficient
> implementations.
>
> ECC groups in IKE specifies two curves for each choice of coordinate
> field, a random curve which is expected to provide maximal security due
> to absence of any exploitable structure, and a Koblitz curve which has
> structure that allows for optimization and high speed.  We feel this is a
> good model to follow. It provides some flexibility while still providing a
> limited number of choices which will promote interoperability.  No special
> coding is needed to support the Koblitz curve for interoperation purposes;
> effort is only required if you want to get the potential speed advantages.
>
> The last point we would like to make is about the field representation
> format (section 4.4 in the draft), where again we would propose to reduce
> the number of options in order to improve interoperability. 16 options
> is too many.
>
> We suggest the initial draft use only prime fields, descriptor 3,
> and trinomial/pentanomial binary fields, descriptors 11 and 12. These
> three are enough to cover all the NIST curves.  They seem to provide
> the advantages which we seek from ECC without multiplying the options
> excessively.
>
> If the group does want to pursue additional field types, we would like
> to see some rationale for the use of prime extension field types 4-9. Our
> concern with the special primes 1-2 is that this area seems to be covered
> by patents.  And descriptors 14-16 are for normal bases, where we see
> two problems.  First, they cannot be efficiently implemented in software;
> and second, we do not think it is possible to convert from a normal basis
> into a polynomial basis representation without additional information
> regarding the specific normal basis chosen.  Hence using normal bases
> as an interchange format is not a good choice.  So we would like to see
> more discussion of that aspect if the group wishes to pursue it.
>
> (One organizational point: section 4.4 actually describes custom curves,
> and we would prefer to see the draft focus on predefined curves.  We have
> ideas on how to reorganize the draft to define specific coordinate
> fields and curves based on them, which we are getting into shape to
> present shortly.)
>
> Hal Finney
> Andrey Jivsov
> Network Associates, Inc.
>
> URLs:
> NIST curves: http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf
>
> ECC groups:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt
>

--Len.











Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NLpYk16126 for ietf-openpgp-bks; Mon, 23 Sep 2002 14:51:34 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NLpWv16122 for <[e-mail]>; Mon, 23 Sep 2002 14:51:32 -0700 (PDT)
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 RAA20554 for <[e-mail]>; Mon, 23 Sep 2002 17:38:08 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA17631 for <[e-mail]>; Mon, 23 Sep 2002 17:51:29 -0400 (EDT)
Message-ID: <00d101c2634b$1b4e2b80$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "OpenPGP" <[e-mail]>
References: <[e-mail]>
Subject: More on key expiration policy (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Date: Mon, 23 Sep 2002 17:49:34 -0400
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-----
Hash: SHA1

Subject: More on key expiration policy (Re:
draft-ietf-openpgp-rfc2440bis-06.txt)

From: "Len Sassaman" <[e-mail]>
> Actually, in Jon's proposal, the bad guy can. If we do things Bodo's way,
> he can't.

Bodo originally suggested that clients abide by expiration times when
creating new certifications.  That alone may not prevent a compromised
key from being misused.  Yes, it would work for certifications prior
to the compromise, and for new ones where the signer gets the key
*directly* from the owner, but that still doesn't cover all cases.

Consider this scenario...
    I steal Bob's key.
    I publish it, with an updated expiration time, to an
     out-of-the-way keyserver.
    Bob's new friend Alice gets his key from this keyserver.
    Alice verifies the fingerprint with Bob, and signs his key,
     in accordance with Bodo's rules.
    Alice sends her new signature to Bob, and/or publishes it
     at my keyserver, but I steal it enroute.
    I have a signature that will outlast Bob's intended expiration.

The problem is that fingerprints don't include the expiration time.

Now, Bob *could* insist on getting a copy of Alice's signature, and
check for a mismatched expiration time.  Together, Bob and Alice could
discover that I've compromised Bob.  But this would require more care
in the keysigning process than even some very cautious people apply.

Note that disallowing rewriting won't prevent this attack, as
that also depends on someone noticing a (different) mismatch.
(If I can completely keep people from seeing key updates,
then I can defeat revocations, too, but that's a much broader
attack.)

This may be another fair argument for allowing rewriting.  If you
really wanted irrevocable expiration times, you'd want to hash them
into the fingerprint material, but it's way too late for that.

> The question I see is this: are key expiration dates a "mandate" or a
> "suggestion" to third parties by the key owner?

More precisely, are expiration times rewriteable?

I'm afraid that the answer has to be YES.  The specification has
clearly said so for a while now, and at least one implementation
(GnuPG) offers this capability.  If we change the rules now,
anyone who has taken advantage of it (or set a short expiration
time with the expectation that they can change it) will be
seriously disappointed.

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

iQA/AwUBPY+MalMkvpTT8vCGEQLVmgCfVDZTWIpnOt2Gu1e31DPtMqaV8ekAn14H
E6TRRSoBFYuIfKzI7oiCwngd
=w8jJ
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NLXlC15794 for ietf-openpgp-bks; Mon, 23 Sep 2002 14:33:47 -0700 (PDT)
Received: from maild1.wiktel.com (maild1.wiktel.com [204.221.145.237]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NLXjv15788 for <[e-mail]>; Mon, 23 Sep 2002 14:33:45 -0700 (PDT)
Received: from virus3.wiktel.com (virus3.wiktel.com [204.221.145.233]) by maild1.wiktel.com (8.11.6/8.11.6) with SMTP id g8NLXeS00886 for <[e-mail]>; Mon, 23 Sep 2002 16:33:40 -0500
Received: from smtp1.wiktel.com ([204.221.145.236]) by virus3.wiktel.com (NAVGW 2.5.2.9) with SMTP id M2002092316254319777 ; Mon, 23 Sep 2002 16:25:43 -0500
Received: from NB1131 ([146.57.166.17]) (authenticated) by smtp1.wiktel.com (8.11.6/8.11.6) with ESMTP id g8NLXeu12772; Mon, 23 Sep 2002 16:33:40 -0500
From: "Richie Laager" <[e-mail]>
To: "'Bodo Moeller'" <[e-mail]>
Cc: "'OpenPGP'" <[e-mail]>
Subject: RE: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 23 Sep 2002 16:33:36 -0500
Organization: Wikstrom Telecom Internet
Message-ID: <000001c26348$e0494ad0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
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

> -----Original Message-----
> From: Bodo Moeller [mailto:[e-mail]] 
> Sent: Monday, September 23, 2002 1:57 PM
> To: Richie Laager
> Cc: 'OpenPGP'
> Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
> 
> 
> On Mon, Sep 23, 2002 at 01:49:14PM -0500, Richie Laager wrote:
> 
> >> Did you read my original message from the mailing list archives?
> >> There is a simple workaround for the protocol failure, which
> >> does not have the problems of your proposal: whenever someone
> >> certifies someone else's key, then if this key has an expiration
> >> time set, the certification signature should get an expiration
> >> time too such that the signature's validity period extends no
> >> longer into the future than the key's validity period.
> 
> > How does this help? If a "bad guy" gets the private key, he can
> > simply resign everyone's key.
> 
> If the bad guy gets Alice's private key that has expired, he can
> renew Alice's self-signature on the key, but he cannot renew Bob's
> certification for Alice's key, which will have expired too
> according to my proposal.  So no-one will believe it is still
> Alice's key.

Okay. I get it now. Alice's key expires in 5 years from creating, for
example. Two years later, Bob signs Alice's. Bob's PGP client sets an
expiration date of 3 years in the future on Bob's signature on
Alice's key. That way, Bob's signature expires at the same time as
Alice's key. If an attacker gets Alice's private key and extends the
expiration, the attacker would have to regain all of the signatures.

The only flaw I can see is that if Alice sets an expiration date of
Never, gets a signature from Bob, and then sets her expiration time
to 5 years, Bob's signature will likely NOT have an expiration date.
So, an attacker could then exploit Bob's signature. In essence, this
means that someone can't shrink their key validity length (length as
in time) and still have these benefits. My proposal would allow this.
However, my proposal doesn't allow someone to extend his or her key
validity length. And, my proposal requires changes on the client side
of the recipient, while your proposal requires client side changes
for the key signer. Therefore, I'll agree that your proposal is the
best. I just wanted to contribute my thoughts and clarify my
understanding of the issue.

Richard Laager

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPY+IsG31OrleHxvOEQL8pACgnEr+K80z6bJjZuVRN1vZA1IQjUoAoJOj
cyoxxYnf/9pDxqTuSG6xed3O
=aRsa
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NJqH912897 for ietf-openpgp-bks; Mon, 23 Sep 2002 12:52:17 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NJqGv12892 for <[e-mail]>; Mon, 23 Sep 2002 12:52:16 -0700 (PDT)
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 PAA28436 for <[e-mail]>; Mon, 23 Sep 2002 15:38:41 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA17083 for <[e-mail]>; Mon, 23 Sep 2002 15:52:01 -0400 (EDT)
Message-ID: <00b701c2633a$6c5a37a0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "OpenPGP" <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)
Date: Mon, 23 Sep 2002 15:50:06 -0400
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-----
Hash: SHA1

Subject: Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)

From: "Derek Atkins" <[e-mail]>
> A bad guy gets a copy of my private key..  If there is a key
> expiration then they cannot keep it alive indefinitely.  Or is key
> compromise not an attack you care about? ;)

No.

If you allow self-signatures to be rewritten with different
expiration times, then no, key COMPROMISE is NOT an attack
that the expiration time can ever mitigate.  Revocation
is the only option.

Now, it WOULD HAVE been reasonable to outright disallow multiple
self-signatures with different expiration times.  Then, the presence
of multiple expiration times could be taken as a clear sign of
compromise.  I would favor this approach, but others clearly do not,
and the spec has clearly allowed rewriting expiration times.

The usage pattern Jon Callas described does help deal with LOST keys,
though, preventing them from being used by legitimate clients.  In
the unlikely event that Jon loses his key, the flood of mail encrypted
to it will end at his most recently chosen expiration time :-).

This applies primarily to encryption.  I suppose it might also prevent
some fool from signing Jon's key (without asking him) after he has
lost it, but I feel no need to protect such fools.  So, I must admit
that I don't understand why Jon wants this to apply to main keys;
couldn't he update the expiration time in the binding signature for
his encryption keys?  If he has a "dead-man's switch" on all of his
subkeys, what more does he get from having the main key expire?

I would ask that the spec include some language to the sections on
expiration times to remind the reader that they can be rewritten, and
that clients should abide by them but not depend on them to limit
compromise.  (The right to rewrite appears elsewhere, but its
consequences may not immediately occur to someone looking at the
expiration time description.)

[As for the Bodo Moeller's original question, I mostly side with Jon.
Certifications are statements about the ownership of a key, not its
lifetime; it should be legal to make a certification that will outlast
the key's (CURRENT) expiration time.  That said, I wouldn't
strenuously object to mentioning that clients might WANT to consider
the key expiration time when making a new certification.]

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

iQA/AwUBPY9wQFMkvpTT8vCGEQL4qQCg3YUnyW9k13AUwS5sc7R0TXSbyjAAn36s
RX8JolyLTC9pvZHdpN18GeJj
=w7Hv
-----END PGP SIGNATURE-----




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NIvUO11401 for ietf-openpgp-bks; Mon, 23 Sep 2002 11:57:30 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NIvTv11397 for <[e-mail]>; Mon, 23 Sep 2002 11:57:29 -0700 (PDT)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.61]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 65A5B2C8E; Mon, 23 Sep 2002 20:57:30 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8NIvUJ02905; Mon, 23 Sep 2002 20:57:30 +0200 (MEST)
Date: Mon, 23 Sep 2002 20:57:29 +0200
From: Bodo Moeller <[e-mail]>
To: Richie Laager <[e-mail]>
Cc: "'OpenPGP'" <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <002301c26331$e9ffadb0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <002301c26331$e9ffadb0$[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 01:49:14PM -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>

On Mon, Sep 23, 2002 at 01:49:14PM -0500, Richie Laager wrote:

>> Did you read my original message from the mailing list archives?
>> There is a simple workaround for the protocol failure, which does
>> not have the problems of your proposal: whenever someone certifies
>> someone else's key, then if this key has an expiration time set,
>> the certification signature should get an expiration time too such
>> that the signature's validity period extends no longer into the
>> future than the key's validity period.

> How does this help? If a "bad guy" gets the private key, he can
> simply resign everyone's key.

If the bad guy gets Alice's private key that has expired, he can renew
Alice's self-signature on the key, but he cannot renew Bob's
certification for Alice's key, which will have expired too according
to my proposal.  So no-one will believe it is still Alice's key.

Well, nearly no-one -- I can't speak for Jon :-)


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NIr5311322 for ietf-openpgp-bks; Mon, 23 Sep 2002 11:53:05 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NIr4v11318 for <[e-mail]>; Mon, 23 Sep 2002 11:53:04 -0700 (PDT)
Received: by thetis.deor.org (Postfix, from userid 500) id 810B645025; Mon, 23 Sep 2002 11:53:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 6939148024; Mon, 23 Sep 2002 11:53:04 -0700 (PDT)
Date: Mon, 23 Sep 2002 11:53:04 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: Bodo Moeller <[e-mail]>, Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 23 Sep 2002, Derek Atkins wrote:

>
> Bodo Moeller <[e-mail]> writes:
>
> > Please point out an advantage of *key* expiration over
> > *self-signature* expiration in that scenario.
>
> A bad guy gets a copy of my private key..  If there is a key
> expiration then they cannot keep it alive indefinitely.  Or is key
> compromise not an attack you care about? ;)

Actually, in Jon's proposal, the bad guy can. If we do things Bodo's way,
he can't.

Bodo wants to make key expirations permanent and unalterable. This means
that even if a bad guy gets the private key, the key expiration cannot be
changed.

With Jon's way, key expirations are not a defense against key compromise,
because they can be extended indefinitely by the holder of the private
key.

The question I see is this: are key expiration dates a "mandate" or a
"suggestion" to third parties by the key owner?

In Mixmaster, we have key expiration dates that are not even tied to the
key by a signature -- they are just denoted in the key header field. The
intention here is to inform the user that the key will be deleted after
the expiration date, and in no way protects against the compromise of the
key. (Deleting the key does that -- the expiration date protects against
unreadable mail by the key holder).

One might argue that expirations in PGP are intended to be interpreted the
same way, and that the user should revoke the key if he is worried about
Bad Guys possessing it. I think this is how it must be interpreted if we
use Jon's system.


--Len.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NInEB11224 for ietf-openpgp-bks; Mon, 23 Sep 2002 11:49:14 -0700 (PDT)
Received: from maild1.wiktel.com (maild1.wiktel.com [204.221.145.237]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NInDv11220 for <[e-mail]>; Mon, 23 Sep 2002 11:49:13 -0700 (PDT)
Received: from virus3.wiktel.com (virus3.wiktel.com [204.221.145.233]) by maild1.wiktel.com (8.11.6/8.11.6) with SMTP id g8NInAS12515 for <[e-mail]>; Mon, 23 Sep 2002 13:49:10 -0500
Received: from smtp2.wiktel.com ([204.221.145.238]) by virus3.wiktel.com (NAVGW 2.5.2.9) with SMTP id M2002092313411319906 ; Mon, 23 Sep 2002 13:41:13 -0500
Received: from NB1131 ([146.57.166.32]) (authenticated) by smtp2.wiktel.com (8.11.6/8.11.6) with ESMTP id g8NIn3h29381; Mon, 23 Sep 2002 13:49:03 -0500
From: "Richie Laager" <[e-mail]>
To: "'Bodo Moeller'" <[e-mail]>
Cc: "'OpenPGP'" <[e-mail]>
Subject: RE: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 23 Sep 2002 13:49:14 -0500
Organization: Wikstrom Telecom Internet
Message-ID: <002301c26331$e9ffadb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
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

> -----Original Message-----
> From: Bodo Moeller [mailto:[e-mail]] 
> Sent: Monday, September 23, 2002 1:03 PM
> To: Richie Laager
> Cc: 'Derek Atkins'; 'Jon Callas'; 'OpenPGP'
> Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
> 
> 
> On Mon, Sep 23, 2002 at 12:48:16PM -0500, Richie Laager wrote:
> 
> >> Yes he can -- this is exactly the problem [1] that I want to
> >> solve with my suggested change to the specification.  The way
> >> Jon wants to use key expiration, the bad guy can keep the key
> >> alive
> >> indefinitely. I call this a protocol failure, he calls it a
> >> feature.
> 
> > I've been following this thread somewhat, and I have the
> > following suggestion: [...]
> 
> Did you read my original message from the mailing list archives?
> There is a simple workaround for the protocol failure, which does
> not have the problems of your proposal: whenever someone certifies
> someone else's key, then if this key has an expiration time set,
> the certification signature should get an expiration time too such
> that the signature's validity period extends no longer into the
> future than the key's validity period.

How does this help? If a "bad guy" gets the private key, he can
simply resign everyone's key.

Richie

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPY9iKm31OrleHxvOEQIFggCfYsFDQBW0Y76iV0j8ydzI/Ct2ZkEAoNCD
4+CEOfmM9vpCRaphkQDdQpFv
=lWxk
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NI2vh10129 for ietf-openpgp-bks; Mon, 23 Sep 2002 11:02:57 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NI2tv10125 for <[e-mail]>; Mon, 23 Sep 2002 11:02:55 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 87F672C8E; Mon, 23 Sep 2002 20:02:56 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8NI2st03502; Mon, 23 Sep 2002 20:02:54 +0200 (MEST)
Date: Mon, 23 Sep 2002 20:02:54 +0200
From: Bodo Moeller <[e-mail]>
To: Richie Laager <[e-mail]>
Cc: "'Derek Atkins'" <[e-mail]>, "'Jon Callas'" <[e-mail]>, "'OpenPGP'" <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <000e01c26329$65730180$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <000e01c26329$65730180$[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 12:48: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>

On Mon, Sep 23, 2002 at 12:48:16PM -0500, Richie Laager wrote:

>> Yes he can -- this is exactly the problem [1] that I want to solve
>> with my suggested change to the specification.  The way Jon wants
>> to use key expiration, the bad guy can keep the key alive
>> indefinitely. I call this a protocol failure, he calls it a
>> feature.

> I've been following this thread somewhat, and I have the following
> suggestion: [...]

Did you read my original message from the mailing list archives?
There is a simple workaround for the protocol failure, which does
not have the problems of your proposal: whenever someone certifies
someone else's key, then if this key has an expiration time set, the
certification signature should get an expiration time too such that
the signature's validity period extends no longer into the future than
the key's validity period.

(Obviously if Alice specifically asks Bob to certify her key for a
longer period, he can do so, but we need a default for the typical
case that there is no out-of-band information on this.)


Of course the one problem we cannot avoid is that the legitimate owner
of the key cannot keep the key alive indefinitely.  This is because
this "problem" is exactly the security feature that me and Florian
Weimer and Derek Atkins want to have: we don't want the bad guy to be
able to unexpire the key if he gets hold of the secret key.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NHmOq09781 for ietf-openpgp-bks; Mon, 23 Sep 2002 10:48:24 -0700 (PDT)
Received: from maild1.wiktel.com (maild1.wiktel.com [204.221.145.237]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NHmMv09776 for <[e-mail]>; Mon, 23 Sep 2002 10:48:23 -0700 (PDT)
Received: from virus3.wiktel.com (virus3.wiktel.com [204.221.145.233]) by maild1.wiktel.com (8.11.6/8.11.6) with SMTP id g8NHmKS04529 for <[e-mail]>; Mon, 23 Sep 2002 12:48:20 -0500
Received: from smtp2.wiktel.com ([204.221.145.238]) by virus3.wiktel.com (NAVGW 2.5.2.9) with SMTP id M2002092312402211534 ; Mon, 23 Sep 2002 12:40:22 -0500
Received: from NB1131 ([146.57.166.32]) (authenticated) by smtp2.wiktel.com (8.11.6/8.11.6) with ESMTP id g8NHmDh28285; Mon, 23 Sep 2002 12:48:13 -0500
From: "Richie Laager" <[e-mail]>
To: "'Bodo Moeller'" <[e-mail]>, "'Derek Atkins'" <[e-mail]>
Cc: "'Jon Callas'" <[e-mail]>, "'OpenPGP'" <[e-mail]>
Subject: RE: draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 23 Sep 2002 12:48:16 -0500
Organization: Wikstrom Telecom Internet
Message-ID: <000e01c26329$65730180$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Bodo Moeller
> Sent: Monday, September 23, 2002 9:01 AM
> To: Derek Atkins
> Cc: Jon Callas; OpenPGP
> Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
> 
> On Mon, Sep 23, 2002 at 09:55:19AM -0400, Derek Atkins wrote:

> Yes he can -- this is exactly the problem [1] that I want to solve
> with my suggested change to the specification.  The way Jon wants
> to use key expiration, the bad guy can keep the key alive
> indefinitely. I call this a protocol failure, he calls it a
> feature.

I've been following this thread somewhat, and I have the following
suggestion:

IIRC, key expirations are stored in the self-signature. So, a PGP
client could take all of the valid self-signatures, and compare
expiration dates. The oldest one would be honored.

This means that you cannot extend the key expiration. However, if you
don't want an attacker to be able to extend the key expiration if he
or she has the private key, this also means that the legitimate owner
of key cannot be allowed to extend the expiration date.

There is another large flaw with this plan. An attacker would only
need to revoke the self-signature, thus making it invalid. So, for
the meaning of this discussion, a "valid self-signature" would be one
that is correct in cryptographic terms, but revocations are ignored.

Deleting the other self-signatures would work, but since keyservers
only add to a key, synchronization with a keyserver could defeat this
attack method. However, if we ever implement the "no-modify" flag,
there is no reason the attacker (with possession of the private key)
couldn't send the key to the keyserver with the other signatures
deleted and the "no-modify" flag set. So, this may require that
keyservers maintain all self-signatures, even if the "no-modify" flag
is set.


So, to recap, if you ignore my implementation notes, the following
choice needs to be made:
1. Is extending a key expiration date by a key's owner a REQUIRED
action. If not, this is feasible. If so, I can't think of a way to do
it.

Richard Laager

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPY9T3231OrleHxvOEQII8gCfWwIaXS/eLAy7hnouhI5j2ZXXobIAmgLJ
DkNjYcTIJ/Yb4Gz6QdJ3v5DQ
=cJQr
-----END PGP SIGNATURE-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NE17604793 for ietf-openpgp-bks; Mon, 23 Sep 2002 07:01:07 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NE15v04789 for <[e-mail]>; Mon, 23 Sep 2002 07:01:05 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 100742C8E; Mon, 23 Sep 2002 16:01:06 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8NE12A03041; Mon, 23 Sep 2002 16:01:02 +0200 (MEST)
Date: Mon, 23 Sep 2002 16:01:02 +0200
From: Bodo Moeller <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Sep 23, 2002 at 09:55:19AM -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Sep 23, 2002 at 09:55:19AM -0400, Derek Atkins wrote:
> Bodo Moeller <[e-mail]> writes:

>> Please point out an advantage of *key* expiration over
>> *self-signature* expiration in that scenario.

> A bad guy gets a copy of my private key..  If there is a key
> expiration then they cannot keep it alive indefinitely.

Yes he can -- this is exactly the problem [1] that I want to solve
with my suggested change to the specification.  The way Jon wants to
use key expiration, the bad guy can keep the key alive indefinitely.
I call this a protocol failure, he calls it a feature.

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8NDunC04693 for ietf-openpgp-bks; Mon, 23 Sep 2002 06:56:49 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NDtlv04678 for <[e-mail]>; Mon, 23 Sep 2002 06:55:48 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21725; Mon, 23 Sep 2002 09:55:41 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA24118; Mon, 23 Sep 2002 09:55:30 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA29482; Mon, 23 Sep 2002 09:55:19 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA11121; Mon, 23 Sep 2002 09:55:19 -0400 (EDT)
To: Bodo Moeller <[e-mail]>
Cc: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
From: Derek Atkins <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
References: <[e-mail]> <[e-mail]>
Date: 23 Sep 2002 09:55:19 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 14
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>

Bodo Moeller <[e-mail]> writes:

> Please point out an advantage of *key* expiration over
> *self-signature* expiration in that scenario.

A bad guy gets a copy of my private key..  If there is a key
expiration then they cannot keep it alive indefinitely.  Or is key
compromise not an attack you care about? ;)

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8N6Nc024724 for ietf-openpgp-bks; Sun, 22 Sep 2002 23:23:38 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8N6Nav24717 for <[e-mail]>; Sun, 22 Sep 2002 23:23:36 -0700 (PDT)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.61]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 7B7492C8E; Mon, 23 Sep 2002 08:23:35 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8N6NYJ28478; Mon, 23 Sep 2002 08:23:34 +0200 (MEST)
Date: Mon, 23 Sep 2002 08:23:34 +0200
From: Bodo Moeller <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sun, Sep 22, 2002 at 11:16:16PM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sun, Sep 22, 2002 at 11:16:16PM -0700, Jon Callas wrote:
> "Bodo Moeller" <[e-mail]>:

>> In
>> your scenario, you specifically don't want the key to finally expire
>> if someone stops updating it, you just want to avoid having valid
>> self-signatures present.

> In my scenario, I specifically want the key expiration. Really I do. Now you
> may disagree with this, but it is what I want.

Please point out an advantage of *key* expiration over
*self-signature* expiration in that scenario.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8N6GFF24567 for ietf-openpgp-bks; Sun, 22 Sep 2002 23:16:15 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8N6GEv24563 for <[e-mail]>; Sun, 22 Sep 2002 23:16:14 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Sun, 22 Sep 2002 23:16:16 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sun, 22 Sep 2002 23:16:16 -0700
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[e-mail]>
To: Bodo Moeller <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
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>

On 9/22/02 12:48 AM, "Bodo Moeller" <[e-mail]>
wrote:

> In
> your scenario, you specifically don't want the key to finally expire
> if someone stops updating it, you just want to avoid having valid
> self-signatures present.

In my scenario, I specifically want the key expiration. Really I do. Now you
may disagree with this, but it is what I want.

    Jon




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8M7oXV09282 for ietf-openpgp-bks; Sun, 22 Sep 2002 00:50:33 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8M7oUv09274 for <[e-mail]>; Sun, 22 Sep 2002 00:50:31 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 31F402C8F; Sun, 22 Sep 2002 09:50:29 +0200 (MET DST)
Received: id <m17t1U3-000QdtC@epsilon>; Sun, 22 Sep 2002 09:48:51 +0200 (CEST) 
Message-Id: <m17t1U3-000QdtC@epsilon>
Date: Sun, 22 Sep 2002 09:48:51 +0200 (CEST)
To: [e-mail], Jon Callas <[e-mail]>
From: [e-mail] (Bodo Moeller)
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
In-Reply-To: <B9B24675.9692@jon>
References: <[e-mail]> <B9B24675.9692@jon>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]>:
> "Bodo Moeller" <[e-mail]>:

>> And assuming there *is* some point in doing self-signature updates
>> like this, whatever it may be, you should use signature expiration
>> time sub-packets, not key expiration sub-packets: it's just the
>> self-signatures that you want to expire, not the key.  So there is no
>> conflict with the proposed workaround for the key expiration protocol
>> failure.

> What I want is something of a dead-man's switch on my own key (and on other
> people's -- Werner is correct in noting that this requires client work,
> server work, and there are a lot of cool features you can load on this). If
> someone stops using their key, then it expires after some reasonable time,
> whether that reasonable time is measured in hours, days, or months.

So use *signature* expiration on the self-signatures for this.  In
your scenario, you specifically don't want the key to finally expire
if someone stops updating it, you just want to avoid having valid
self-signatures present.

> On the flip side of this, let's imagine that I certify Alice's key. When I
> certify it, I'm stating that I believe it belongs to her. If she has a
> dead-woman's switch on her key, it doesn't change my statement. If I wanted
> to limit the duration of my statement, that option was available to me. If
> Alice permits her key to expire, I still believe it's her key!

It might have become someone else's key too, that's the problem with
this: one reason for setting an expiry date is the expectation that
the key may no longer be secure after some time, be it because of
worries about keylengths or because you don't want to keep the
hard-disks of your old computers in a safe forever.

>                                                                It may be
> expired, but it's still her key. She could always un-expire it by putting a
> new self-sig on it. If I don't like all of this, I always have the option of
> revoking my signature, as well.

Compared with key expiry (and I mean final expiry that cannot simply
be undone by anyone who has gotten hold of the secret key), revocation
is somewhat of a kludge.  In some situations it is the best you can
do, but the problem is that the semantics is not monotonous.  This may
be fun for AI people, but security folks should be worried about the
ramifications of denial of service attacks (nothing guarantees that
the revocation reaches everyone who should know about it).


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8LMrOc02767 for ietf-openpgp-bks; Sat, 21 Sep 2002 15:53:24 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LMrNv02761 for <[e-mail]>; Sat, 21 Sep 2002 15:53:23 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Sat, 21 Sep 2002 15:53:24 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 21 Sep 2002 15:53:25 -0700
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[e-mail]>
To: Bodo Moeller <[e-mail]>
CC: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

On 9/21/02 2:54 PM, "Bodo Moeller" <[e-mail]>
wrote:

> And assuming there *is* some point in doing self-signature updates
> like this, whatever it may be, you should use signature expiration
> time sub-packets, not key expiration sub-packets: it's just the
> self-signatures that you want to expire, not the key.  So there is no
> conflict with the proposed workaround for the key expiration protocol
> failure.

What I want is something of a dead-man's switch on my own key (and on other
people's -- Werner is correct in noting that this requires client work,
server work, and there are a lot of cool features you can load on this). If
someone stops using their key, then it expires after some reasonable time,
whether that reasonable time is measured in hours, days, or months.

On the flip side of this, let's imagine that I certify Alice's key. When I
certify it, I'm stating that I believe it belongs to her. If she has a
dead-woman's switch on her key, it doesn't change my statement. If I wanted
to limit the duration of my statement, that option was available to me. If
Alice permits her key to expire, I still believe it's her key! It may be
expired, but it's still her key. She could always un-expire it by putting a
new self-sig on it. If I don't like all of this, I always have the option of
revoking my signature, as well.

    Jon



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8LLsvr03295 for ietf-openpgp-bks; Sat, 21 Sep 2002 14:54:57 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LLstw03291 for <[e-mail]>; Sat, 21 Sep 2002 14:54:56 -0700 (PDT)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.61]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 285202C8F; Sat, 21 Sep 2002 23:54:52 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8LLsp527434; Sat, 21 Sep 2002 23:54:51 +0200 (MEST)
Date: Sat, 21 Sep 2002 23:54:51 +0200
From: Bodo Moeller <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <m17siAV-000QdtC@epsilon> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Sep 21, 2002 at 10:20:53PM +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Sep 21, 2002 at 10:20:53PM +0200, Bodo Moeller wrote:
> On Sat, Sep 21, 2002 at 11:20:49AM -0700, Jon Callas wrote:
>> "Bodo Moeller" <[e-mail]>:

>>> I am talking about main keys, not subkeys.  Simply don't set an
>>> expiration time for the signing key if you want to be able to continue
>>> to use it indefinitely.

>> So am I. I'm talking about main keys.
>> 
>> I have a vision where my program might (for example) re-create my
>> self-signature every day with a 48-hour expiration, and upload it to the
>> server.

> But why would you want to do this?!  This key "expiration" does not
> provide any security.  You can just as well submit a key without an
> expiration date; instead of stopping to send updated self-signatures,
> you just stop to use the key.

And assuming there *is* some point in doing self-signature updates
like this, whatever it may be, you should use signature expiration
time sub-packets, not key expiration sub-packets: it's just the
self-signatures that you want to expire, not the key.  So there is no
conflict with the proposed workaround for the key expiration protocol
failure.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8LKu2R07151 for ietf-openpgp-bks; Sat, 21 Sep 2002 13:56:02 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LKu0o07147 for <[e-mail]>; Sat, 21 Sep 2002 13:56:01 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17ssa8-0001kg-00; Sun, 22 Sep 2002 00:18:32 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17srEd-0002VM-00; Sat, 21 Sep 2002 22:52:15 +0200
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
References: <[e-mail]>
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Sat, 21 Sep 2002 22:52:14 +0200
In-Reply-To: <[e-mail]> (Jon Callas's message of "Sat, 21 Sep 2002 11:20:49 -0700")
Message-ID: <[e-mail]>
Lines: 14
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, 21 Sep 2002 11:20:49 -0700, Jon Callas said:

> I have a vision where my program might (for example) re-create my
> self-signature every day with a 48-hour expiration, and upload it to the
> server.

Aihhh, this needs some work on the keyserver side of the story and I
can think of neat features to be implemented on the client side. ;-)


Shalom-Salam,

   Werner




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8LKKsB06083 for ietf-openpgp-bks; Sat, 21 Sep 2002 13:20:54 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LKKqo06079 for <[e-mail]>; Sat, 21 Sep 2002 13:20:53 -0700 (PDT)
Received: from cdc-ws1.cdc.informatik.tu-darmstadt.de (cdc-ws1 [130.83.23.61]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 879C82C90; Sat, 21 Sep 2002 22:20:54 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws1.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8LKKs927176; Sat, 21 Sep 2002 22:20:54 +0200 (MEST)
Date: Sat, 21 Sep 2002 22:20:53 +0200
From: Bodo Moeller <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
References: <m17siAV-000QdtC@epsilon> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Sep 21, 2002 at 11:20:49AM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Sep 21, 2002 at 11:20:49AM -0700, Jon Callas wrote:
> "Bodo Moeller" <[e-mail]>:

>> I am talking about main keys, not subkeys.  Simply don't set an
>> expiration time for the signing key if you want to be able to continue
>> to use it indefinitely.

> So am I. I'm talking about main keys.
> 
> I have a vision where my program might (for example) re-create my
> self-signature every day with a 48-hour expiration, and upload it to the
> server.

But why would you want to do this?!  This key "expiration" does not
provide any security.  You can just as well submit a key without an
expiration date; instead of stopping to send updated self-signatures,
you just stop to use the key.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8LIKqB00785 for ietf-openpgp-bks; Sat, 21 Sep 2002 11:20:52 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LIKpo00777 for <[e-mail]>; Sat, 21 Sep 2002 11:20:51 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Sat, 21 Sep 2002 11:20:49 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 21 Sep 2002 11:20:49 -0700
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <m17siAV-000QdtC@epsilon>
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>

On 9/21/02 4:11 AM, "Bodo Moeller" <[e-mail]>
wrote:

> Jon Callas <[e-mail]>:
>> "Bodo Moeller" <[e-mail]>:
> 
>>> Here's the yearly reminder on the OpenPGP key expiration protocol failure.
>>> 
>>> http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
>>> http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
>>> http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
> 
>> My opinion (still) is that it isn't a bug, it's a feature. I want someday to
>> make keys that have short-lived self-signatures on them that are regularly
>> renewed, [...]
> 
> You are talking about subkeys (encryption subkeys, presumably -- in
> the case of signature keys, you can simply stop using them without
> having announced so in advance).  If you want to regularly renew your
> subkeys, then set appropriate expiration times for these subkeys.
> 
> I am talking about main keys, not subkeys.  Simply don't set an
> expiration time for the signing key if you want to be able to continue
> to use it indefinitely.
> 

So am I. I'm talking about main keys.

I have a vision where my program might (for example) re-create my
self-signature every day with a 48-hour expiration, and upload it to the
server.

OpenPGP has a policy that in the base specification, we permit a variety of
trust models and do not require one; we provide a language that is robust
enough to support all these trust models.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8LBTg216862 for ietf-openpgp-bks; Sat, 21 Sep 2002 04:29:42 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LBTfk16854 for <[e-mail]>; Sat, 21 Sep 2002 04:29:41 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 7BBEF2C8F; Sat, 21 Sep 2002 13:29:40 +0200 (MET DST)
Received: id <m17siRI-000QdtC@epsilon>; Sat, 21 Sep 2002 13:28:44 +0200 (CEST) 
Message-Id: <m17siRI-000QdtC@epsilon>
Date: Sat, 21 Sep 2002 13:28:44 +0200 (CEST)
To: [e-mail]
Cc: Werner Koch <[e-mail]>, Jon Callas <[e-mail]>
From: [e-mail] (Bodo Moeller)
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
In-Reply-To: <[e-mail]>
References: <B9B15B23.962C@jon> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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 <[e-mail]>:
> Jon Callas:

>> My opinion (still) is that it isn't a bug, it's a feature.

> I fully agree.  [...]

With me as well apparently, because this:

> By default GnuPG uses the expiration date of the self-signature as the
> one for a key signature. This is on Florian Weimer's request and afaik
> is sufficient for him and his use of the PGP PKI.

is exactly what I was asking for -- except that I want this to be
recommended in the specification [1][2] so that Florian won't have to
contact all the implementors individually [3].

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
[2] http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
[3] http://lists.gnupg.org/pipermail/gnupg-devel/2001-July/006196.html


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: by above.proper.com (8.11.6/8.11.3) id g8LBJbj15878 for ietf-openpgp-bks; Sat, 21 Sep 2002 04:19:37 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LBJZk15872 for <[e-mail]>; Sat, 21 Sep 2002 04:19:35 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 0A0322C8F; Sat, 21 Sep 2002 13:19:30 +0200 (MET DST)
Received: id <m17siAV-000QdtC@epsilon>; Sat, 21 Sep 2002 13:11:23 +0200 (CEST) 
Message-Id: <m17siAV-000QdtC@epsilon>
Date: Sat, 21 Sep 2002 13:11:23 +0200 (CEST)
To: [e-mail]
From: [e-mail] (Bodo Moeller)
Cc: Jon Callas <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
In-Reply-To: <B9B15B23.962C@jon>
References: <[e-mail]> <B9B15B23.962C@jon>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]>:
> "Bodo Moeller" <[e-mail]>:

>> Here's the yearly reminder on the OpenPGP key expiration protocol failure.
>> 
>> http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
>> http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
>> http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html

> My opinion (still) is that it isn't a bug, it's a feature. I want someday to
> make keys that have short-lived self-signatures on them that are regularly
> renewed, [...]

You are talking about subkeys (encryption subkeys, presumably -- in
the case of signature keys, you can simply stop using them without
having announced so in advance).  If you want to regularly renew your
subkeys, then set appropriate expiration times for these subkeys.

I am talking about main keys, not subkeys.  Simply don't set an
expiration time for the signing key if you want to be able to continue
to use it indefinitely.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8LAhKc13671 for ietf-openpgp-bks; Sat, 21 Sep 2002 03:43:20 -0700 (PDT)
Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8LAhJk13665 for <[e-mail]>; Sat, 21 Sep 2002 03:43:19 -0700 (PDT)
Received: (qmail 18513 invoked by uid 417); 21 Sep 2002 10:43:09 -0000
Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 21 Sep 2002 10:43:09 -0000
Received: from softhome.net ([209.6.138.140]) (AUTH: PLAIN [e-mail]) by softhome.net with esmtp; Sat, 21 Sep 2002 04:43:07 -0600
Message-ID: <[e-mail]>
Date: Sat, 21 Sep 2002 06:41:57 -0400
From: John Kane <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-OpenPGP <[e-mail]>
Subject: Re: Fixing the MDC language
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>

  jc> contains a SHA-1 hash of plaintext data
  jc> The plaintext of the data to be encrypted

An ambiguity quibble.  This is meant to refer to the octets of the
compressed/encoded packet as seen by the CFB envelope, as opposed
to the uncompressed/decoded data as seen by the end users?
I see the hint buried in 5.14, but pleeease make it more explicit in 5.13...





Received: by above.proper.com (8.11.6/8.11.3) id g8LA2E808794 for ietf-openpgp-bks; Sat, 21 Sep 2002 03:02:14 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8LA28k08772 for <[e-mail]>; Sat, 21 Sep 2002 03:02:09 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17siN8-0004Gx-00; Sat, 21 Sep 2002 13:24:26 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17sh2o-0002Ge-00; Sat, 21 Sep 2002 11:59:22 +0200
To: Jon Callas <[e-mail]>
Cc: Bodo Moeller <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
References: <[e-mail]>
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Sat, 21 Sep 2002 11:59:22 +0200
In-Reply-To: <[e-mail]> (Jon Callas's message of "Fri, 20 Sep 2002 23:09:23 -0700")
Message-ID: <[e-mail]>
Lines: 25
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 20 Sep 2002 23:09:23 -0700, Jon Callas said:

> My opinion (still) is that it isn't a bug, it's a feature. I want someday to
> make keys that have short-lived self-signatures on them that are regularly

I fully agree.  Furthermore, due to the possibility to set an
expiration date on a key signatature, a "CA" gains the same effect as
with an expiration date on the key.  It is about what a trusted
authority sees as a sound expiration date.  This may either be a key
signator by using the signature expiration time or the key owner by
setting the expiration date on his key signatures (self-signature).

PGP has the tradtion to to let the user decide and not some other
entity.  With the OpenPGP model the user is even free to ask a CA to
set an expiration date on their key signature.  

By default GnuPG uses the expiration date of the self-signature as the
one for a key signature.  This is on Florian Weimer's request and afaik
is sufficient for him and his use of the PGP PKI.


Salam-Shalom,

   Werner




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8L6H0s08844 for ietf-openpgp-bks; Fri, 20 Sep 2002 23:17:00 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8L6Gdk08715 for <[e-mail]>; Fri, 20 Sep 2002 23:16:39 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Fri, 20 Sep 2002 23:16:34 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 20 Sep 2002 23:09:23 -0700
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[e-mail]>
To: Bodo Moeller <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

On 9/20/02 6:40 AM, "Bodo Moeller" <[e-mail]>
wrote:

> 
> Here's the yearly reminder on the OpenPGP key expiration protocol failure.
> 
> http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
> http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
> http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
> 

My opinion (still) is that it isn't a bug, it's a feature. I want someday to
make keys that have short-lived self-signatures on them that are regularly
renewed, and don't want to require the entire PKI to regenerate itself every
week, or day, or month. I think it's horribly limiting to require all the
dates to match up, and ruins a lot of interesting possibilities.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g8KDefS10812 for ietf-openpgp-bks; Fri, 20 Sep 2002 06:40:41 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KDeck10802 for <[e-mail]>; Fri, 20 Sep 2002 06:40:39 -0700 (PDT)
Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id A07292C97 for <[e-mail]>; Fri, 20 Sep 2002 15:40:38 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g8KDea401683 for [e-mail]; Fri, 20 Sep 2002 15:40:36 +0200 (MEST)
Date: Fri, 20 Sep 2002 15:40:36 +0200
From: Bodo Moeller <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
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>

Here's the yearly reminder on the OpenPGP key expiration protocol failure.

http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8K6tfS01782 for ietf-openpgp-bks; Thu, 19 Sep 2002 23:55:41 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8K6tek01776 for <[e-mail]>; Thu, 19 Sep 2002 23:55:40 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g8K6t9k17770; Thu, 19 Sep 2002 23:55:09 -0700
Date: Thu, 19 Sep 2002 23:55:09 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Fixing the MDC language
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

A couple of comments:

First, there is another typo I forgot to mention:

> includes all of the plaintext, and then also includes two octets of values
> 0xD0, 0x14.  These represent the encoding of a Modification Detection Code

The D0 was from an older version of the draft when we were going to
use tag 16 for the MDC packet.  In fact we chose tag 19, so 0xD0 should
be 0xD3.

The other point:

> The plaintext of the data to be encrypted is passed through the SHA-1 hash
> function, and the result of the hash is appended to the plaintext in a
> Modification Detection Code packet.  The input to the hash function includes
> the prefix data described above which acts as a weakly keyed hash;

This last sentence is not quite correct, the prefix data per se does not
act as a weakly keyed hash.  It acts as the key to a sort of keyed hash.
But it's not really a normal keyed hash, because the key is usually kept
a lot more secret than our pseudo-IV.

In any case I don't really think we ought to mention this keyed-hash
stuff.  It's not necessary to an implementor, and as a shorthand for
some kind of security analysis it is too brief to be meaningful.  I'd
suggest removing the "which acts as..." clause entirely.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g8K6UEs28009 for ietf-openpgp-bks; Thu, 19 Sep 2002 23:30:14 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8K6UDk28000 for <[e-mail]>; Thu, 19 Sep 2002 23:30:13 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Thu, 19 Sep 2002 23:30:09 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 19 Sep 2002 23:30:09 -0700
Subject: Fixing the MDC language
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
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>

Here's a proposed fix to the oops that Hal found:

-----

The plaintext of the data to be encrypted is passed through the SHA-1 hash
function, and the result of the hash is appended to the plaintext in a
Modification Detection Code packet.  The input to the hash function includes
the prefix data described above which acts as a weakly keyed hash; it
includes all of the plaintext, and then also includes two octets of values
0xD0, 0x14.  These represent the encoding of a Modification Detection Code
packet tag and length field of 20 octets.

The resulting hash value is stored in a Modification Detection Code packet
which MUST use the two octet encoding just given to represent its tag and
length field.  The body of the MDC packet is the 20 octet output of the
SHA-1 hash.

The Modification Detection Code packet is appended to the plaintext and
encrypted along with the plaintext using the same CFB context.

During decryption, the plaintext data should be hashed with SHA-1, including
the prefix data as well as the packet tag and length field of the
Modification Detection Code packet.  The body of the MDC packet, upon
decryption, is compared with the result of the SHA-1 hash.  Any difference
in hash values is an indication that the message has been modified and
SHOULD be reported to the user. Likewise, the absence of an MDC packet, or
an MDC packet in any position other than the end of the plaintext, also
represent message modifications and SHOULD also be reported.

-----

I can quickly (like in 30 minutes) pop off another draft if this is
acceptable. Comments ASAP.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8JJMEc22758 for ietf-openpgp-bks; Thu, 19 Sep 2002 12:22:14 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8JJMCk22754 for <[e-mail]>; Thu, 19 Sep 2002 12:22:12 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Thu, 19 Sep 2002 12:15:03 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8JJLXE3022022; Thu, 19 Sep 2002 12:21:33 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6F62>; Thu, 19 Sep 2002 12:21:23 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Jon Callas'" <[e-mail]>, Michael Young <[e-mail]>, Trevor Perrin <[e-mail]>, "'David Wagner'" <[e-mail]>, OpenPGP <[e-mail]>, [e-mail]
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Thu, 19 Sep 2002 12:21:21 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

To keep picking at this, the "chosen-ciphertext" attack of Jallad, Katz, and
Schneier could be used in conjunction with a downgrade attack to discover
the prefix block.  The attacker takes the ciphertext of the prefix block
from an integrity-protected message, then incorporates it into a
non-integrity-protected message, preceding it with a block of zeros.  The
receiver naively responds with "what the heck is this", and the decrypted
prefix block.

Now, the attacker can go ahead with his attack of "shuffling" the ciphertext
blocks around, and then recomputing the hash until he finds a collision on
the first bytes of the existing hash, then bit-flipping the last bytes to
match.  There's a lot of caveats to this attack, so it's probably not
anything to seriously worry about:
 - only works if attacker knows all plaintext
 - only works if data is uncompressed
 - only works if data is encrypted with passphrase
   - if public-key signed, it fails
   - if public-key encrypted, then forgeries are trivial anyways
 - only works if preceded by JKS attack
 - only works if the attacker has resources to find collisions on the first
X bytes of the hash, where X could be as low as 4 with probability 1/16, but
would average 11.
 - only allows attacker to move ciphertext blocks around, not to XOR new
strings into the ciphertext (because doing so would introduce a ciphertext
block which the attacker hasn't seen before and thus can't recover the next
CFB keystream block for, so the change would be unpredictable)
 - requires the attacker to make several other changes to the plaintext,
besides his targeted modification, so that he can search for collisions

The "cut-out" attack is where the attacker embeds a PGP literal data packet
+ MDC packet in a larger plaintext, and then cuts out the corresponding
ciphertext after encryption and uses that.  This attack is tripped up by the
prefix block, and by the check bytes with probability 2^-16.  The JKS
attack, as mentioned, could recover the prefix block's plaintext for one of
these illicit ciphertexts.  However then a shuffling attack would be needed
to make the hash match.  And the check bytes are still a problem.  But an
attacker could embed many illicit plaintexts in a single larger plaintext,
and check for many prefix/check bytes matches in a single JKS attack, so the
probability of 2^-16 could be increased.  For example, if an attacker embeds
1000 illicit plaintexts in a larger plaintext, and then cuts out and submits
1000 prefix block / check block pairs in a single JKS attack for matching,
he increases the odds of finding a match, and thus a successful forgery, to
2^-6.

Both the "shuffling" and "cut-out" attacks would be completely foiled by
using a MAC instead of an MDC, since the session key cannot be recovered in
a JKS attack like the prefix block can, and without it an attacker would not
be able to modify things and then recompute the MAC, as he can do with an
MDC.  Also, there may be other ways of stealing the prefix block;
implementors may not realize that integrity depends on its secrecy, so may
be careless with it.

The JKS attack on integrity-protected data would be foiled by using a Key
Derivation Function to derive a new encryption key from the session key, so
that integrity-protected ciphertext could not be "downgraded" and used in a
non-integrity-protected context with the same session key.  John Kane
suggested (off-list) something like:

Version = Sym. Encrypted Integrity Protected Data Packet Version Number
EncKey  = KDF(SessionKey, Version, 0)
AuthKey = KDF(SessionKey, Version, 1)

The version would be revved to 2, and would be incorporated into the KDF to
prevent rollbacks.  For version 2 and higher, a new type of MDC Packet would
be defined that contains an HMAC-SHA1 instead of SHA1.

Trevor


-----Original Message-----
From: Jon Callas [mailto:[e-mail]]
Sent: Wednesday, September 18, 2002 8:26 PM
To: Michael Young; Trevor Perrin; 'David Wagner'; OpenPGP; [e-mail]
Subject: Re: [Cfrg] OpenPGP security analysis


On 9/17/02 8:20 AM, "Michael Young" <[e-mail]> wrote:

> The MDC in OpenPGP is really no more than a checksum, intended to
> detect accidental damage.  (In fact, during the discussion, I believe
> that some folks suggested that it be just a checksum.)  Before the
> MDC, there was little ability to detect *any* sort of accident -- not
> just truncation, but fairly arbitrary internal damage as well.  (When
> the payload is a compressed packet, the decompression might discover
> damage, but then again, it might not.)  There was discussion of a
> stronger MAC, but I think this was dropped given that OpenPGP has a
> strong signature mechanism.

Yes, and no. The MDC is supposed to detect intentional damage as well as
accidental damage. While a checksum was suggested, it was rejected because
it's pretty obvious that would not have the desired characteristics.

It *is* true that the MDC is not and was never intended to be a MAC. The
goal of the MDC is to reliably detect modification of the data in the
envelope, whether by insertion, deletion, or changing it. If an attacker can
do that, then then MDC has failed and we need a new mechanism.

Also note that the MDC's hash is weakly keyed, as there is an "IV" for it
inside the envelope.

If we need to, there are ways we could turn this into a MAC, including a
function over the key, or key+hashkey, or even including an extra MAC key
inside the ESK.

I think there are a number of separate questions around this that include:

(1) Is there a security problem in the MDC as in bis-06?

(2) Should we change it regardless?

Each of those is important. If the answer to (1) is yes, then we need
something. (2) needs to balance existing deployment and so on.

    Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8J8m8P14161 for ietf-openpgp-bks; Thu, 19 Sep 2002 01:48:08 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8J8m3k14151 for <[e-mail]>; Thu, 19 Sep 2002 01:48:03 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 19 Sep 2002 01:47:56 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 19 Sep 2002 01:48:10 -0700
Subject: Re: [Cfrg] OpenPGP security analysis
From: Jon Callas <[e-mail]>
To: Hal Finney <[e-mail]>, <[e-mail]>, <[e-mail]>, OpenPGP <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

On 9/18/02 2:40 PM, "Hal Finney" <[e-mail]> wrote:

> 
> Here's something important.  The latest version of the OpenPGP-bis draft
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt
> has got an error with regard to the MDC feature.  In section 5.13 it
> says,

Well, isn't that seriously irritating?

I'll rev it.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8J3WDm05214 for ietf-openpgp-bks; Wed, 18 Sep 2002 20:32:13 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8J3WCk05210 for <[e-mail]>; Wed, 18 Sep 2002 20:32:12 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 18 Sep 2002 20:32:08 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 18 Sep 2002 20:25:59 -0700
Subject: Re: [Cfrg] OpenPGP security analysis
From: Jon Callas <[e-mail]>
To: Michael Young <[e-mail]>, Trevor Perrin <[e-mail]>, "'David Wagner'" <[e-mail]>, OpenPGP <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <003801c25e5d$b5e44280$[e-mail]>
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>

On 9/17/02 8:20 AM, "Michael Young" <[e-mail]> wrote:

> The MDC in OpenPGP is really no more than a checksum, intended to
> detect accidental damage.  (In fact, during the discussion, I believe
> that some folks suggested that it be just a checksum.)  Before the
> MDC, there was little ability to detect *any* sort of accident -- not
> just truncation, but fairly arbitrary internal damage as well.  (When
> the payload is a compressed packet, the decompression might discover
> damage, but then again, it might not.)  There was discussion of a
> stronger MAC, but I think this was dropped given that OpenPGP has a
> strong signature mechanism.

Yes, and no. The MDC is supposed to detect intentional damage as well as
accidental damage. While a checksum was suggested, it was rejected because
it's pretty obvious that would not have the desired characteristics.

It *is* true that the MDC is not and was never intended to be a MAC. The
goal of the MDC is to reliably detect modification of the data in the
envelope, whether by insertion, deletion, or changing it. If an attacker can
do that, then then MDC has failed and we need a new mechanism.

Also note that the MDC's hash is weakly keyed, as there is an "IV" for it
inside the envelope.

If we need to, there are ways we could turn this into a MAC, including a
function over the key, or key+hashkey, or even including an extra MAC key
inside the ESK.

I think there are a number of separate questions around this that include:

(1) Is there a security problem in the MDC as in bis-06?

(2) Should we change it regardless?

Each of those is important. If the answer to (1) is yes, then we need
something. (2) needs to balance existing deployment and so on.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8INISx20099 for ietf-openpgp-bks; Wed, 18 Sep 2002 16:18:28 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8INIQk20094 for <[e-mail]>; Wed, 18 Sep 2002 16:18:26 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Wed, 18 Sep 2002 16:11:47 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8INIHE3021586; Wed, 18 Sep 2002 16:18:17 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6195>; Wed, 18 Sep 2002 16:18:10 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Hal Finney'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Trevor Perrin <[e-mail]>
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Wed, 18 Sep 2002 16:18:09 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

This stops both attacks I mentioned, as far as I can tell.  It stops the
first attack (where the attacker embeds an illicit string in the plaintext,
and then later cuts out and uses the corresponding ciphertext), because the
attacker won't be able to predict or control the prefix bytes, so he can't
produce a valid MDC on his embedded string.

The one thing I still see to worry about, is the rollback attack where an
attacker embeds an illicit string in an integrity-protected packet, then
later cuts out and uses the ciphertext as a *non*-integrity-protected
packet.  This requires the attacker also cut out the previous blocksize+2
ciphertext bytes (cause of PGP's CFB resynchronization).  This attack will
only succeed in the 1/65,536 probability the check bytes happen to match.
An attacker could embed lots of illicit strings in a single file, to
increase the odds of this happening, but would have no way of knowing if he
succeeded short of submitting the illicit ciphertexts to the receiver and
observing if they decrypt successfully.

Using a key derivation function on the session key to derive the encryption
key in the integrity-protected case would prevent this attack.  Also
switching from an MDC to a MAC just to be safe still seems a good idea, if
it can be done in a backwards-compatible and rollback-proof way.  I heard a
good suggestion for this offlist, I assume the authors will present it
sometime.  

Trevor


-----Original Message-----
From: Hal Finney [mailto:[e-mail]]
Sent: Wednesday, September 18, 2002 2:41 PM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: [Cfrg] OpenPGP security analysis


Here's something important.  The latest version of the OpenPGP-bis draft
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt
has got an error with regard to the MDC feature.  In section 5.13 it
says,

   The plaintext of the data to be encrypted is passed through the
   SHA-1 hash function, and the result of the hash is appended to the
   plaintext in a Modification Detection Code packet.  Specifically,
   the input to the hash function does not include the prefix data
   described above;

This is wrong; the input to the hash function DOES include the prefix
data.  This is how it is implemented in the commercial PGP version 7.X
(which only reads but does not yet create this packet), and in GnuPG,
which can both create and read it.  I checked interoperability on this
feature with Werner Koch a long time ago and we are both doing it the
same way.  I also just downloaded GPG and looked at the code to make
sure, and it does hash the prefix.

The error is repeated a couple of paragraphs later,

   During decryption, the plaintext data should be hashed with SHA-1,
   not including the prefix data 

The reason this is important is that it can help to prevent these attacks
which involve controlled modification to the plaintext.  Since the hash
includes the block of prefix data, which is hidden to the attacker,
he cannot predict what the hash is before his modifications, even if he
knows the entire message; and nor can he predict what the hash should be
after modification.  So he can't do as Trevor Perrin describes below,
rearranging blocks, or XORing data into an existing message, and then
compensating for his changes by XORing an appropriate value into the hash.

Guessing the prefix block will only have success 2^128 for the AES and
Twofish ciphers where we mostly use the MDC, or 2^64 for the older ciphers
if it is used there.  In either case this is a very low chance of success.

We should correct the draft to accurately reflect the behavior of the
implementations in the field.  Hashing the prefix data improves the strength
of the MDC construction so it is important for security.

Hal Finney
NAI.com

> From: Trevor Perrin <[e-mail]>
> Subject:  RE: [Cfrg] OpenPGP security analysis
> Date:  Wed, 18 Sep 2002 13:31:27 -0700
> List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
> List-ID: <ietf-openpgp.imc.org>
>
>
>
> [I apologize for holding a monologue here, just wanted to close this up]
>
> >From: Trevor Perrin 
> >
> >There may other ways of making predictable modifications of 
> >the plaintext, which can also take advantage of the fact that 
> >you only need to find a collision on 4 bytes of the hash, then 
> >can bit-flip the rest.
>
> For example, copying-and-pasting a sequence of ciphertext blocks, or
> deleting a sequence, will cause a scrambled block just after each splice
> point, but these scrambled blocks will be predictable by an attacker who
> knows the plaintext, because CFB mode lets an attacker with known
plaintext
> reconstruct the keystream block that follows each ciphertext block.  Thus
> the situation is similar to Bellovin's cut-and-paste attacks against
> non-integrity-protected CBC, with the caveats:
>
>  - the attack requires the attacker know the entire plaintext string, so
he
> can compute the hash value of the modified plaintext that corresponds to
his
> ciphertext modifications
>
>  - the attack depends on the attacker trying out a large number of
potential
> modifications, until he finds one that collides with the first X bytes of
> the current hash, where X is the number of hash bytes that reside in all
but
> the last encryption block, (with a 16-byte block size and 20-byte hash,
> X=4,5,6,..,19 with probability 1/16th each)
>
> So in practice the attacker would choose a targeted modification he wanted
> to make, then choose some imperceptible modifications that he can make in
an
> out-of-the-way corner of the document, and search through their
permutations
> until he finds a collision.
>
> Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ILfSF17004 for ietf-openpgp-bks; Wed, 18 Sep 2002 14:41:28 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ILfQk17000 for <[e-mail]>; Wed, 18 Sep 2002 14:41:26 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g8ILeoS13022; Wed, 18 Sep 2002 14:40:50 -0700
Date: Wed, 18 Sep 2002 14:40:50 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [Cfrg] OpenPGP security analysis
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>

Here's something important.  The latest version of the OpenPGP-bis draft
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt
has got an error with regard to the MDC feature.  In section 5.13 it
says,

   The plaintext of the data to be encrypted is passed through the
   SHA-1 hash function, and the result of the hash is appended to the
   plaintext in a Modification Detection Code packet.  Specifically,
   the input to the hash function does not include the prefix data
   described above;

This is wrong; the input to the hash function DOES include the prefix
data.  This is how it is implemented in the commercial PGP version 7.X
(which only reads but does not yet create this packet), and in GnuPG,
which can both create and read it.  I checked interoperability on this
feature with Werner Koch a long time ago and we are both doing it the
same way.  I also just downloaded GPG and looked at the code to make
sure, and it does hash the prefix.

The error is repeated a couple of paragraphs later,

   During decryption, the plaintext data should be hashed with SHA-1,
   not including the prefix data 

The reason this is important is that it can help to prevent these attacks
which involve controlled modification to the plaintext.  Since the hash
includes the block of prefix data, which is hidden to the attacker,
he cannot predict what the hash is before his modifications, even if he
knows the entire message; and nor can he predict what the hash should be
after modification.  So he can't do as Trevor Perrin describes below,
rearranging blocks, or XORing data into an existing message, and then
compensating for his changes by XORing an appropriate value into the hash.

Guessing the prefix block will only have success 2^128 for the AES and
Twofish ciphers where we mostly use the MDC, or 2^64 for the older ciphers
if it is used there.  In either case this is a very low chance of success.

We should correct the draft to accurately reflect the behavior of the
implementations in the field.  Hashing the prefix data improves the strength
of the MDC construction so it is important for security.

Hal Finney
NAI.com

> From: Trevor Perrin <[e-mail]>
> Subject:  RE: [Cfrg] OpenPGP security analysis
> Date:  Wed, 18 Sep 2002 13:31:27 -0700
> List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
> List-ID: <ietf-openpgp.imc.org>
>
>
>
> [I apologize for holding a monologue here, just wanted to close this up]
>
> >From: Trevor Perrin 
> >
> >There may other ways of making predictable modifications of 
> >the plaintext, which can also take advantage of the fact that 
> >you only need to find a collision on 4 bytes of the hash, then 
> >can bit-flip the rest.
>
> For example, copying-and-pasting a sequence of ciphertext blocks, or
> deleting a sequence, will cause a scrambled block just after each splice
> point, but these scrambled blocks will be predictable by an attacker who
> knows the plaintext, because CFB mode lets an attacker with known plaintext
> reconstruct the keystream block that follows each ciphertext block.  Thus
> the situation is similar to Bellovin's cut-and-paste attacks against
> non-integrity-protected CBC, with the caveats:
>
>  - the attack requires the attacker know the entire plaintext string, so he
> can compute the hash value of the modified plaintext that corresponds to his
> ciphertext modifications
>
>  - the attack depends on the attacker trying out a large number of potential
> modifications, until he finds one that collides with the first X bytes of
> the current hash, where X is the number of hash bytes that reside in all but
> the last encryption block, (with a 16-byte block size and 20-byte hash,
> X=4,5,6,..,19 with probability 1/16th each)
>
> So in practice the attacker would choose a targeted modification he wanted
> to make, then choose some imperceptible modifications that he can make in an
> out-of-the-way corner of the document, and search through their permutations
> until he finds a collision.
>
> Trevor


Received: by above.proper.com (8.11.6/8.11.3) id g8IKVjE12946 for ietf-openpgp-bks; Wed, 18 Sep 2002 13:31:45 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8IKVek12932 for <[e-mail]>; Wed, 18 Sep 2002 13:31:40 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Wed, 18 Sep 2002 13:25:07 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8IKVZE3016724; Wed, 18 Sep 2002 13:31:37 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z61TG>; Wed, 18 Sep 2002 13:31:28 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: Trevor Perrin <[e-mail]>, "'Michael Young'" <[e-mail]>, "'David Wagner'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Wed, 18 Sep 2002 13:31:27 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

[I apologize for holding a monologue here, just wanted to close this up]

>From: Trevor Perrin 
>
>There may other ways of making predictable modifications of 
>the plaintext, which can also take advantage of the fact that 
>you only need to find a collision on 4 bytes of the hash, then 
>can bit-flip the rest.

For example, copying-and-pasting a sequence of ciphertext blocks, or
deleting a sequence, will cause a scrambled block just after each splice
point, but these scrambled blocks will be predictable by an attacker who
knows the plaintext, because CFB mode lets an attacker with known plaintext
reconstruct the keystream block that follows each ciphertext block.  Thus
the situation is similar to Bellovin's cut-and-paste attacks against
non-integrity-protected CBC, with the caveats:

 - the attack requires the attacker know the entire plaintext string, so he
can compute the hash value of the modified plaintext that corresponds to his
ciphertext modifications

 - the attack depends on the attacker trying out a large number of potential
modifications, until he finds one that collides with the first X bytes of
the current hash, where X is the number of hash bytes that reside in all but
the last encryption block, (with a 16-byte block size and 20-byte hash,
X=4,5,6,..,19 with probability 1/16th each)

So in practice the attacker would choose a targeted modification he wanted
to make, then choose some imperceptible modifications that he can make in an
out-of-the-way corner of the document, and search through their permutations
until he finds a collision.

Trevor


Received: by above.proper.com (8.11.6/8.11.3) id g8HJ8OT03526 for ietf-openpgp-bks; Tue, 17 Sep 2002 12:08:24 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8HJ8Nk03522 for <[e-mail]>; Tue, 17 Sep 2002 12:08:23 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Tue, 17 Sep 2002 12:01:52 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8HJ8KE3007255; Tue, 17 Sep 2002 12:08:20 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6D1Z>; Tue, 17 Sep 2002 12:08:16 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: Trevor Perrin <[e-mail]>, "'Michael Young'" <[e-mail]>, "'David Wagner'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Tue, 17 Sep 2002 12:08:15 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

Another attack, based on the fact that the last block containing part of the
hash is subject to bit-flipping, as David Wagner points out:

Suppose a 16-byte block size is being used, so the last 16 bytes of the SHA1
hash are subject to modification.  This means the attacker can make targeted
changes to the ciphertext, and if he is able to predict what effect these
changes have on the corresponding plaintext, then he can compute what the
new SHA1 hash should be.  If this new hash collides with the old hash in the
first 4 bytes, then he can bit-flip the last 16 bytes of the SHA1 hash to
match.  So the attacker can experimentally try around 2^31 ciphertext
modifications, and odds are one of them will collide with the unmodifiable 4
bytes of the hash, and he'll be able to make a forgery.

With CFB (which PGP uses) and known plaintext, the attacker can make
computable alterations in the plaintext by changing the ciphertext.
Px     (the xth plaintext block)
Px+1   (the x+1th plaintext block)
Py     (the yth plaintext block)
.
..

He can change the ciphertext with predictable results on the plaintext by
setting Cy=Cx.  Then he can compute:
Py   = (Py xor Cy) xor Cx
Py+1 = (Px+1 xor Cx+1) xor Cy+1

Note that the attacker can't control Py or Py+1 with precision, because if
he did targeted bit-flipping on the ciphertext he wouldn't know what that
block was encrypted as.  So this would mostly be useful for overwiting a
particular section of incriminating evidence with random data, or somesuch.


There may other ways of making predictable modifications of the plaintext,
which can also take advantage of the fact that you only need to find a
collision on 4 bytes of the hash, then can bit-flip the rest.

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HHOpO26319 for ietf-openpgp-bks; Tue, 17 Sep 2002 10:24:51 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8HHOok26315 for <[e-mail]>; Tue, 17 Sep 2002 10:24:50 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Tue, 17 Sep 2002 10:18:16 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8HHOhE3004191; Tue, 17 Sep 2002 10:24:43 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6C78>; Tue, 17 Sep 2002 10:24:40 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Michael Young'" <[e-mail]>, Trevor Perrin <[e-mail]>, "'David Wagner'" <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Tue, 17 Sep 2002 10:24:39 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

>From: Michael Young [mailto:[e-mail]]
>
>But if this is the scenario, then two facts complicate the attack:
>    M and M' must be formatted as OpenPGP packets; and,

you're right, this does complicate the attack - it means that in the simple
truncation attack (where the evil message ciphertext is just a truncation of
the innocuous message ciphertext) the decrypted literal packet data length
will be wrong.

Unless there's a way to get around that, the only attack I see, then,
requires the attacker to inject make-believe check bytes and OpenPGP packet
formatting, and thus will succeed with probability only 2^-16 cause the
check bytes will probably turn out wrong. 

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HGoAs25330 for ietf-openpgp-bks; Tue, 17 Sep 2002 09:50:10 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8HGo3k25322 for <[e-mail]>; Tue, 17 Sep 2002 09:50:03 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Tue, 17 Sep 2002 09:43:33 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8HGo0E3003118; Tue, 17 Sep 2002 09:50:00 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6CZH>; Tue, 17 Sep 2002 09:49:56 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Michael Young'" <[e-mail]>, Trevor Perrin <[e-mail]>, "'David Wagner'" <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Tue, 17 Sep 2002 09:49:55 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

>From: Michael Young [mailto:[e-mail]]
>
>[snip]
>
>Assuming the usual PGP public key model, the attacker doesn't need the
>sender to participate in this plan.  In this scenario, the attacker
>can alter message traffic from sender to receiver, so he could simply
>replace a message with is own well-formed PGP message.  
>Nothing new here.

Good point.  If the message is being secured with a passphrase instead of
the recipient's public key, however (which OpenPGP supports), the attack is
more serious, since the attacker would not normally be able to forge
passphrase-encrypted messages.


>
>This assumes that the receiver's public key is really public.
>If it's not, but you can convince the sender to encrypt arbitrary
>messages to it, then it's not really very private anyway.

The messages might not be totally arbitrary.  You might send a seemingly
innocuous (Word or PDF or XML or JPEG or whatever) document to Alice, and
say "forward this to Bob".  Alice reads the document and it looks fine, but
in some hidden field you've squirrelled away a more insidious message which
you plan on cutting out and using later.


>
>But if this is the scenario, then two facts complicate the attack:
>    M and M' must be formatted as OpenPGP packets; and,
>    the OpenPGP OFB scheme includes two redundant check bytes.

I believe the redundant check bytes reduce the probability of this attack
succeeding to 2^-16 when the insidious message is not located at the
beginning of the innocuous-looking message.  The attacker would have to cut
out the ciphertext block previous to where he spliced in his evil message,
and claim this is the ciphertext of the prefix block.  When the legitimate
recipient decrypts this first block, using CFB with an IV of 0, it will
produce bytes that are random from the attacker's perspective, and thus the
attacker won't have been able to anticipate and set the check bytes
appropriately.  If the attacker tries to modify the check bytes by bit
flipping the ciphertext and then submitting multiple tries to the recipient
until they match the prefix bytes, these modifications will be fed into CFB
and will destroy the next block of plaintext, thus invalidating the MDC
(even though the check bytes themselves aren't part of the MDC).

If the attacker places the evil message bytes at the very beginning of the
innocuous-looking message, then this caveat doesn't apply cause the sender
will set the check bytes appropriately, and the attacker just needs to
truncate.


>(I'll explain in more detail in a separate note when I get time.)
>
>The MDC in OpenPGP is really no more than a checksum, intended to
>detect accidental damage.  (In fact, during the discussion, I believe
>that some folks suggested that it be just a checksum.)  Before the
>MDC, there was little ability to detect *any* sort of accident -- not
>just truncation, but fairly arbitrary internal damage as well.  (When
>the payload is a compressed packet, the decompression might discover
>damage, but then again, it might not.)  There was discussion of a
>stronger MAC, but I think this was dropped given that OpenPGP has a
>strong signature mechanism.

The security note at the bottom of page 65 in the current draft indicates
that this MDC is a security feature, and is intended to provide message
integrity.
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt

It stills seems like switching from SHA1 to HMAC-SHA1 would yield the
desired level of security, possibly using a key derivation function on the
session key to generate seemingly-independent encryption and authentication
keys, though I'm not sure if that's necessary.

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HFMWc19418 for ietf-openpgp-bks; Tue, 17 Sep 2002 08:22:32 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HFMPk19413 for <[e-mail]>; Tue, 17 Sep 2002 08:22:30 -0700 (PDT)
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 LAA21676; Tue, 17 Sep 2002 11:08:33 -0400 (EDT)
Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA13028; Tue, 17 Sep 2002 11:21:49 -0400 (EDT)
Message-ID: <003801c25e5d$b5e44280$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "Trevor Perrin" <[e-mail]>, "'David Wagner'" <[e-mail]>, <[e-mail]>, <[e-mail]>
References:  <[e-mail]>
Subject: Re: [Cfrg] OpenPGP security analysis
Date: Tue, 17 Sep 2002 11:20:08 -0400
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-----
Hash: SHA1

Subject: Re: [Cfrg] OpenPGP security analysis

Trevor Perrin <[e-mail]> forwarded a note from...
> >From: David Wagner [mailto:[e-mail]]
> >http://www.cs.berkeley.edu/~daw/my-posts/mdc-broken
[quoted here for those new to the conversation:]
    I'm not sure I understand what you mean, but there's an attack.
    Suppose you want to make the receiver think message M was sent,
    even thought the sender would never authorize this.  Then you
    should construct M' = M || H(M) || X, where X is arbitrary and
    where || denotes concatenation (it better be at block boundaries).
    Ask the sender to transmit M'; he will form M' || H(M'), encrypt
    it with CBC mode, and transmit the result.  Now you can truncate
    the ciphertext, snipping it just before the "X" part, and the
    receiver will think M was sent, which is an integrity failure.

First, I should point out that, M *was* "sent", just not by the
apparent sender.  An MDC is not a signature.  The receiver should
not treat it as such.

Trevor went on to write:
> I don't see any complications that would trip this attack up in OpenPGP's
> encryption/integrity packet type.

Assuming the usual PGP public key model, the attacker doesn't need the
sender to participate in this plan.  In this scenario, the attacker
can alter message traffic from sender to receiver, so he could simply
replace a message with is own well-formed PGP message.  Nothing new here.

This assumes that the receiver's public key is really public.
If it's not, but you can convince the sender to encrypt arbitrary
messages to it, then it's not really very private anyway.

But if this is the scenario, then two facts complicate the attack:
    M and M' must be formatted as OpenPGP packets; and,
    the OpenPGP OFB scheme includes two redundant check bytes.
(I'll explain in more detail in a separate note when I get time.)

The MDC in OpenPGP is really no more than a checksum, intended to
detect accidental damage.  (In fact, during the discussion, I believe
that some folks suggested that it be just a checksum.)  Before the
MDC, there was little ability to detect *any* sort of accident -- not
just truncation, but fairly arbitrary internal damage as well.  (When
the payload is a compressed packet, the decompression might discover
damage, but then again, it might not.)  There was discussion of a
stronger MAC, but I think this was dropped given that OpenPGP has a
strong signature mechanism.

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

iQA/AwUBPYdIGFMkvpTT8vCGEQLxNwCfRfQ+SWNP0WlY+rfW3oU2z2IfAooAn2LW
5t9L+6P4AEdbQMg++aBynxdz
=uu0e
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8H2mKK16289 for ietf-openpgp-bks; Mon, 16 Sep 2002 19:48:20 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8H2mIk16285 for <[e-mail]>; Mon, 16 Sep 2002 19:48:19 -0700 (PDT)
Received:  from bsd.sigaba.com (67.113.238.131)  by bulwinkle.sigaba.com (Sigaba Gateway v3.5)  with SMTP; Mon, 16 Sep 2002 19:41:51 -0700
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8H2mHE3012610; Mon, 16 Sep 2002 19:48:17 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6CKF>; Mon, 16 Sep 2002 19:48:15 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'David Wagner'" <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: [Cfrg] OpenPGP security analysis
Date:  Mon, 16 Sep 2002 19:48:15 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
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>

>-----Original Message-----
>From: David Wagner [mailto:[e-mail]]
>
>Unfortunately, Hash-then-Encrypt has known security weaknesses, in
>general.  For instance, there is a chosen-plaintext attack that 
>lets you truncate a ciphertext without detection.  See, e.g.,
>http://www.cs.berkeley.edu/~daw/my-posts/mdc-broken


I don't see any complications that would trip this attack up in OpenPGP's
encryption/integrity packet type.  If you try to place M anywhere else
within M' besides the beginning, however, you'd have to guess at and prepend
duplicate prefix bytes to M, and snip so as to include the block previous to
these, and the attack would only have a 2^-16 probability of success because
the guessed duplicate prefix bytes probably won't match whatever the initial
prefix bytes turn out to be.

It seems like this could be fixed by using HMAC-SHA1 instead of just SHA1,
with a key derived by some function of the encryption key, but I'm not
sure..

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83IoOI25285 for ietf-openpgp-bks; Tue, 3 Sep 2002 11:50:24 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83IoN225281 for <[e-mail]>; Tue, 3 Sep 2002 11:50:23 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g83Inva21220 for [e-mail]; Tue, 3 Sep 2002 11:49:57 -0700
Date: Tue, 3 Sep 2002 11:49:57 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: S/MIME vulnerability
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>

There is a report out recently indicating that Microsoft Outlook has a
major S/MIME security vulnerability.  See
http://online.securityfocus.com/archive/1/290107/2002-08-31/2002-09-06/0
or http://www.theregus.com/content/4/26172.html.

It is the same bug which was publicized a few weeks ago regarding SSL
site certificates.  Although at the time Microsoft claimed that the problem
was restricted to IE, it turns out that Outlook is affected too.

Basically the Microsoft software fails to distinguish which keys are
meant to be signers of other keys.  Essentially, all keys are trusted
as signers, if those keys are signed by other valid keys.  The effect
is that virtually any key can be used to sign another.

The S/MIME world uses X.509 certificates, of course, and so what it
means is that if you have a cert from Verisign, say, then you can create
certs on any key with any name you like, and the Microsoft software will
believe them.  Outlook will accept a signed message from one of these
bogus certs and will display the signer name (which you created and can
be anything you want) as valid, without any warnings or error indications.

The Bugtraq article says,

> As it stands, there is virtually no difference between signed and unsigned
> email in Outlook.  Unless carefully inspected, signed email in Outlook is
> essentially meaningless.  This also applies to any signed email received
> over the past 5+ years.

This is a very serious security vulnerability to have gone so long without
being detected.

Hal Finney