[Cscwg-public] Subject name stability

[Mike Hearn]

Hi,

No interest in this issue? If not, how come? It seems pretty central to
code signing as a technology.

On Mon, 8 May 2023 at 12:55, Mike Hearn via Cscwg-public <
cscwg-public at cabforum.org> wrote:

> 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
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230522/d800c194/attachment.html>