<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 26/5/2023 11:26 π.μ., Martijn
Katerbarg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:MW5PR17MB60126F21BB7841F288773F0DE3479@MW5PR17MB6012.namprd17.prod.outlook.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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@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;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</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 lang="EN-US">Dimitris,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:18.0pt"><span
lang="EN-US">></span>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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">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.</span></p>
</div>
</blockquote>
<br>
Hi Martijn,<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:MW5PR17MB60126F21BB7841F288773F0DE3479@MW5PR17MB6012.namprd17.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards,<br>
<br>
Martijn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="en-SE"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span
lang="EN-US"> 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>Dimitris Zacharopoulos (HARICA) via
Cscwg-public<br>
<b>Sent:</b> Friday, 26 May 2023 10:17<br>
<b>To:</b> <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></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt
2.0pt">
<p class="MsoNormal"
style="line-height:12.0pt;background:#FAFA03"><span
style="font-size:10.0pt;color:black">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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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
href="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"
moz-do-not-send="true">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>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 22/5/2023 4:18 μ.μ., Dean Coclin via
Cscwg-public wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt">Hello
Mike,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><br>
Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Dean
Coclin</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">CSCWG
Chair</span><o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Cscwg-public <a
href="mailto:cscwg-public-bounces@cabforum.org"
moz-do-not-send="true"><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
href="mailto:mike@hydraulic.software"
moz-do-not-send="true"><mike@hydraulic.software></a>;
<a href="mailto:cscwg-public@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">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:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<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://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"
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:l6
level1 lfo3">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:l6
level1 lfo3">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:l6
level1 lfo3">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:l3
level1 lfo6">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:l3
level1 lfo6">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:l4
level1 lfo9">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:l4
level1 lfo9">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:l4
level1 lfo9">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:l4
level1 lfo9">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://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"
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>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"><br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Cscwg-public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true" class="moz-txt-link-freetext">Cscwg-public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="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" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"><o:p> </o:p></span></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>