3 ms·
> 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.
by michaelt 3y ago
> 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.
- AnonCoward42 3y agoInstead 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.
- gvx 3y agoIMO, 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.
- lifthrasiir 3y agoPEM 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.
- crote 3y agoSomeone 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.
- gvx 3y agoThe 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.
- marcosdumay 3y agoOr, just set the expiration date to 1970-01-01.