New CS proposal: Cross-organization mTLS

[MarkSRobinson]

What is the proposed Cheat Sheet about?

There is currently zero standards around how organizations can setup mTLS between them. In the absence of any recommendations, people will just make up whatever rules appeal to them. These rules basically make zero sense if you understand TLS at any level, but on the plus side they also carry the risk of hard downtime if a mistake is made or if someone is on vacation.

What security issues are commonly encountered related to this area?

1. Using certificates signed by public CAs for mTLS.
2. Manually emailing short lived certificates between organizations.
3. Not validating the certificates that are emailed between organizations.

What is the objective of the Cheat Sheet?

Fundamentally, I want a standard I can point to such that it mitigates the following risks:

1. Doesn't require manual certificate management for mTLS. I really want to emphasize that preventing downtime is the goal here.
2. Doesn't require using public CAs which are subject to their own problems.
3. Actually guarantees some level of security/authentication when using mTLS.

What other resources exist in this area?

The quality of documents around mTLS is shockingly poor. Most tutorials on the subject recommend hard-coding credentials.
Other documents are basically sales pitches for low-quality vendor solutions which work only inside a walled garden.

[kwwall]

@MarkSRobinson - I think this is a great idea, especially if you are willing to do the heavy lifting and create a PR. If you do that, I will volunteer to be one of the reviewers and if he doesn't mind, I'd like to volunteer @markgamache as the 2nd reviewer.

[mackowski]

Agree with @kwwall this is a good idea. @MarkSRobinson do you want to create initial PR?

[MarkSRobinson]

Yup, I'll get started on it.

[markgamache]

Yup, I'll get started on it.

I can't wait to see this. Given that this is pretty complex and there are a ton of tradeoffs, if you want to start with a more celebrative (g-doc or such) doc type, before a PR, that might be good.