RSA Key Generation Parameters - public exponent, certainty, string-to-key count I want to know what values are appropriate for the public exponent and certainty when generating an RSA Key (for example using Bouncy Castle RSAKeyGenerationParameters function). 

What is the significance of the the string to key count (s2kcount) which appears to be optional input for the BcPBESecretKeyEncryptorBuilder bouncy castle function?

Is there an authoritative source that has a simple and answer to what to enter for the public exponent, certainty and string to key count? I have checked the RFC 4880 and other posts but have been unable to understand them to work this out.
Short answer: public exponent $65537$, certainty $5$. Terms and Conditions May Apply.

I have no clues about string to key count.



Whenever one wants to know "&nbsp;what values are appropriate&nbsp;", there's the problem of defining appropriate: is there some normative context, e.g. FIPS&nbsp;186-4? I'll assume that reference.

This, and all standards I know, agree that public exponent can be $65537=2^{16}+1$, and that's a choice that one will regret only on the grounds of performance of the public-key function (used for encryption and signature verification, not decryption or signature generation). A few standards allow $3$ which seems safe with a padding scheme randomizing the message, and can improve said performance by a factor like 8.

Answering the BouncyCastle-and-Java-specific part of the question (which is largely off-topic) would require the effort of ensuring that certainty is actually used as a number of Miller-Rabin primality tests with random base, and for random primes half the key's modulus size. I have no true assurance this holds, and assume it blindly.

FIPS&nbsp;186-4 only allows $1024$, $2048$, and $3072$-bit public modulus, and requires using random $p$ with auxiliary conditions on the factorization of $p-1$ and $p+1$ at the $1024$-bit level, without stating a rationale for when the auxiliary conditions are required. Some think these are pointless, other including me believe they make some sense when generating extremely many keys, in order to repel down to entirely hopeless levels the possibility that methods derived from Pollard's $p-1$ can factor one of the many moduli with better odds than general methods can factor a single modulus.

Whatever the reason, with the assumption that BouncyCastle uses random primes, FIPS&nbsp;186-4 leaves us with the only applicable generation method that of appendix B.3.3, at step 4.5.1 of which we are told to "&nbsp;test $p$ for primality as specified in Appendix C.3, using an appropriate value from Table C-2 or C-3 in Appendix C.3 as the number of iterations.&nbsp;", with a rationale given for these in appendix F.3, telling us we should use table C-2 if we want residual odds of having a composite matching the standard-estimated security level of the key, or table C-3 for $2^{-100}$ odds.

Here are these tables; what interests us for certainty is the values given for "&nbsp;$p$ and $q$&nbsp;" (which size is, we assume, half the key's modulus size). For example, the bottom entry in the first table tells us that certainty of $4$ is enough to generate each of the two $1536$-bit prime required for $3072$-bit RSA key and odds of generating a composite less than $2^{-128}$. Higher values further reduce the bound for these odds (which is mostly pointless), and make key generation slower (but less than proportionally, so using $4$ instead of $5$ only gives a moderate gain).



Appendix F.1 in FIPS&nbsp;186-4 gives the method used to compute these tables, and can be used for reduced certainty (thus somewhat faster key generation) for keys larger than $3072$-bit. Actual odds of choosing a composite are believed to be significantly lower than given by theses tables and method.

Note: Nothing in this answer shall be understood as suggesting that generating RSA keys using BouncyCastle with certainty of $5$ may be FIPS&nbsp;186-4 conformant.