<div dir="ltr"><div>Root Programs want to know how and why misissuances took place, and certificate profile history helps. So I'm on that side.<br></div><div><br></div><div>But the main problem I've seen is when a person uses an outdated certificate profile. Somehow an outdated profile is lying around for X type of certificate, so it has to be the right one.  ...  Only to find out later that it was supposed to have been replaced because a requirement changed since the last time it was used. It's the result of human error, lack of communication, bad tracking, etc. The way that it's supposed to be avoided is by having the person attest that they reviewed the current standards and that the reused profile is current with requirements.  </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 11:20 AM Neil Dunbar via Netsec <<a href="mailto:netsec@cabforum.org">netsec@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
<br>
While the discussion continues on the main list, Ryan S brings up an<br>
interesting question regarding Certificate Profiles. I can actually see<br>
both sides of this argument, so some NetSec flavoured discussion would<br>
be valuable to me.<br>
<br>
Should a Cert Profile (which constrains/configures certificates issued<br>
under a PKI hierarchy) be considered to belong to a CA Private Key? If<br>
so, should that actually be part of events logged, alongside certificate<br>
requests, etc?<br>
<br>
Pro retention: Knowing the history of Certificate Profile recording and<br>
changing can give useful information to Root Programs who wish to know<br>
how and why misissuances took place - not within the context of N<br>
certificates were misissued, but rather which systemic issues allowed<br>
them to be misissued, and how those profiles changed in order to<br>
remediate the damage.<br>
<br>
Against retention: the actual effects of a Certificate Profile consists<br>
in the issuance of certificates; those certificates are either properly<br>
issued, or not, at the time of certificate publication; thus from a<br>
security perspective making the profile changes part of the CA Key/Cert<br>
record actually serves no purpose.<br>
<br>
So it (to me) comes down to long term root cause analysis utility<br>
[tracking of policy and profile changes] versus actual security utility<br>
[certificate misissuance caused by a bad cert profile]. It also comes<br>
down to "useful to which audience". An auditor might well not see much<br>
point in delving into a Cert Profile's history for the last 10 years,<br>
and a Root Program might want to know it, but only in rare circumstances<br>
[discuss!]<br>
<br>
I'm keen to avoid the "keep it just in case it could be interesting one<br>
day" school of thought, but the thoughts of those on the list would be<br>
very welcome.<br>
<br>
Neil<br>
<br>
<br>
_______________________________________________<br>
Netsec mailing list<br>
<a href="mailto:Netsec@cabforum.org" target="_blank">Netsec@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/netsec" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/netsec</a><br>
</blockquote></div>