<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
Hello Mike,<br>
<br>
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".<br>
<br>
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.<br>
<br>
As a matter of following the <a moz-do-not-send="true"
href="https://cabforum.org/2019/03/09/ballot-forum-8-establishment-of-a-code-signing-working-group/#Code-Signing-Certificate-Working-Group-Charter">WG
Charter</a>, the CSCWG doesn't really discuss how code signing
certificates are "consumed" by Certificate Consumers but any
feedback is useful.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 22/5/2023 4:18 μ.μ., Dean Coclin via
Cscwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000188439cd23e-17ac32ec-3ff2-427e-80ca-f7be814fa1ef-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">Hello Mike,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">This item
was discussed at last week’s meeting. A response is being
prepared and will be sent to you soon.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Dean Coclin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">CSCWG Chair<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Cscwg-public
<a class="moz-txt-link-rfc2396E" href="mailto:cscwg-public-bounces@cabforum.org"><cscwg-public-bounces@cabforum.org></a> <b>On Behalf Of </b>Mike
Hearn via Cscwg-public<br>
<b>Sent:</b> Monday, May 22, 2023 7:59 AM<br>
<b>To:</b> Mike Hearn <a class="moz-txt-link-rfc2396E" href="mailto:mike@hydraulic.software"><mike@hydraulic.software></a>;
<a class="moz-txt-link-abbreviated" href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br>
<b>Subject:</b> Re: [Cscwg-public] Subject name stability<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">No interest in this issue? If not, how
come? It seems pretty central to code signing as a
technology.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, 8 May 2023 at 12:55, Mike Hearn
via Cscwg-public <<a
href="mailto:cscwg-public@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">cscwg-public@cabforum.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hello,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">By way of introduction, I run a
company that makes <a
href="https://url.avanan.click/v2/___https:/hydraulic.software/___.YXAzOmRpZ2ljZXJ0OmE6bzpiYTljNzM5OGZmOWQ0MTFmNDA4ODAzNTUyMmNiZmY3MTo2OjM5ZGE6YTY3Mzg4ZjIxMmIxOTAzNTRhYTNjZjBkZGUwOGI4OWU5NWViODZhZmE5MzAwYTRkM2Y0YWM4ZGY3MjNiNGI3MDpoOkY"
target="_blank" title="Protected by Avanan:
https://hydraulic.software/" moz-do-not-send="true">a
tool to simplify desktop app distribution</a>, 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo1">Software updates silently break. This
is a critical issue.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo1">Apps lose access to any {files, keys,
permissions, etc} linked to their subject name.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo1">Publisher reputations appear to reset
(probably? it's a bit unclear what happens in this
case).<o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are a couple of possible
answers to this situation:<o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0
level1 lfo2">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.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo2">Address it via policy changes.<o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l2
level1 lfo3">Subject name stability is a valuable
and desirable service for any non-trivial use of a
PKI.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l2
level1 lfo3">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.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l2
level1 lfo3">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.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2
level1 lfo3">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.<o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-mike<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Cscwg-public mailing list<br>
<a href="mailto:Cscwg-public@cabforum.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Cscwg-public@cabforum.org</a><br>
<a
href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/cscwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzpiYTljNzM5OGZmOWQ0MTFmNDA4ODAzNTUyMmNiZmY3MTo2OmIyNjk6N2QzNjU0M2IxMThlZWU0YTVlZmFkYjI5MmI0OWRmODMzOGM1MTBlOTIzZDViZDRkMzZjM2VkNjQ1MWU3OGIwYzpoOkY"
target="_blank" title="Protected by Avanan:
https://lists.cabforum.org/mailman/listinfo/cscwg-public"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>