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

Bruce Morton Bruce.Morton at entrustdatacard.com
Wed Jun 3 13:16:34 MST 2020


I am not trying to give up, I am just trying to understand what needs to be logged.

So are you saying that we have to log when “some human reviews those changes and declares all possible values in the space of its expression to be compliant with the requirements to which the CA is bound.”

I was thinking that when some human did that, then this was just a step in a configuration change management process and not part of a logging process.

Thanks, Bruce.

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


I guess it depends what you mean by "software update" - for instance, if I want to change my policy OID which gets embedded into my certificates (because my CPS has changed, for instance), that's probably a configuration change as you say; not necessarily a software update, unless you mean "ask the software to re-read its configuration database", in which case, I agree with you.

And I'll stand up and say that _I_ have been the cause of a cert profile misconfiguration which resulted in a policy change at TrustCor. Indeed it was one little oversight, but you are either compliant with the plethora of restrictions or you are not.

But, since we at least have an intuitive notion of "what is a certificate profile", perhaps we need to get that intuitive knowledge into the open?

My notion of a certificate profile: the template of parameters which define and constrain -

  *   the construction of the subject DN in a certificate
  *   the allowable issuing CAs for a certificate (which then controls the issuer DN, the Authority Key Identifier, the signature algorithm over the tbsCertificate etc)
  *   the maximum validity period for the certificate
  *   the allowable algorithms and sizes for the public key
  *   those extensions which must be embedded into the certificate and the allowable values for each one
  *   (possibly) the private key duration

So, in my (narrow) world view, the certificate generation code is there to interpret the template, instantiate concrete values into the allowable variables and then produce the certificate through some workflow.

It is thus incumbent, that when a profile changes, some human reviews those changes and declares all possible values in the space of its expression to be compliant with the requirements to which the CA is bound.

I am now wholly confident that wiser heads than mine will say "No, it's also X, Y and Z, and it's not A, B and C".

So - have at it. I'm totally fine with declaring that we can't come up with a clear expression of "certificate profile", but I would at least like to have a crack before I give up!

Cheers,

Neil
On 03/06/2020 19:46, Bruce Morton wrote:
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><mailto: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><mailto:ndunbar at trustcorsystems.com>; CABF Network Security List <netsec at cabforum.org><mailto: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/cd6bada6/attachment-0001.html>


More information about the Netsec mailing list