Thanks for the additional details, Mark. So it sounds like these
organizations are not only requiring that the remote party's certificate be
issued by a public CA, but that it be a specific certificate.
Couple of observations here:
1. This is clearly not business for the TLS WG. This WG doesn't do
anything with how certificate trust is provisioned. UTA might be right, or
just run through the DISPATCH process.
2. This seems like a terrible design.
* It's basically HTTP certificate pinning [RFC7469], which is being
aggressively deprecated by browsers for exactly the downtime reasons you
mention.
* The public CA isn't adding any value here, and as you note, they add
to the downtime risk
* Trying to automate this is pointless, because you'll just end up back
at the same problem of establishing trust with the other side. If you had
an automated "here's my new cert" protocol, well, how do you verify that
the thing sending you the new cert is authorized to?
In light of (2), I would be disinclined for the IETF to do any work on this
particular flavor of the mTLS problem.
On Fri, Sep 13, 2024 at 11:08 PM Mark Robinson <m...@markrobinson.io> 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.
>
> Mark
>
> On Wed, Sep 11, 2024 at 4:30 PM Peter Gutmann <pgut...@cs.auckland.ac.nz>
> wrote:
>
>> Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org> writes:
>>
>> >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes
>> >confusion where customers ask whether "mTLS" is a different protocol or a
>> >specific TLS implementation? However, it can be argued that this
>> unfortunate
>> >term has already taken root.
>>
>> +1, Richard pretty much said everything I have concerns about but saved
>> me a
>> lot of typing. mTLS *is* TLS, there's no need to give it a special name
>> for
>> marketing(?) purposes.
>>
>> Having said that, I'd have no problems with a "TLS Profile for xxx",
>> which is
>> what it really seems to be.
>>
>> (And I'll add an obligatory comment that what (m)TLS does isn't mutual
>> authentication, it's unidirectional authentication in both directions, but
>> that boat has long since sailed. If you wanted to have actual mTLS it'd
>> have
>> to use PSK).
>>
>> Peter.
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
