BR: Consider increasing minimum key size to 4096

[a-stacey]

According to wikipedia:

The NIST recommends 2048-bit keys for RSA. [15] An RSA key length of 3072 bits should be used if security is required beyond 2030.[16] NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys.[17]

https://en.wikipedia.org/wiki/Key_size

So it seems reasonable to move the next power of two beyond 3072 to make sure that we are well prepared beyond 2030 or enforcing that keys expire before then (which would also seem to be a reasonable requirement).

Original Author: sta358

(Moved with github-migration-0.1.0.0 (package github-migration-0.1.0.0 revision df9f38b))

[sarafalamaki]

The expirationTime is already a query param. It might be better if the whole request was a json object rather than a mixture of JSON and a query param though. Like:
data newKey = { newKey_PEM_RSAPubKey :: PEM_RSAPubKey , newKey_ExpirationTime :: ExpirationTime
That way we can add more params if needed. Again, this is going to be made redundant once we move to X509 certs (JOSE).

Original Author: fal05c

[a-stacey]

See also the issues discussed in #212 which describes an issue that means that we only validate that the key size is greater then (2^N)-8 as this is also relevant to this discussion and the minimum accepted key size.

Original Author: sta358

[sarafalamaki]

The reason I'm reluctant to increase the minimum key size is that a lot of hardware can't generate /store keys that big. Forcing software to do it is less secure than having a smaller key in hardware. It's an easy thing to change later, so we can delay the decision until the integration phase.

Original Author: fal05c