Hi Matt, You answered my thoughts on BR applicability in your last paragraph. I don't mean to say there's a direct element as written being broken, but the combination of revocation misuse & misleading certificate lifespan makes it hard to take a certificate at face-value.
- Wayne On Monday, August 5, 2024 at 3:31:50 AM UTC+1 Matt Palmer wrote: > On Fri, Aug 02, 2024 at 05:43:35AM -0700, Wayne wrote: > > So in summary: the allegations are true, and there's a direct business > > model created to allow this to exist alongside the traditional > certificates > > system? > > > > Are any other CAs going to be forthcoming on a similar approach, as what > is > > being described is renting certificate lifespan, with hidden cancellation > > fees. I don't see how this is compatible with the baseline requirements, > > I'd appreciate it if you could expand on this point further, as I'm not > seeing any conflict with the BRs here -- nor do I think that the BRs > *should* make any stipulations on business models (for both legal and > practical reasons). As far as revocation reasons go, I believe the BRs > are a list of "circumstances in which you *must* revoke", they don't > mandate that certificates *not* be revoked for other reasons. > > It appears that there is a level of misunderstanding between what > Entrust was selling and what customers *thought* they were buying. To > the degree that the problem was Entrust misrepresenting its products and > services, then that will (presumably) be ironed out between Entrust and > its customers, through legal action or otherwise. To the extent that > the problem was, instead, customers failing to comprehend what Entrust > was saying, well there's plenty of precedent for *that* in the WebPKI > (amongst other places). > > We've recently seen, with the DigiCert TRO, an ugly consequence of > customers misunderstanding what was being sold, and I believe that the > customer in that instance has been generally considered (by the WebPKI > community) at least partially responsible for not taking the time to > understand what they were buying. It's difficult, therefore, to > simultaneously put the blame entirely on Entrust for their customers' > misunderstanding of the ramifications of what they were buying while > criticising Alegeus for their similar misunderstanding. > > > It is disconcerting that this is phrased as standard operating procedure, > > and nothing to worry about. > > On a personal level, I don't like Entrust's business model here, but > there are *lots* of things I don't like, and not everything I dislike is > something that has to be banned (much as I might like it to be). > > I will, however, amplify Watson Ladd's comment elsewhere in this thread, > which I believe is extremely pertinent: > > "Let me get this straight: you will not revoke on time when presented > with a BR violation, making the excuse customers will be > inconvenienced, run criticial systems yadda yadda. You will revoke > gratuitously come contract renewal time, and none of the reasons > listed before matter." > > This, to me, is an important thing to bear in mind. It may not be a BR > violation to revoke for business reasons, but using it as a sales tool > against potentially the same category of system that was used as a > defence against the consequences of Entrust's own actions is... not > great, at the very least. > > - Matt > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/94a76d41-7cff-45ab-a236-6ac349bf00a6n%40mozilla.org.
