On Tue, Oct 01, 2024 at 12:26:08PM +0000, Sandy Balzer wrote: > Dear Ben, > > Thanks a lot for your effort which is highly appreciated. > > However we believe that there are some customers who really struggle > with automation and we believe it is important to get more insights > into what exactly their problems are.
Towards that end, what has SwissSign done to (a) confirm that first belief, and (b) gather the insights? What is SwissSign's timeline to complete those information gathering activities, and to what degree is SwissSign willing to commit to sharing the details and conclusions from that work? > Additionally, from a customer point of view (as well as the whole PKI > community) it would be important to outline the final target state > that such an interim policy change would work towards including the > time frame of the final state. I think the final state is fairly straightforward: that no revocation is delayed beyond the BR-mandated limits due to subscriber action (or inaction). The desired time frame is "years ago". > From our previous delayed revocation, we know that: > > * public trust certificates are used where private PKIs may be > better suited > > * customer internal approval processes take more time than a > 24h/5d revocation timeline allows > > * certificate pinning is still used (although it is generally > known that it's a bad idea) that requires update to applications > > * update of certificates in Apps that require re-publishing in > App-Stores which may not be possible within the required timeline > > * customer awareness of their contractually agreed requirement to > be able to deal with 24h/5d revocation is low This is a solid distillation of the problems that subscribers have caused for themselves (and their CAs). It would be useful, I think, for all CAs, particularly those with extended issuance periods and legacy issuance mechanisms (which are those most likely to have a large number of customers with these problems) to consider these issues and determine what work they will do to mitigate or eliminate them. If I were Mozilla, I might even put them in a future CA questionnaire... > All these are not problems that a CA alone can fix. All we can do is > educate, support to the best of our abilities and revoke on time. While a CA alone may not be able to fix these problems, from the perspective of the WebPKI community, these are all problems that are the CA's responsibility. The CA is the interface between the WebPKI and its subscribers, and thus is the best-placed party to influence the behaviour of its subscribers. - 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/aa38eb4e-60fe-47c4-903e-bd2d8e9d8b26%40mtasv.net.
