[cabf_netsec] SC28 and Certificate Profile changes

[David Kluge]

I agree that retaining certificate profiles can be useful and the data
volume involved is rather small.
We could just add a separate paragraph to section 5.4.1 and define what
profile related information to retain and for how long?

On Tue, Jun 2, 2020 at 8:07 PM Ben Wilson via Netsec <netsec at cabforum.org>
wrote:

> 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> wrote:
>
>> 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
>>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/netsec
>


-- 

David Kluge | Technical Program Manager | kluge at google.com |  +41 44 668 03
54
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20200603/848bec09/attachment.html>