<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Thanks everyone for your input. To be honest, I didn't expect this
to be a controversial issue since timestamping has been around for
many years.<br>
<br>
I think Microsoft's reference c(5) is probably aligned with the BRs
(6.1.7). However, technically speaking, an OCSP responder
certificate is also an end-entity certificate but it is specifically
allowed in the BRs (same section). <br>
<br>
Currently, as written, section 6.1.7 of the BRs numbered item 3,
allows the Root Key to be used to sign "Certificates for
infrastructure purposes (e.g. administrative role certificates,
internal CA operational device certificates, and OCSP Response
verification Certificates)".<br>
<br>
I think that we can all agree that this exception is kind of vague
and should probably be narrowed down to a smaller, more specific
set. Of course, a TimeStamping Certificate is not your everyday
"Subscriber" Certificate and could be defined by some CAs as a
"Certificate for infrastructure purposes", since it is usually
operated by the CA/TSP and not some other non-TSP entity as it works
with SSL, S/MIME, Code Signing Certificates. The ETSI EN 319 421 and
the minimum requirements for Code Signing document, have very strict
controls on how to issue and maintain a Timestamping Certificate
that minimize the risk (from a risk management perspective) compared
to other end-entity (SSL, S/MIME and CodeSigning) Certificates.
Also, the CRL issuance frequency for the status of Timestamping
Certificates is aligned with the frequency of the status of
Subordinate CA Certificates so they are treated differently.<br>
<br>
We could ballot this and change 6.1.7(3) to either specifically
allow or disallow timestamping end-entity certificates to be issued
directly from a Root and -obviously- if the majority votes that
timestamping certificates must not be allowed to be issued directly
from Root Certificates, introduce a proper effective date for
enforcing this policy.<br>
<br>
<br>
Dimitris.<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/9/2016 9:02 μμ, Jody Cloutier
wrote:<br>
</div>
<blockquote
cite="mid:MWHPR03MB25739480CCEA9CCF5F455232D6FB0@MWHPR03MB2573.namprd03.prod.outlook.com"
type="cite">
<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]-->
<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
moz-do-not-send="true" 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"> <a
class="moz-txt-link-abbreviated"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a class="moz-txt-link-freetext"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Thursday, September 8, 2016 10:56 AM<br>
<b>To:</b> Dimitris Zacharopoulos <a
class="moz-txt-link-rfc2396E"
href="mailto:jimmy@it.auth.gr"><jimmy@it.auth.gr></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated"
href="mailto:Bruce.Morton@entrust.com">Bruce.Morton@entrust.com</a>;
<a class="moz-txt-link-abbreviated"
href="mailto:public@cabforum.org">public@cabforum.org</a><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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:Bruce.Morton@entrust.com"
target="_blank">
<Bruce.Morton@entrust.com></a>;
<a moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>