On 2020-10-01 6:36 p.m., Benjamin Kaduk via Datatracker wrote:
A couple of the new bits in the -29 might benefit from targeted review (noted
inline), e.g., for CDDL, TSV, or INT-specific aspects.
Carsten has already done that for CDDL.
I'm unclear what TSV and INT specific things you have in mind.
ACP nodes MUST NOT support certificates with RSA public keys whose
modulus is less than 2048 bits, or certificates whose ECC public keys
are in groups whose order is less than 256 bits. RSA signing
certificates with 2048-bit public keys MUST be supported, and such
I think I mentioned this previously (and sorry for the repetition if I
did), but just in case I didn't: this 256-bit group order requirement
excludes Ed25519 and friends. If you're fine with that, that's okay; I
just want to make sure it's an informed choice.
Right, Ed25519 is considered to be a curve of 128-bits of equivalent
strength. My understanding is that secp256*, while having 256-bit
curves, is also 128-bits of strength.
And RSA keys of 2048 bits is also of that relative strength.
I think that this is what Toerless is trying to say, but he didn't get
the wording right. Can you advise what the correct way to ask for this
is? Can we just point elsewhere?
I think I may have failed to think about and comment on this previously,
but doing direct ECDH with the (static) key in the certificate is pretty
uncommon -- as I understand it you don't need this bit set in order to
use the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite, for
example. To be clear, I'm not saying it's inherently wrong to make this
requirement, just that I don't think it's needed for the use-cases
presented in this document. (It may also make it harder to get such
certificates issued in the future, though it's hard to predict what
path CA policies will take in the future.)
Agreed, and it's why I prefer to say less.
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
