Hm, ok.. I'm not sure why tho. As far as I can tell, the baseline requirements always mention a private key in combination with the corresponding public key in a certificate. So I don't think CAs are mandated to do this. Anyone can issue a certificate for a randomly found private key. It's only when the CA is attended on the fact a certificate was issued with a compromised key, the CA has to act.
Also, you might want to doublecheck the private keys in the Boulder repository in that case. test-ee.key was still functional (now revoked). Maybe others are too. Everything from /test/ with "key" in its name is now revoked.
I wouldn't dare provoking the LE staff obviously No need to get dramatic/threaten me..
@Osiris lets cut them some slack, I would not be surprised if they are under pressure to keep LE safe and reliable. They have to fend off all the evils lurking out there on the internet. And maybe sometimes the community just mildly triggers the system. It is unfortunate that tolerance is not something easily afforded an organization dealing with security. Just asking to look at the comment from their perspective.
Offtopic: I can understand pressure to keep LE safe and reliable. I'm just personally offended James thinks it's necessary to threaten me to prevent me from actually doing something like posting 100 private keys?
I apologize - I was too harsh here, and reflexively assumed you knew how we have to respond to private key compromise reports. (To explain this, without excusing my reaction: We have to treat these as formal incidents, with a short time limit to investigate, engage on-call team members, and verify that the keys are blocked. There's a history of these being reported to us right at the start of holidays.)
There's multiple ways we have of blocking a private key from future issuance. I used this private key leak as a training opportunity for a new junior engineer. We went through investigating the key algorithm, how to geenrate a CSR, issuance via certbot, and ultimately revocation of this leak. We used one of my domains to illustrate the point that if a key is leaked, anyone on the internet could perform this same action. Under the hood the key compromise reason kicks off a chain of events that ultimately revoke every certificate with a matching Subject Public Key Info hash (SPKI).
Typing from the middle of the woods. Sorry for typos.
Well okay, this IS a newsflash for me now. When @Bruce5051 mentioned Never share your PRIVATE KEY, I merely thought that was to say (other than literally just not sharing it) to never use a shared/exposed key. I at least knew that much.
But from all of the hubbub going on in this post, I'm now seeing it's MUCH more than that.
And for that, I humbly apologize for wasting your time in having to create a revocation for something I never had any intention of using outside of testing my program.
Should I take it that no one should include the signature portion of their token? Just the header and payload?
I had looked at all of the error-related posts, like Parse error reading JWS and never saw any comment about them posting their private key.
Was it because I didn't explicitly state from my initial post that it was just a test key (even though I did say test request?
I definitely don't want to be wasting people's time from mistakes like that.
I do find it odd that the "private key" content I posted here from jwt.io is different from the text file that was used from my system.
What was posted here begins with MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQ, which matches the start of my file, but it veers off after that: Here gev...; File gjg.... And it doesn't even contain ANY of the JWK.D value.
If you'd like to see for comparison, I can post the file content here. I just don't want you to have to waste generating another revocation. Again, it's all just a temporary test key while I test my program.
For that matter, where did that private key come from, when I nulled out the JWT.D value prior to sending the token?
Signatures are safe to post. They don't contain private data and ultimately are the result of a one-way hash function. So unless an unsafe hash algorithm is used (e.g. SHA-1), signatures are safe. (Even with a SHA1 hash it's safe to post, just not safe to use any longer due to too high chance of collisions.)
Personally, I'm still not convinced it's necessary for CAs to make sure any posted private key can't be used on their system even if there isn't a certificate associated with it. If that's the case, I wish the LE team good luck (sincerely! as it's probably quite labor intensive) with indeed revoking all the private keys posted on this Community (there are A LOT).
It seems 22.214.171.124does actually mandate this! Although one can argue what the confines of "made aware" is:
The CA SHALL reject a certificate request if one or more of the following conditions are
4. The CA has previously been made aware that the Applicant’s Private Key has
suffered a Key Compromise, such as through the provisions of Section 126.96.36.199;
So if a LE crewmember does come across a private key, that indeed would mean that the CA SHALL make sure that key can't be used any longer, such as revoking a randomly generated cert and subsequently revoking it, with keycomprimise as reason.
My initial BR search did not find this paragraph, my apologies to James for doubting. Although this does maybe present a problem with all the private keys posted on the Community. Is "made aware" only when an actual crew member comes across the private key or is posting it on the Community "made aware" enough?
If I understand James post correctly, even randomly generated keys which are not intended to be used for anything at all need to be revoked. So with or without mentioning "test key".