Sean Gallagher wrote: > On 11/07/2023 5:33 pm, novoMedia via dovecot wrote: > > I am not exactly sure what hosts have to do with this. The must-staple > > extension is a (cryptographically ensured) flag that is 'ingrained' > > into a certificate. It tells a client to only accept the certificate > > if a valid and recent OCSP response was stapled along with the > > certificate. > > It wasn't clear that you were talking about using the same certificate > across many services on a single host. That's fair but I will point out > there is nothing stopping you from using several certificates for the > same server. One with the extension and one without. Every application > on that server can have a certificate tailored to it's own needs if need > be. And with free CA's available, it's actually pretty easy. It's really > an argument about manageability. It would be _nice_ to be able to use > one certificate for all services on a server. And so it would be _nice_ > if Dovecot supported OCSP stapling.
Right that would be a possibility. But I don't see the security advantage of must-staple if there's a 'sister-certificate' without must-staple right beside it. In case of an intrusion, the attacker would just grab the non-must-staple one. Before I'd do that, I would just plainly disable must-staple and keep OCSP optional. But yes, technically you are right. > > Counter question: Why should John Doe connecting over HTTPS, doing - > > let's say - sensitive banking applications, be deprived of the > > security advantages of the 'must-staple' extension? Just because > > Thunderbird or Outlook does not support it? What does John Doe using > > Chrome have to do with Thunderbird/Outlook? > > Seems like a confused argument. Why would John Doe's bank and John Doe's > email provider be forced to use the same certificate for their > respective servers. The banking example was just made-up. It wasn't meant to be taken literally but only to get a point across. > > I'd argue that a single scientific paper (from admittedly reputable > > universities) is hardly an industry poised to move back. In all > > honesty, this looks like an attempt to clout OCSP with undeserved > > doubts - for reasons unknown to me. But I think it's fair to say that > > Dovecot users finally deserve what is common practice in Nginx/HTTP > > and Exim/SMTP since ~8 Years(!) already. > > I've go no axe to grind here, just calling it as I see it.. FireFox and > Chrome have already moved on this. Both browsers already support a CRL > 2.0 type mechanism and have stated they intend to stop checking OCSP. I > don't know what the other browsers are doing, but this seems to be the > direction things are heading in. If the web doesn't want OCSP any more, > will it stay around. I dunno. > > If my response came across as confrontational I apologize in advance. > > It is not my intention to seek contention. I only want to find > > solutions. But after Years of waiting for this feature and reading > > arguments that mostly contradict all of my real life experiences, I > > feel compelled to speak as clearly and concisely as possible. > > No confrontation here. I support you with your quest. It's just not > something I think I would ever use or need - so I didn't vote for it. I > also didn't vote against it - it would be nice to have,. > Sean. No worries Sean, thank you for your participation in this conversation. I am sure it made my standpoint to future participants more clear. Thanks for that. Best regards, novoMedia _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
