Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07

["Brockhaus, Hendrik" <[e-mail]>]

Roman, Mike

> Von: Mike Ounsworth <[e-mail]>
> Gesendet: Freitag, 5. November 2021 19:00
> 
> Hi Roman!
> 
> > AES128 + RSA2048 would be more consistent based on the principle of
> matching relative key strength. However, if prior specs said AES256+RSA2048, I
> think we should be careful about weaking the requirement regardless of
> consistency.

As the algorithm use profile from RFC 4210 Appendix D.2 was not maintained for a long time, AES was just mentioned as a further alternative. The mandatory algorithm back then was 3-DES.
I am not aware of any document stating AES256 for transporting private keys. As it is a critical operation, one could recommend to use the maximum strength available, but we should mandate only strength comparable to the key transported. > 

> A couple thoughts here:
> 
> 1. I don't think we have any language stating that these profiles are
> requirements. The language (from Hendrik's slides for Monday) is the column
> header " Recommended for managing keys up to". It's a nit-pick, I know.

My understanding would be that at least the strength of the key to be managed should be used. Higher strength should also be allowed.

> 
> 2. An implementation doing AES256+RSA2048 exceeds the profile that
> recommends AES128+RSA2048. That's fine, unless there's an on-the-wire
> interop concern here? For example if an existing CMP client handling RSA2048
> keys only has an AES256 implementation and would barf if the server suddenly
> started using AES128? I assume that sort of thing would be caught in product
> testing.
> 
> Or is your concern more to do with optics / security proofs / FIPS and CMVP
> style certifications if we lower the required AES strength of a profile?

Hendrik