[Cscwg-public] Subject name stability

[Mike Hearn]

Hello,

I'd like to start a discussion on possible changes to the CSWG rules for
issuing certificates in the case that the subject name of the subscriber
changes.

By way of introduction, I run a company that makes a tool to simplify
desktop app distribution <https://hydraulic.software/>, which for now
focuses on out-of-store apps (support for app stores may arrive in future
versions). The tool conforms to modern standards on the Windows platform,
and thus creates MSIX packages. The MSIX system relies on code signing
identities more heavily than Windows has done in the past. Apps distributed
this way get "package identity", in which the app is treated as a coherent
whole rather than a collection of files that might or might not be in the
same directory. App files and data are namespaced under a short hash of the
X.500 name of the signing certificate. Package identity is promoted by
Microsoft as a core part of their platform strategy, and a similar system
exists on Apple platforms too.

Unfortunately using subject names in this way (as a database key) exposes
subscribers to subject name instability. If a CA changes the subject name
it issues to subscribers then Windows thinks that's a new organization and:

   1. Software updates silently break. This is a critical issue.
   2. Apps lose access to any {files, keys, permissions, etc} linked to
   their subject name.
   3. Publisher reputations appear to reset (probably? it's a bit unclear
   what happens in this case).

Microsoft has added a mechanism that lets you preserve your old "package
family name" (sn hash) when a certificate identity changes, but after some
close examination we've unfortunately had to conclude that the mechanism
isn't really usable and that's unlikely to change soon. I can go into the
gritty details if anyone is interested. As such we've started developing
workarounds, but they aren't ideal for neither developers nor end users
(e.g. the end user will sometimes see the app uninstall and reinstall
itself). Changes to the SN will therefore be somewhat disruptive and
certainly for anyone who isn't using our tools but who adopts modern
Windows packaging, SN changes can be fatal. Left unaddressed this situation
will simply cause people to avoid anything that might look at their
certificates beyond the basic "is there one" check (as indeed ~30% of
developers already ignore code signing completely).

There are a couple of possible answers to this situation:

   1. Define it as out of scope. The public PKI does not make any claims
   about identity stability and it's up to users to realize this and develop
   use-case specific plans for identity migrations. If Microsoft's mechanisms
   for this aren't workable then that's a problem for Windows users and
   developers but not the CA system.

   2. Address it via policy changes.

I've signed the IPR agreement and joined the CSWG list in order to start a
discussion about (2). I argue that there are several strong reasons to
consider policy changes here, both pragmatic and theoretical:

   1. Subject name stability is a valuable and desirable service for any
   non-trivial use of a PKI.

   2. It is in practice quite difficult to both realize the need for
   identity migration ahead of time and then implement it in a way that's both
   usable and secure. Microsoft has much greater time and resources than most
   organizations that would consume certificates but has struggled with this,
   and most systems that try to do things with certificate identity simply
   lack any method at all for migration. Pushing the problem to developers
   isn't working out well because they tend to assume at first that these
   sorts of problems are already solved by the CA/B Forum and that's why
   they're outsourcing identity verification to CAs to begin with. By the time
   they realize it's not the case it's already too late and systems are
   deployed in the wild.

   3. SN changes are often administrative. Even when justified by
   improvements in security, the fact that they can break software updates and
   cause apps to lose access to keystore entries and permissions means the
   overall security change can be negative.

   4. Non-disruptive policy changes can be made relatively quickly compared
   to the time needed to update all the Windows installs in the wild, which
   can take many years. And of course once developers make architectural
   decisions to avoid relying on SNs those decisions can last decades.

There are quite a few possible policy-based ways to improve this situation,
but the simplest is just to allow people who got certificates for a
specific SN in the past to continue buying the exact same SN in future.
That is, policy changes that affect the SN would only be mandatory for
developers who are  new to the CS ecosystem and opt-in otherwise. The SAN
field would be used to store new versions of the SN. This opens up some
other questions, for example, what happens if a company changes its name
from X to Y and then a new company forms that uses the now-free name X, but
I think these can be worked through.

There are other possible solutions. Apple run their own code signing PKI
and part of the reason is so they can allocate stable "team IDs" from a
central database. Likewise, for their store Microsoft doesn't use the
public PKI either. That strategy is a complete fix except for the need to
once again change the SNs on people, and for all CAs to collaborate on a
central database of identities. Apple also have a system called the
"designated requirement" which in theory allows for some degree of identity
migration, but it's unused in practice, probably due to complexity.

I hope this message sparks some ideas for how the CS ecosystem can be
improved in this regard. Without some approach to granting long term
identities with trustworthy stability, developers will have no choice but
to find workarounds and ultimately abandon attempts to connect more things
to subscriber identities.

thanks,
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230508/358ee4e8/attachment.html>