[cabf_netsec] SC28 and Certificate Profile changes
Neil Dunbar
ndunbar at trustcorsystems.com
Wed Jun 3 08:38:21 MST 2020
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20200603/e5b1e6c2/attachment.html>
More information about the Netsec
mailing list