[Cscwg-public] Subject name stability
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri May 26 08:32:49 UTC 2023
On 26/5/2023 11:26 π.μ., Martijn Katerbarg wrote:
>
> Dimitris,
>
> >If this is the subjectDN field of the code signing certificates, if
> the CA properly validates the subject entity, the values should be
> exactly the same between different CAs. If you have examples where one
> CA includes a certain entity's subjectDN and another CA includes a
> different subjectDN for the same entity, please share this information.
>
> Not necessarily. One CA may have chosen to include
> subject:streetAddress and subject:postalCode, where a different CA may
> not. Some CAs may use subject:localityName, where others use
> subject:stateOrProvinceName. There can be a fair bit of flexibility in
> the subjectDN.
>
Hi Martijn,
IMO this is up to the Applicant to decide, not the CA. The CA is
providing the options. If the Applicant doesn't want the streetAddress
to be included in the subjectDN, they will make sure not to request that
field.
Similarly for the ST or L. The requirements say ST or L or both must be
present in the subjectDN, so I believe this option is also up to the
Applicant to decide.
Thanks,
Dimitris.
> Regards,
>
> Martijn
>
> *From:*Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of
> *Dimitris Zacharopoulos (HARICA) via Cscwg-public
> *Sent:* Friday, 26 May 2023 10:17
> *To:* cscwg-public at cabforum.org
> *Subject:* Re: [Cscwg-public] Subject name stability
>
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
> Hello Mike,
>
> I would like you to please clarify what you mean by "Subject Name".
> You later also use the acronym "SN" which I assume also points to
> "Subject Name".
>
> If this is the subjectDN field of the code signing certificates, if
> the CA properly validates the subject entity, the values should be
> exactly the same between different CAs. If you have examples where one
> CA includes a certain entity's subjectDN and another CA includes a
> different subjectDN for the same entity, please share this information.
>
> As a matter of following the WG Charter
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2F2019%2F03%2F09%2Fballot-forum-8-establishment-of-a-code-signing-working-group%2F%23Code-Signing-Certificate-Working-Group-Charter&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C78d68bff3a3e40ed5bd608db5dc1844d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638206857962323215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i09vFp7EGZ9OlDiQZfZTOlAK3pxOu598C8dk8bg7AVw%3D&reserved=0>,
> the CSCWG doesn't really discuss how code signing certificates are
> "consumed" by Certificate Consumers but any feedback is useful.
>
>
> Best regards,
> Dimitris.
>
>
> On 22/5/2023 4:18 μ.μ., Dean Coclin via Cscwg-public wrote:
>
> Hello Mike,
>
> This item was discussed at last week’s meeting. A response is
> being prepared and will be sent to you soon.
>
>
> Best regards,
>
> Dean Coclin
>
> CSCWG Chair
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org>
> <mailto:cscwg-public-bounces at cabforum.org> *On Behalf Of *Mike
> Hearn via Cscwg-public
> *Sent:* Monday, May 22, 2023 7:59 AM
> *To:* Mike Hearn <mike at hydraulic.software>
> <mailto:mike at hydraulic.software>; cscwg-public at cabforum.org
> *Subject:* Re: [Cscwg-public] Subject name stability
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl.avanan.click%2Fv2%2F___https%3A%2Fhydraulic.software%2F___.YXAzOmRpZ2ljZXJ0OmE6bzpiYTljNzM5OGZmOWQ0MTFmNDA4ODAzNTUyMmNiZmY3MTo2OjM5ZGE6YTY3Mzg4ZjIxMmIxOTAzNTRhYTNjZjBkZGUwOGI4OWU5NWViODZhZmE5MzAwYTRkM2Y0YWM4ZGY3MjNiNGI3MDpoOkY&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C78d68bff3a3e40ed5bd608db5dc1844d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638206857962323215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7qP3VZ7OlrAL6ITjonm4R8qasAIYloqn9Il5Q8xtz04%3D&reserved=0>,
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl.avanan.click%2Fv2%2F___https%3A%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzpiYTljNzM5OGZmOWQ0MTFmNDA4ODAzNTUyMmNiZmY3MTo2OmIyNjk6N2QzNjU0M2IxMThlZWU0YTVlZmFkYjI5MmI0OWRmODMzOGM1MTBlOTIzZDViZDRkMzZjM2VkNjQ1MWU3OGIwYzpoOkY&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C78d68bff3a3e40ed5bd608db5dc1844d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638206857962323215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wJTXZVFQhraV2CO3837RGH62DpiyHK5qg4ADvZ0j9bc%3D&reserved=0>
>
>
>
> _______________________________________________
>
> Cscwg-public mailing list
>
> Cscwg-public at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/cscwg-public <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C78d68bff3a3e40ed5bd608db5dc1844d%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638206857962323215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nhUiNCMeR%2FItQZ%2FlGO5ypm7sQqlHPLv7%2Fi%2BDedZ%2Fl30%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230526/2100a5b7/attachment-0001.html>
More information about the Cscwg-public
mailing list