[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CAT HERDING] Key lengths for interoperability and security considerations
- To: ietf-smime@xxxxxxx
- Subject: [CAT HERDING] Key lengths for interoperability and security considerations
- From: Blake Ramsdell <blake@xxxxxxxxxxxx>
- Date: Tue, 13 May 2008 10:57:06 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1210701619; bh=FH2Y957tO6NjlIoiZae221nwDz8yazYs1V6m 4dcfdsk=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type:Content-Disposition: User-Agent:X-MM-Ex-RefId; b=LsCO1F5MDUN5NexfozscWN2JJe14H3LeWxtZcL B8H9PvXNtbYdf2Zsfd5VWh4m8hfOnVlq1/DMnhrodC+HHnEQ3lBS+pd3FaFA1NOqaNF fgZxMfGW6DwvkVoNCzEWh6s8WbIrk9yIAZbEvR0JevKwBxx7uCLrKh/dIYzC+SdgM4=
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1210701436; bh=FH2Y957tO6NjlIoiZae221nwDz8yazYs1V6m 4dcfdsk=; h=Date:From:To:Subject:Message-ID:MIME-Version: Content-Type:Content-Disposition:User-Agent:X-MM-Ex-RefId; b=f0YB6 gK7E7GvLC0mc5H0wBFsxlsSgZbOXqyPoI8vjnoJGYsjJFgY1m2hZt8tB3bN7VW5tUaF 5JNG8U7wkiYDkJ2U8MO9P0ClFB5pNFyFzGCCa5ZVKbR3tAUeQgLHJG+q/1zUcwe2dDz dPOcsKdvNwqzILI5aN2JtYWcsomemH5M=
- List-archive: <http://www.imc.org/ietf-smime/mail-archive/>
- List-id: <ietf-smime.imc.org>
- List-unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
- Sender: owner-ietf-smime@xxxxxxxxxxxx
- User-agent: Mutt/1.5.15+20070412 (2007-04-11)
OK, so what needs to be done to come to closure on the key sizes. I think a
skeleton of The Right Thing looks something like this:
1. Normative language (MUST / SHOULD with lots of plusses and minuses and
atsigns) describing the minimum and maximum lengths for keys. This covers
the most important area of interoperability, and needs to be very clear
about signing key lengths vs. verifying key lengths vs. generating key
lengths.
2. An indication by those MUST / SHOULD statements pointing to the security
considerations. This is the best we can do to guide people away from using
one bit keys, and steer them in the direction of strong crypto.
3. Wording in the security considerations regarding the use of overshort or
overlong keys.
Sean is preparing a summary of the existing discussion to address each point,
and we'll see where we're at.
Blake