Russ Housley <[email protected]> wrote: >> <t>ACP nodes MUST NOT support certificates with RSA public keys of >> less than 2048 bits. They MUST support certificates with RSA public keys >> with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST >> support certificates with ECC public keys using NIST P-256, P-384 and >> P-521 curves.</t> >> >> <t>ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for certificates with RSA key and the same RSA signatures plus ECDSA signatures for certificates with ECC key.</t> >> --- >> >> I don't understand whether your note about the key length of the curves is an indication of missing text. When i first reviewed with Ben, i had to enter the curves because thats as specific as necessary AFAIK, but given how the key length is implied, i wouldn't understand why i would need to write those down. I don't remember that i have seen that being done either in other RFCs i read through. >> >> In any case, specific text suggestions always welcome in case this text is not sufficient.
russ> I was expecting you to make one of the curves MUST and the others
russ> SHOULD. Making all three curves MUST is okay with me, but it will
russ> increase implementation size.
russ> Likewise, I was expecting you to make one of the hash functions
russ> MUST and the others SHOULD.
I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- terminology
from
IPsecME's RFC8247.
It would be nice if SAAG lifted section 1.1 into a BCP14-like document, as I
think that it has widespread applicability throughout documents that want to
establish interoperable crypto.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
