[Cscwg-public] Subject name stability

[Mike Hearn]

Hi Dean,

Although this is the answer I expected, please note that the issue isn't
MSIX specific. *Any* system that associates data with a certificate
identity will face this problem. MSIX is the motivating example in
my case, but other cases may exist e.g. blacklisting of organizations for
anti-malware purposes. With neither pre-canned implementations nor guidance
to assist developers with the identity migration challenge, the few
remaining systems that do consume code signing certificates will continue
to yield poor user/developer experiences when entirely
foreseeable circumstances arise. Chances to sell more certificates will be
missed.

thanks,
-mike

On Wed, 31 May 2023 at 17:40, Dean Coclin <dean.coclin at digicert.com> wrote:

> Hello Mike,
>
> Please see response below, developed by the working group:
>
>
>
> *The resulting behaviors of  an implementation of leveraging authenticated
> values in a publicly trusted code signing certificate are the
> responsibilities of the implementation owner, not the CSBRs. *
>
> The subject name values of a code signing certificate must be
> representative of the validated identity information as outlined in the
> CSBRs and the IETF standards for x.509, and not be manipulated in a way
> that caters to a specific implementation of how one is leveraging x.509
> certificate data. The 3 issues called out here by Mike are all specific to
> MSIX and not about the general usage of x.509 code signing certificates.
> Any resolution to this complication with how authenticated values of a code
> signing certificate must be discussed with the implementation owner, and in
> this case it is Microsoft’s owners of MSIX. Organization changes such an HQ
> relocation is something that a CA will handle in the renewal of a
> certificate and the associated SubjectDN values will represent that
> location of the new HQ and not the old HQ. Again, the resulting impacts to
> how certificates are consumed is not the responsibility of the CA or the
> CSCWG, but the responsibility of the implementation owners.
>
>
>
> On the sub topic of CA practices on the inclusion of SubjectDN values
> included based on CSBRs requirements is the CA’s choice. Some of the
> allowable fields are not mandated for inclusion and the ultimate decision
> for what is included is up to the CA issuing the certificate provided those
> practices are in compliance with the CSBRs. The allowable fields provide
> flexibility to the CAs to do what is right for their business practices
> (e.g. inclusion of OU field comes with additional requirements and costs a
> CA may choose not to do as part of their business and thus not offer this
> field in certificates). I see no justification for a change in the CSBRs at
> this time for SubjectDN value requirements.
>
>
>
> Please take up this issue with the implementation owners that have
> dependencies on authenticated values in an x.509 certificate that do change
> over the life of an organization or individual.
>
>
>
>
>
> *Dean Coclin *
>
> CSCWG Chair
>
>
>
>
>
>
>
>
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of *Mike
> Hearn via Cscwg-public
> *Sent:* Monday, May 8, 2023 6:56 AM
> *To:* cscwg-public at cabforum.org
> *Subject:* [Cscwg-public] Subject name stability
>
>
>
> 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://url.avanan.click/v2/___https:/hydraulic.software/___.YXAzOmRpZ2ljZXJ0OmE6bzo1ZmI4MjgwZDBhYjYzMWVkN2JmMzdjMmY4OTdlNzk1Yzo2OjUwNDg6Y2JjZDEzZTgzNDliNGU0YjM5NWVmYWFkYzljNzliOGIzNmMyYmNhNWVmNDY5YTg3NzYyZDQ5NWUxOTA1ZmQ5NTpoOkY>,
> 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/20230531/e69f1ab4/attachment.html>