<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.</p>
<p>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?</p>
<p>My notion of a certificate profile: the template of parameters
which define and constrain -</p>
<ul>
<li>the construction of the subject DN in a certificate</li>
<li>the allowable issuing CAs for a certificate (which then
controls the issuer DN, the Authority Key Identifier, the
signature algorithm over the tbsCertificate etc)</li>
<li>the maximum validity period for the certificate <br>
</li>
<li>the allowable algorithms and sizes for the public key</li>
<li>those extensions which must be embedded into the certificate
and the allowable values for each one</li>
<li>(possibly) the private key duration</li>
</ul>
<p>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.</p>
<p>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.<br>
</p>
<p>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".</p>
<p>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!</p>
<p>Cheers,</p>
<p>Neil<br>
</p>
<div class="moz-cite-prefix">On 03/06/2020 19:46, Bruce Morton
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SN6PR11MB26565AAD9BA131EB712E336B86880@SN6PR11MB2656.namprd11.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Bruce.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Netsec
<a class="moz-txt-link-rfc2396E" href="mailto:netsec-bounces@cabforum.org"><netsec-bounces@cabforum.org></a> <b>On Behalf Of
</b>Ben Wilson via Netsec<br>
<b>Sent:</b> Wednesday, June 3, 2020 12:53 PM<br>
<b>To:</b> Neil Dunbar <a class="moz-txt-link-rfc2396E" href="mailto:ndunbar@trustcorsystems.com"><ndunbar@trustcorsystems.com></a>;
CABF Network Security List <a class="moz-txt-link-rfc2396E" href="mailto:netsec@cabforum.org"><netsec@cabforum.org></a><br>
<b>Subject:</b> [EXTERNAL]Re: [cabf_netsec] SC28 and
Certificate Profile changes<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><strong><span
style="font-family:"Calibri",sans-serif;color:red">WARNING:</span></strong>
This email originated outside of Entrust Datacard.<br>
<strong><span
style="font-family:"Calibri",sans-serif;color:red">DO
NOT CLICK</span></strong> links or attachments unless you
trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="100%" size="2" align="center">
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jun 3, 2020 at 9:38 AM Neil
Dunbar via Netsec <<a href="mailto:netsec@cabforum.org"
moz-do-not-send="true">netsec@cabforum.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 03/06/2020 13:31, David Kluge
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">I agree that retaining
certificate profiles can be useful and the data
volume involved is rather small.
<o:p></o:p></p>
<div>
<p class="MsoNormal">We could just add a separate
paragraph to section 5.4.1 and define what profile
related information to retain and for how long?
<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<p>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.<o:p></o:p></p>
<p>Something like<o:p></o:p></p>
<p>"x. Creation, modification and deletion of certificate
profiles which define certificates which are signed by
the CA Private Key"<o:p></o:p></p>
<p>"y. Creation, modification and deletion of CRL profiles
which define CRLs which are signed by the CA Private
Key"<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>Couple of downsides:<o:p></o:p></p>
<p>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".<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>Any better constructions?<o:p></o:p></p>
<p>Neil<o:p></o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
Netsec mailing list<br>
<a href="mailto:Netsec@cabforum.org" target="_blank"
moz-do-not-send="true">Netsec@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/netsec"
target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/netsec</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>