<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 12:23 μ.μ., Mike Hearn
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Dimitris,
<div><br>
</div>
<div>I don't recall ever being given a choice over the format of
the subjectDN when buying a code signing certificate, by any
CA. The contents of any CSR submitted are ignored and when
purchasing in an HSM there's no CSR to begin with. So in
practice the experience of subscribers is that SNs can change
when they switch CA.</div>
</div>
</blockquote>
<br>
The CSR is only served as a way to convey a public key to the CA.
The rest of the "identity" information must be validated
independently by the CA and the Applicant may identify which subject
fields should be included in the final certificate.<br>
<br>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Additionally, they can change in these cases:</div>
<div>
<ul>
<li>Company name change. Same entity legally, new SN.</li>
</ul>
</div>
</div>
</blockquote>
True, and this is important to be highlighted in the subjectDN
because the subjectDN conveys the name of the legal entity. If the
name changes, the subjectDN must change.<br>
<br>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>Company HQ is relocated.</li>
</ul>
</div>
</div>
</blockquote>
This should not result in a new certificate, as long as the address
is not part of the subjectDN.<br>
<br>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>Change in CSWG policies (e.g. postalCode being removed?)</li>
</ul>
</div>
</div>
</blockquote>
<br>
The impact to the ecosystem is usually being considered when
policies like this (deprecation of fields) is being discussed.<br>
<br>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>Cases where CSWG policies turn out to be ambiguous.</li>
</ul>
</div>
</div>
</blockquote>
<br>
I am not following this example. Can you expand a bit more?<br>
<br>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>Change in CA default policy where flexibility exists.</li>
</ul>
</div>
</div>
</blockquote>
<br>
There is always the option to move to other CAs if the CA's policies
do not meet the Subscriber's needs. All CAs must adhere to the
"Baseline Requirements" at a minimum but may not support all the
options allowed in the BRs. <br>
<br>
<blockquote type="cite"
cite="mid:CAGv+2bNAfKnR+p8az0mDs4HW+S_HaXhS88uM_MPr2rtzjVuiaQ@mail.gmail.com">
<div dir="ltr">
<div>
<div>These things can happen. Attempting to pin things down so
names never change is probably impossible. That's why it
would be good if there were ways to systematically handle
the above cases, by allowing people to re-use previously
issued names if they came from a compliant-at-the-time CA.</div>
</div>
</div>
</blockquote>
<br>
Certificate pinning is generally a practice that should be avoided,
and this has been discussed several times in the past. However, this
is not something that the CSCWG or the CA/B Forum can include in a
Guideline because it is out of scope of its Charter.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<br>
</body>
</html>