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.
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).
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)".
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.
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.
Dimitris.
On 8/9/2016 9:02 μμ, Jody Cloutier wrote:
Thanks, Ryan.
Dimitris, See http://aka.ms/ c(5). “The CA must not use the root
certificate to issue end-entity certificates.”.
J
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Ryan Sleevi
*Sent:* Thursday, September 8, 2016 10:56 AM
*To:* Dimitris Zacharopoulos <[email protected]>
*Cc:* [email protected]; [email protected]
*Subject:* Re: [cabfpub] Questions regarding timestamping certificates
Dimitris,
Thanks for raising this. I'd be especially curious to get Jody's take,
and I'd suggest you see if https://aka.ms/rootcert has anything to say
on this matter.
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.
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.
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.
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.
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.
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)
Does that help offer a 'vendor' perspective?
On Thu, Sep 8, 2016 at 9:15 AM, Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> wrote:
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?
Dimitris.
On 8/9/2016 6:14 μμ, Inigo Barreira wrote:
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.
*De:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *En nombre de *Dimitris
Zacharopoulos
*Enviado el:* jueves, 8 de septiembre de 2016 16:39
*Para:* Bruce Morton
*CC:* [email protected] <mailto:[email protected]>
*Asunto:* Re: [cabfpub] Questions regarding timestamping
certificates
On 8/9/2016 4:59 μμ, Bruce Morton wrote:
Hi Dimitris,
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.
That was my initial reading too and thank you for confirming.
If others think that's not the case, please let us know.
You may want to get feedback directly from the vendor of the
client software which will validate the time-stamp signatures.
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 :)
Best regards,
Dimitris.
Bruce.
*From:*Dimitris Zacharopoulos [mailto:[email protected]]
*Sent:* Thursday, September 8, 2016 9:03 AM
*To:* Bruce Morton <[email protected]>
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*Subject:* Re: [cabfpub] Questions regarding timestamping
certificates
On 8/9/2016 3:07 μμ, Bruce Morton wrote:
Hi Dimitris,
I think the best document to use for Time-stamping
Authority is the Minimum Requirements for Code Signing
certificates, see
https://casecurity.org/wp-content/uploads/2016/07/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf.
Thanks, Bruce.
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).
I guess my 1st question is more focused on what is allowed
under the currently approved CA/B Forum Baseline Requirements.
Best regards,
Dimitris.
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Dimitris Zacharopoulos
*Sent:* Thursday, September 8, 2016 4:34 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* [cabfpub] Questions regarding timestamping
certificates
Hello everyone,
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".
1. 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)?
2. 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.
Thank you in advance.
Dimitris Zacharopoulos.
_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
