Re: [TLS] Perhaps there's another way. Was: Verify data in the RI extension?

[Nelson B Bolyard <[e-mail]>]

On 2009-11-26 11:24 PST, Dr Stephen Henson wrote:

> Yes, it provides handles to the keys but the keys are not necessarily 
> accessible. Some applications set the parameters so the keys are never 
> extractable for security reasons. Some security standards *require* that
> keys can never leave the token.
> 
> That kind of thing causes problems with adding new algorithms (or
> algorithms with new inputs). Changing the inputs (as opposed to adding
> new ones) is less likely to cause a problem.
> 
> Adding new mechanisms or modifying existing ones in incompatible ways is 
> problematical if there is another standards process where it all has to
> be approved/discussed. If the hardware is FIPS 140-2 validated and needs
> a new validation to add a new mechanism that's a real pain.
> 
> As regards PKCS#11 I'm wondering if the use of interfaces like
> C_DecryptVerify() (which improve throughput by decrypting and MACing in
> one go) places additional restrictions on what can be done. I'm thinking
> here if they cause problems with feeding additional data into a handshake
> which isn't part of the actual handshake and might mess up state with
> e.g. stream ciphers.
> 
> Steve.

Yes, this is a very grave concern.  PLEASE do not propose any changes that
would necessitate new PKCS#11 mechanisms, which, in turn, would necessitate
new FIPS 140-2 or 140-3(!) security evaluations and certifications.  That
would slow the deployment of a new fix in certain (governmental)
environments by YEARS (no kidding).