Hubert Kario <hka...@redhat.com> writes: >Note that I asked for "being able to handle", not "selects and uses".
The issue here is that a Cortex M3 isn't going to be able to handle RSA-2048, no matter what an RFC says :-). That's what the "ability of the hardware to deal with large keys" was meant to say. When I've run into upper limits, it's almost always because the hardware can't go much beyond the given upper-limit value (Sun's Java implementation with its braindamaged 1024-bit upper limit for DLP keys was a notable exception). So I could perhaps say something like "implementations SHOULD handle key sizes of up to 2048 bits, and MAY expect to see key sizes up to 4096 bits" or something similar. >no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1. of RFC >5246, you need to be explicit about it. Maybe I'm missing something here, but the text that refers to signing with "RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty unambiguous. Is there something else I need to add there? >The implementation will need to interoperate with normal (i.e. already >deployed) TLS 1.2 implementations anyway, why prevent code reuse? Right, and if you need that you can include all the extensions you want. If you only need TLS-LTS, you can leave them out. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
