Re: Fixing the secret keys, and a small apology

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> Wed, 05 September 2001 13:17 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29948 for <openpgp-archive@odin.ietf.org>; Wed, 5 Sep 2001 09:17:56 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id f85CwDE15711 for ietf-openpgp-bks; Wed, 5 Sep 2001 05:58:13 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85CwCD15705 for <ietf-openpgp@imc.org>; Wed, 5 Sep 2001 05:58:12 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15ecFH-0006rm-00 for ietf-openpgp@imc.org; Wed, 05 Sep 2001 14:57:31 +0200
To: ietf-openpgp@imc.org
Subject: Re: Fixing the secret keys, and a small apology
References: <p05100309b7baf2e20a43@[192.168.1.180]>
From: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Date: Wed, 05 Sep 2001 14:57:31 +0200
In-Reply-To: <p05100309b7baf2e20a43@[192.168.1.180]> (Jon Callas's message of "Tue, 4 Sep 2001 14:28:50 -0700")
Message-ID: <tgae09ztfo.fsf@mercury.rus.uni-stuttgart.de>
Lines: 30
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <jon@callas.org> writes:

> * Change the entire public key version number to 5, and add in a check.

I think V5 should be started only if a few other adjustments are made,
too.  The certificate-does-not-cover-key-expiration-time problem comes
to my mind here. ;-)

> * Change the String-to-Key specifier. The solution here is adding in the
> tag 254 to 3.7.2.1

and reserve 254 (and 255) in 9.2 for this kind of use.

> and have 254 denote an improved S2K. The benefit here is
> that it causes the least change to user software, and is as secure as
> anything else. The downside is that if someone uses a cipher algorithm
> there, then they can't use algorithm 254. However, not only is using a
> cipher algorithm deprecated, but our present max cipher number is 10.

This is not quite correct, the numbers 100 to 110 are already
assigned, too, technically speaking.  However, 254 was never an
official private/experimental symmetric algorithm identifier, so I
don't think we have to care about potential problems caused by using
254 at this particular place, especially since using symmetric
algorithm specifiers in this context is deprecated anyway.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898