> In short: don’t ever try and redact real private keys. For documentation purposes, just put “KEY GOES HERE” in the appropriate spot, or something like that.
Personally I've always liked redacted keys because it makes it clear to users what they should expect.
Does this system want a PEM or a DER or a CER or a CRT or a JKS or a P7B or a P11? Or some vendor-specific format? The public key or the private key? Or both in the same file? A literal value, or a filename of a certificate on disk? A keyring?
It'd all be a heck of a lot easier if we didn't have such a mess of key formats.
Someone should make a set of documentation keys which are invalid, but still look valid. That way they could be used for documentation, but couldn't accidentally be copied into a production environment.
The simplest thing I can think of is by generating keys that follow the exact right structure but some invariant like n = p * q is broken. Of course that relies on the assumption that implementations do some basic sanity checks like that. I don't know if that's a fair assumption to make.
PEM headers can be safely kept, otherwise base64-encoded payload has no discernible pattern at all and thus should be removed entirely even in your reasoning.
Instead you could vary it by using i.e. "PEM KEY GOES HERE". Tho I must admit there is no real harm in producing a new private key that is not used - at least not directly; it might lead to copy/paste usage, which is obvious user error, but depends on the audience.
IMO, if you're writing documentation, you should be aware that any sample text or code will be copy/pasted by someone and will end up in production there.
Comments
> In short: don’t ever try and redact real private keys. For documentation purposes, just put “KEY GOES HERE” in the appropriate spot, or something like that.
Personally I've always liked redacted keys because it makes it clear to users what they should expect.
Does this system want a PEM or a DER or a CER or a CRT or a JKS or a P7B or a P11? Or some vendor-specific format? The public key or the private key? Or both in the same file? A literal value, or a filename of a certificate on disk? A keyring?
It'd all be a heck of a lot easier if we didn't have such a mess of key formats.
Someone should make a set of documentation keys which are invalid, but still look valid. That way they could be used for documentation, but couldn't accidentally be copied into a production environment.
The simplest thing I can think of is by generating keys that follow the exact right structure but some invariant like n = p * q is broken. Of course that relies on the assumption that implementations do some basic sanity checks like that. I don't know if that's a fair assumption to make.
Or, just set the expiration date to 1970-01-01.
PEM headers can be safely kept, otherwise base64-encoded payload has no discernible pattern at all and thus should be removed entirely even in your reasoning.
Instead you could vary it by using i.e. "PEM KEY GOES HERE". Tho I must admit there is no real harm in producing a new private key that is not used - at least not directly; it might lead to copy/paste usage, which is obvious user error, but depends on the audience.
IMO, if you're writing documentation, you should be aware that any sample text or code will be copy/pasted by someone and will end up in production there.