[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: S/MIME v3.2 IDs key size text
- To: Paul Hoffman <phoffman@xxxxxxx>
- Subject: Re: S/MIME v3.2 IDs key size text
- From: Blake Ramsdell <blake@xxxxxxxxxxxx>
- Date: Fri, 9 May 2008 17:12:39 -0700
- Cc: "Turner, Sean P." <turners@xxxxxxxx>, ietf-smime@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1210378540; bh=zWcwQk26qycMHwi7DfOWsWP2PTVm8sb+GhPc u2b6m+k=; h=Received:X-DKIM:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:X-MM-Ex-RefId; b=N06dvm Iftu5CdrR2aazsKH9glp1w+1zFfOrgaozB8rIYkv/q7DR9nA9kWbkmD7LSSMEcFEC9n CT5tJIVMCi/dNxupa1qiuuE/4XXGj+jTvtzPedCqSZV2SnqErDQjgLB0CeNpND/lQPg VtP3w4Fq6c3SIfeqTPgJL48w+WF4kDI=
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1210378363; bh=zWcwQk26qycMHwi7DfOWsWP2PTVm8sb+GhPcu 2b6m+k=; h=Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To: User-Agent:X-MM-Ex-RefId; b=sP/9dowMONzfAAmVPymL4enNbH/PvxAQz+cfPH EuzoxQjx4I0e6WjxNZZ8nrOtgGCVVhphJWSBppEblZUlAVhb8fpRRrcutYJ7UsnrtMt NU3tyhlFmJ5tV92kVIbohWWP11e+qDWj9Wg0cTv06F+PKH2X4SbOrq4pZ1PakfcBIA=
- In-reply-to: <>
- 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>
- References: <> <> <> <>
- Sender: owner-ietf-smime@xxxxxxxxxxxx
- User-agent: Mutt/1.5.15+20070412 (2007-04-11)
On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote:
> Beyond what Russ just pointed out, I find the first line to be in bad
> taste. Any IETF spec that says "you must not be able to verify a signature
> even though it is valid" is pretty offensive.
>
> Can we return to talking about interoperability?
I think you and I are on the same page, and there's two things:
1. Interoperability. The key sizes to guarantee two implementations will talk
to each other.
2. Security considerations. The key sizes that are a no-no due to insufficient
or overly-sufficient size.
Have we given up on the separation of these?
Blake