<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 9/9/2016 10:13 πμ, Inigo Barreira
wrote:<br>
</div>
<blockquote
cite="mid:E677B1B22533A54B94F55AD3825E190BFECBBD@mx3.startssl.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texto de globo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EstiloCorreo19
{mso-style-type:personal;
font-family:"Segoe UI","sans-serif";
color:#1F497D;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
span.EstiloCorreo20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1167790363;
mso-list-template-ids:-1129689518;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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:"Calibri","sans-serif";color:#1F497D">In
the ETSI standards this has been “divided” to distinguish
between a certificate and a timestamp token and/or unit,
considering them “differently” (in fact there are different
standards for each, 411-x is for issuing certificates and
421 is for timestamping policies).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Basically
the CABF docs are for issuing SSL certs with additional
“features” that affect the whole ecosystem, but always based
on this type of certificates. There´s also the code signing
which is not of “such” importance because of the numbers and
platforms in which the TSA is mentioned.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So,
if we´re reforming the fórum, there are some standards out
there to be used, … instead of updating/modifying the BRs or
EVGs, I´d rather go for an independent document, like in
ETSI, in where all the matters related to timestamping be
addressed in one document and not surfing or digging in many
of them. IMHO, I´d be easier to mantain, address, make
Standards bodies life easier, etc. But the issue will remain
if some software vendors still request it and TSPs will be
“forced” to do so in order to have their services
“recognized” in that software, though maybe is a matter of
time<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards</span></p>
</div>
</blockquote>
<br>
I proposed to update/modify the BRs because -as I clearly stated- it
involves Root Certificates that also down the chain issue SSL
Certificates. So, I believe we should try to eliminate this "open to
interpretations" clause and either allow or explicitly deny the
direct issuance of a timestamping end-entity certificate from a
Root.<br>
<br>
I'd like to discuss this on the next call and see if there is
interest to draft a ballot. In case it is decided that it should not
be allowed, I am sure there would be a fairly proper effective date
for CAs to comply.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<br>
<blockquote
cite="mid:E677B1B22533A54B94F55AD3825E190BFECBBD@mx3.startssl.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">De:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<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>En nombre de </b>Dimitris
Zacharopoulos<br>
<b>Enviado el:</b> jueves, 8 de septiembre de 2016 23:28<br>
<b>Para:</b> Jody Cloutier; Ryan Sleevi<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>Asunto:</b> Re: [cabfpub] Questions regarding
timestamping certificates<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 8/9/2016 9:02 μμ, Jody Cloutier wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,
Ryan. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.”.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">J</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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 moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
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
moz-do-not-send="true" href="mailto:jimmy@it.auth.gr"><jimmy@it.auth.gr></a><br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:Bruce.Morton@entrust.com">Bruce.Morton@entrust.com</a>;
<a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] Questions regarding
timestamping certificates</span><o:p></o:p></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:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<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>
<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 0cm 0cm 0cm">
<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>
<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>
<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 0cm 0cm 0cm">
<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>
<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 0cm 0cm 0cm">
<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>
<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>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>