[cabf_netsec] [EXTERNAL]Re: SC28 and Certificate Profile changes
Neil Dunbar
ndunbar at trustcorsystems.com
Wed Jun 3 13:06:16 MST 2020
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> *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/65e4cbd6/attachment.html>
More information about the Netsec
mailing list