RE: S/MIME v3.2 IDs key size text (resend, no signature)

At 5:57 PM -0400 5/12/08, Turner, Sean P. wrote:
>  >-----Original Message-----
> > From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> > [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Paul 
> > Hoffman
> > Sent: Monday, May 12, 2008 12:49 PM
> > To: Tony Capel
> > Cc: ietf-smime(_at_)imc(_dot_)org
> > Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature)
> >
> >
> > At 12:14 PM -0400 5/12/08, Tony Capel wrote:
> > > Sean et al:
> > >
> > > How about:
> > >
> > >     0 <  key size < 512     : MAY     but refer to security
> > considerations
> > > section
> > >   512 <= key size < 1024    : SHOULD- but refer to security
> > considerations
> > > section
> > > 1024 <= key size <= 2048   : MUST
> > > 2048 <  key size           : MAY     but refer to security
> > considerations
> > > section
> > Could you add verbs to your table? MAY what? SHOULD- what?
> Not sure what Tony was thinking but I suggested that this go in 3850bis so
> it would have been for receiving agents.
In your mind, what verb goes with "SHOULD-" for a receiving agent? 
"SHOULD be able to verify but we won't require it in a future 
version"? If so, that means that we are saying "we intend to break 
interoperability with previous versions of this spec because of 
security issues". Breaking the implied stability promise we made when 
there is no real threat (such as people forging 768-bit signatures) 
seems a bit over the top.
Further, such an interpretation of SHOULD- also means that we intend 
to deprecate 1024 bit keys in the foreseeable future even though the 
cryptographic security of >90% of Internet commerce is based on those 
keys. If the intention was to get implementers to take us seriously, 
saying this may not have the desired effect.