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
- Fixing the secret keys, and a small apology Jon Callas
- Re: Fixing the secret keys, and a small apology Michael Young
- Identifying revoked certificates Michael Young
- Re: Fixing the secret keys, and a small apology Florian Weimer
- Re: Fixing the secret keys, and a small apology Werner Koch
- Re: Fixing the secret keys, and a small apology Michael Young
- Re: Fixing the secret keys, and a small apology Michael Young
- Re: Fixing the secret keys, and a small apology Werner Koch
- Re: Fixing the secret keys, and a small apology Jon Callas
- Re: Identifying revoked certificates Jon Callas
- Re: Identifying revoked certificates David Shaw
- Re: Identifying revoked certificates Michael Young
- Re: Identifying revoked certificates Jon Callas
- Re: Identifying revoked certificates Jon Callas
- Re: Identifying revoked certificates Michael Young
- Re: Identifying revoked certificates Werner Koch
- Re: Identifying revoked certificates Michael Young
- Re: Identifying revoked certificates Werner Koch