[cabf_netsec] SC28 and Certificate Profile changes

Ben Wilson bwilson at mozilla.com
Tue Jun 2 11:06:46 MST 2020

Root Programs want to know how and why misissuances took place, and
certificate profile history helps. So I'm on that side.

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.

On Tue, Jun 2, 2020 at 11:20 AM Neil Dunbar via Netsec <netsec at cabforum.org>

> All,
> While the discussion continues on the main list, Ryan S brings up an
> interesting question regarding Certificate Profiles. I can actually see
> both sides of this argument, so some NetSec flavoured discussion would
> be valuable to me.
> Should a Cert Profile (which constrains/configures certificates issued
> under a PKI hierarchy) be considered to belong to a CA Private Key? If
> so, should that actually be part of events logged, alongside certificate
> requests, etc?
> Pro retention: Knowing the history of Certificate Profile recording and
> changing can give useful information to Root Programs who wish to know
> how and why misissuances took place - not within the context of N
> certificates were misissued, but rather which systemic issues allowed
> them to be misissued, and how those profiles changed in order to
> remediate the damage.
> Against retention: the actual effects of a Certificate Profile consists
> in the issuance of certificates; those certificates are either properly
> issued, or not, at the time of certificate publication; thus from a
> security perspective making the profile changes part of the CA Key/Cert
> record actually serves no purpose.
> So it (to me) comes down to long term root cause analysis utility
> [tracking of policy and profile changes] versus actual security utility
> [certificate misissuance caused by a bad cert profile]. It also comes
> down to "useful to which audience". An auditor might well not see much
> point in delving into a Cert Profile's history for the last 10 years,
> and a Root Program might want to know it, but only in rare circumstances
> [discuss!]
> I'm keen to avoid the "keep it just in case it could be interesting one
> day" school of thought, but the thoughts of those on the list would be
> very welcome.
> Neil
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/netsec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20200602/bffe79e6/attachment.html>

More information about the Netsec mailing list