<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:x="urn:schemas-microsoft-com:office:excel" 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)">
<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:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Segoe UI";
        panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",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:12.0pt;
        font-family:"Times New Roman",serif;}
span.hoenzb
        {mso-style-name:hoenzb;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Segoe UI",sans-serif;
        color:#1F497D;
        font-weight:normal;
        font-style:normal;
        text-decoration:none none;}
.MsoChpDefault
        {mso-style-type:export-only;}
@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:836848570;
        mso-list-template-ids:-1539566132;}
@list l0:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
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"><span style="font-size:11.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D">Thanks, Ryan.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D">Dimitris, See
<a href="http://aka.ms/">http://aka.ms/</a> c(5). “The CA must not use the root certificate to issue end-entity certificates.”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D">J<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Thursday, September 8, 2016 10:56 AM<br>
<b>To:</b> Dimitris Zacharopoulos <jimmy@it.auth.gr><br>
<b>Cc:</b> Bruce.Morton@entrust.com; public@cabforum.org<br>
<b>Subject:</b> Re: [cabfpub] Questions regarding timestamping certificates<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Dimitris,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for raising this. I'd be especially curious to get Jody's take, and I'd suggest you see if <a href="https://aka.ms/rootcert">https://aka.ms/rootcert</a> has anything to say on this matter.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As it stands, I'm loathe to suggest that it would be acceptable, simply because of EKU, to suggest that direct root issuance is safe or acceptable. As you know, the sub-CA approach ensures a proper risk-limiting scope; that is, we want
 to ensure the sub-CA is created "safely", and thus not have to worry about anything that the sub-CA itself signs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ultimately, it's about risk management. Let's assume we said that the mere presence of the id-kp-timeStamping EKU was sufficient to make the "EE issued by Root" safe, and thus out of scope of the BRs. Would it be acceptable for that Root
 to sign the EE with SHA-1, since it's Out of Scope? Obviously, no - as the risk with SHA-1 would be an attacker could collide with an attacker-controlled cert that wasn't id-kp-timeStamping limited. However, if it was an id-kp-timeStamping sub-CA, then that
 sub-CA could issue however many certificates were desired, and the risk of any SHA-1 collisions under that sub-CA would be limited to affecting the timestamping services, thus minimizing the risk to most (but not all) browser vendors.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Similarly, if we accept that it was sufficient, we'd run the risk that the Root's CRL could potentially grow. That is, imagine the impact to clients if there was 1 TLS sub-CA, and 100,000 id-kp-whatever EE certs, and the 100,000 certs needed
 to be revoked. TLS clients wanting to check if the sub-CA was revoked would also need to download the CRL with the 100,000 other revocations, potentially impacting performance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We unquestionably know that the root itself needs to comply with the BRs, and so I believe the MUST NOT absolutely applies, regardless of what you're signing. If you issue a sub-CA with id-kp-timestamping from this root, then the goal is
 that the sub-CA's profile fits the acceptable set (of what the Root is allowed to sign; in particular, the choice of algorithm), the Root's CRL matches the CRL policies, but that the sub-CA itself is not bound by the BRs in what it issues or how it operates.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I agree, this is not entirely obvious from the BRs, and is the long-standing scope issue (both of the BRs and the Forum), and hopefully, as we work towards resolving the Forum structure some, we can revise the BRs as necessary to make it
 clearer the scope of common matters, and what elements are out of scope.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In this regard, I appreciate the structured approach that ETSI has taken, in that it makes a clearer distinction between policies and profiles. We want the Root to have a known set of policies, and issue certificates with a bounded set
 of profiles. However, some subordinate certificates may follow one set of policies (and issue with one set of profiles), while another subordinate certificate may follow a different set of policies and profiles. That is, we could assume the Root has a uniform
 set of Policies (that are the minimum safety net for the *union* of all subrodinates; aka the most restrictive policy wins), while Subordinates may only have to comply with one set of policies (such as TLS or code signing), if the risk is constrained to a
 specific set of profiles (such as id-kp-serverAuth vs id-kp-codeSigning)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Does that help offer a 'vendor' perspective?<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Sep 8, 2016 at 9:15 AM, Dimitris Zacharopoulos <<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>> wrote:<o:p></o:p></p>
<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 class="MsoNormal"><br>
Yes, I was wondering if this is in fact allowed by the BRs. In a case where you have a Root that doesn't have the SSL trust-bits, I am sure you can do that. But what happens if your Root is included in the browsers with the SSL trust-bits set?<span style="color:#888888"><br>
<br>
<span class="hoenzb">Dimitris.</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 8/9/2016 6:14 μμ, Inigo Barreira wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Well, it depends. There are some software vendors that “request” to have the TSA signed by a known
 certificate, and as they only trust on root certificate, usually to get your timestamps “recognized” you have to sign the TSA with the CA root cert just in case.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">De:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">
<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org" target="_blank">mailto:public-bounces@cabforum.org</a>]
<b>En nombre de </b>Dimitris Zacharopoulos<br>
<b>Enviado el:</b> jueves, 8 de septiembre de 2016 16:39<br>
<b>Para:</b> Bruce Morton<br>
<b>CC:</b> <a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a><br>
<b>Asunto:</b> Re: [cabfpub] Questions regarding timestamping certificates</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 8/9/2016 4:59 μμ, Bruce Morton wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi Dimitris,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I don’t think that the spirit of BR 6.1.7 would be for a root CA to issue a certificate for a TSA.
 Also, the members of the Code Signing Working Group have recommended that there be a separate CA for issuing time-stamping certificates which is defined in Appendix B (4) of the Minimum Requirements for Code Signing certificates.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
That was my initial reading too and thank you for confirming. If others think that's not the case, please let us know.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">You may want to get feedback directly from the vendor of the client software which will validate the
 time-stamp signatures.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
I don't think that will  be necessary because if the standards require a 2 level certificate chain verification, the client software must support it :)<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Bruce.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Dimitris Zacharopoulos [<a href="mailto:jimmy@it.auth.gr" target="_blank">mailto:jimmy@it.auth.gr</a>]
<br>
<b>Sent:</b> Thursday, September 8, 2016 9:03 AM<br>
<b>To:</b> Bruce Morton <a href="mailto:Bruce.Morton@entrust.com" target="_blank">
<Bruce.Morton@entrust.com></a>; <a href="mailto:public@cabforum.org" target="_blank">
public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] Questions regarding timestamping certificates</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 8/9/2016 3:07 μμ, Bruce Morton wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi Dimitris,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think the best document to use for Time-stamping Authority is the Minimum Requirements for Code Signing
 certificates, see <a href="https://casecurity.org/wp-content/uploads/2016/07/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf" target="_blank">
https://casecurity.org/wp-content/uploads/2016/07/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf</a>.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks, Bruce.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
Thank you Bruce, you helped me find answers related to my second question. I am not 100% sure if it answers my first question. The minimum requirements for code signing document, describes a scenario where there are explicit Subordinate CA Certificates for
 TimeStamping but there is no requirement that forbids end-entity certificates to be issued directly from the Root (at least not one I could spot straight away).
<br>
<br>
I guess my 1st question is more focused on what is allowed under the currently approved CA/B Forum Baseline Requirements.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org" target="_blank">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Dimitris Zacharopoulos<br>
<b>Sent:</b> Thursday, September 8, 2016 4:34 AM<br>
<b>To:</b> <a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a><br>
<b>Subject:</b> [cabfpub] Questions regarding timestamping certificates</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Hello everyone,<br>
<br>
We are setting up a new Timestamping Authority and we are looking for specific rules that apply to certificates and subCA Certificates related to timestamping. While reading various standards and the CA/B Forum documents, and after looking at various existing
 implementations of publicly-trusted CAs, I have some questions and would appreciate any feedback from the forum. Although the BRs apply to SSL certificates, some Root Certificates might be used for both SSL and timestamping services. So the questions that
 follow, apply to CAs that use the same Root Certificate for both SSL and timestamping purposes. Of course, the EV CodeSigning requirements also define some rules for "EV Timestamp Authorities".<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys MUST NOT be used to sign end-entity certificates with some exceptions. This exception list does not specifically mention end-entity certificates with EKU id-kp-timeStamping. Are
 Root CAs allowed to directly issue end-entity certificates for timestamping authorities (end-entity certificates with EKU only id-kp-timeStamping)?<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Section 4.9.7 describes the CRL issuance frequency for Subscriber and Subordinate CA Certificates. If there is a Subordinate CA Certificate constrained with EKU id-kp-timeStamping, is an end-entity certificate (with only id-kp-timeStamping) issued from that
 subCA considered a "Subscriber" Certificate? Should this subCA issue CRLs every 7 days or every 12 months? My understanding (according to section 1.1 of the BRs) is that the end-entity certificates from that subCA are not required to comply with the CA/B Forum
 BRs. This should allow the CA to choose the CRL issuance (from that restricted subCA), to exceed the 7-day requirement.<o:p></o:p></li></ol>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
Thank you in advance.<br>
<br>
<br>
Dimitris Zacharopoulos.<br>
<br>
<br>
<br>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>