Bouncy Castle provides 6 different paddings for padding messages.
However, I am not quite sure which one to choose from.
ISO10126d2, ISO7816d4, PKCS7, TBC, X923, ZeroByte.
Given that the native Bouncy Castle API requires the message to be greater than 114 bytes.
What could be the recommended padding to be used to pad the message?
What is the strength and weaknesses of each padding?
I would want to choose either X923 with RNG or ISO10126d2 but I am not really sure about that.
You've specified padding modes for block ciphers. For block ciphers, the padding depends solely on the mode of operation and of course the block size. The paddings you mention are mainly for ECB & CBC mode of operation. Signatures however depend on a hash function, not on a block cipher. Hash functions usually perform some kind of padding internally, but that padding is not configurable.
Signatures may also pad the hash itself but that function is not intrinsic to signature schemes; a scheme without padding could well exist. For RSA we would regularly use the PKCS#1 v1.5 or PSS signature schemes, and these include a padding method of the same name (the precise names are mentioned in the PKCS#1 standard, but nobody uses that while discussing the schemes).
However, if we look at the definition of Ed448 signature scheme then we'll find the following algorithm description:
5.2.6. Sign
The inputs to the signing procedure is the private key, a 57-octet string, a flag F, which is 0 for Ed448, 1 for Ed448ph, context C of at most 255 octets, and a message M of arbitrary size.
Hash the private key, 57 octets, using SHAKE256(x, 114). Let h denote the resulting digest. Construct the secret scalar s from the first half of the digest, and the corresponding public key A, as described in the previous section. Let prefix denote the second half of the hash digest, h[57],...,h[113].
Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114), where M is the message to be signed, F is 1 for Ed448ph, 0 for Ed448, and C is the context to use. Interpret the 114-octet digest as a little-endian integer r.
Compute the point [r]B. For efficiency, do this by first reducing r modulo L, the group order of B. Let the string R be the encoding of this point.
Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and interpret the 114-octet digest as a little-endian integer k.
Compute S = (r + k * s) mod L. For efficiency, again reduce k modulo L first.
Form the signature of the concatenation of R (57 octets) and the little-endian encoding of S (57 octets; the ten most significant bits of the final octets are always zero).
Here PH is the hash function used over the message which is a configuration option.
Note that there are two parts that could be considered padding: dom4(F, C) || prefix || PH(M) pads the hash with dom4(F, C) || prefix, and dom4(F, C) || R || A || PH(M) pads the hash with dom4(F, C) || R || A. However, neither of these two calculations are configurable (dom4 is an ASCII string, prefix is part of the hash output, R is a randomized point calculated from A and A is the public key (also a point).
All in all, no padding mode should have to be indicated for Ed448; you should just have to configure the PH, i.e. the message hash.
