<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1264222202;
mso-list-template-ids:-428173670;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I am not trying to give up, I am just trying to understand what needs to be logged.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.
<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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Netsec <netsec-bounces@cabforum.org> <b>On Behalf Of
</b>Neil Dunbar via Netsec<br>
<b>Sent:</b> Wednesday, June 3, 2020 4:06 PM<br>
<b>To:</b> CABF Network Security List <netsec@cabforum.org><br>
<b>Subject:</b> Re: [cabf_netsec] [EXTERNAL]Re: SC28 and Certificate Profile changes<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<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.<o:p></o:p></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.<o:p></o:p></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?<o:p></o:p></p>
<p>My notion of a certificate profile: the template of parameters which define and constrain -<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
the construction of the subject DN in a certificate<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
the allowable issuing CAs for a certificate (which then controls the issuer DN, the Authority Key Identifier, the signature algorithm over the tbsCertificate etc)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
the maximum validity period for the certificate <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
the allowable algorithms and sizes for the public key<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
those extensions which must be embedded into the certificate and the allowable values for each one<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
(possibly) the private key duration<o:p></o:p></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.<o:p></o:p></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.<o:p></o:p></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".<o:p></o:p></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!<o:p></o:p></p>
<p>Cheers,<o:p></o:p></p>
<p>Neil<o:p></o:p></p>
<div>
<p class="MsoNormal">On 03/06/2020 19:46, Bruce Morton wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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 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 href="mailto:ndunbar@trustcorsystems.com"><ndunbar@trustcorsystems.com></a>; CABF Network Security List
<a 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" align="center" style="text-align:center">
<hr size="2" width="100%" 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">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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<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">Netsec@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/netsec" target="_blank">https://lists.cabforum.org/mailman/listinfo/netsec</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
</body>
</html>