On Fri, Sep 13, 2024 at 08:08:12PM -0700, Mark Robinson wrote:
> I want to thank everyone for your feedback. It's been super helpful.
>
> I think I should elaborate on what the problem is and how it can be fixed.
>
> I've worked with a lot of companies who want to use mTLS (as bas as the
> name is) to increase security but don't know how to do it in a way that
> won't reduce reliability. For example, many companies require a certificate
> signed by a public CA and then *emailed* to them. They have the annual cert
> expiry of a regular cert combined with a manual (and hackable process) that
> basically guarantees downtime when someone goes on vacation.
>
> What I'd like to cover:
> - How two orgs (that aren't CAs) can exchange keys
> - How to rotate keys
> - What parameters keys should be set, and how keys should be validated
> - When and how keys should be updated
> - All of this without manual steps or #$%#$%ing email.
>
> Setting up cross-validation of TLS should be a single line change for high
> performing organizations and should never, ever, ever involve email certs
> between customer service reps.
Trusting an arms-length 3rd party public CA to authenticate access to
one's systems by one's business partners is a murky business...
The best one can do without devolving responsibility to unaccountable
3rd-parties is self-service portals, where authorised admininstrators
from each business partner can on a self-service basis:
- Generate, and download a PKCS#12 bundle with a private key and
matching certificate issued by the relying party's CA.
- Authorise a previously downloaded key.
- Deauthorise a previously authorised key.
On the client side, the use of an X.509 certificate (rather than say a
raw public key) is then soley to grease the protocol wheels, the names
in the certificate are irrelevant, the server has its own list of
authorised keys and identity mappings.
In other words, carefully implemented, the client-side of "mTLS" is more
PK than PKI. Or, more precisely, all the infrastructure is on the
relying party side.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
