[cabf_netsec] [EXTERNAL]Re: SC28 and Certificate Profile changes

[Bruce Morton]

I am thinking that the certificate profile is managed through configuration changes and not logging. I can’t change my certificate profile without a CA configuration change or a software update. What would we log in between changes?

Also, I agree that certificate profile is not a define term. I’m not sure that we can have a requirement unless we agree to the definition.

Thanks, Bruce.

From: Netsec <netsec-bounces at cabforum.org> On Behalf Of Ben Wilson via Netsec
Sent: Wednesday, June 3, 2020 12:53 PM
To: Neil Dunbar <ndunbar at trustcorsystems.com>; CABF Network Security List <netsec at cabforum.org>
Subject: [EXTERNAL]Re: [cabf_netsec] SC28 and Certificate Profile changes

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
You're right - "certificate profiles" are too vague to be of use unless they're defined as the code used to create the certificates. The problem arises because the "profile" is usually embodied in a series of documents and code that makes its way through a human approval process and one little oversight goes unnoticed. I've seen it happen 10 times or more in my career.  Not sure how to define it, though.

On Wed, Jun 3, 2020 at 9:38 AM Neil Dunbar via Netsec <netsec at cabforum.org<mailto:netsec at cabforum.org>> wrote:


On 03/06/2020 13:31, David Kluge wrote:
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?


Since Certificate Profiles are _usually_ tied to a particular CA, I would say that creation, modification and deletion of certificate profiles could be added to 5.4.1 (1); that would imply a responsibility to hold onto all profiles attached to an Issuing CA for the life of the CA Private Key/Certificates plus 2 years.

Something like

"x. Creation, modification and deletion of certificate profiles which define certificates which are signed by the CA Private Key"

"y. Creation, modification and deletion of CRL profiles which define CRLs which are signed by the CA Private Key"

It's probably the sort of thing which lives in a source code control system ; and it's a pretty small data set, IMO. So it's not like we're asking for indexing and reporting of totally unstructured data.

Does this make sense? I wouldn't want to add anything to the CA Key/Certificate Lifecycle section except things which are intimately tied to the CA Key/Certificate itself.

Couple of downsides:

What is a "certificate profile"? It's not a defined term. We have an intuitive notion of what it means, but is that good enough? Probably - since we also say things like "security profiles".

It is possible for a certificate profile to be shared across issuing CAs; what would be the retention of that? I guess that we could just constrain it to be the pair (CA Key, Certificate Profile), so that if it were shared, it would be the longest lived of the CA Private Keys.

Any better constructions?

Neil
_______________________________________________
Netsec mailing list
Netsec at cabforum.org<mailto: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/20200603/4e1879b5/attachment.html>