My opinion:
The CA/B Forum Baseline Requirements only apply to certificates which chain to
publicly trusted roots. This is made clear in the preamble of the document:
This document describes an integrated set of technologies, protocols,
identity-proofing, lifecycle management, and auditing requirements that are
necessary (but not sufficient) for the issuance and management of
Publicly-Trusted Certificates; Certificates that are trusted by virtue of the
fact that their corresponding Root Certificate is distributed in
widely-available application software.
The BRs do not apply to certificate issuance from non publicly trusted
hierarchies.
Dean CoclinCA/B Forum Vice-Chair
-----Original Message-----
From: Sándor dr. Szőke via dev-security-policy
<dev-security-policy@lists.mozilla.org>
To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Sent: Thu, Dec 13, 2018 1:36 pm
Subject: Maximal validity of the test TLS certificate issued by a private PKI
system
It is not absolutely clear for us how to manage the test certificates which
were issued by a CA where there are no certificate chains to a root certificate
subject to the Baseline Requirements (for example an independent test CA
hierarchy).
The BR wording is as follows:
Test Certificate: A Certificate with a maximum validity period of 30 days and
which: (i) includes a critical
extension with the specified Test Certificate CABF OID (2.23.140.2.1), or (ii)
is issued under a CA where there
are no certificate paths/chains to a root certificate subject to these
Requirements.
I can interpret the definition in two different ways:
1. by using the listing as a parenthesis, so
Test Certificate:
A Certificate
{with a maximum validity period of 30 days}
AND
which:
{
(i) includes a critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1),
OR
(ii) is issued under a CA where there are no certificate paths/chains to a root
certificate subject to these Requirements.
}
So it means that any test certificate shall have the validity max. 30 days,
AND
we have two possibilities:
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate shall
include the critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1)
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
further requirement.
Question:
if this interpretation is correct, then why do we have a requirement to limit
the validity period of the test certificate for 30 days, if the issuer CA is
out of the scope of the BR?
------------------------
2. by thinking as an engineer, where the AND operation is higher level than the
OR, the separation looks like this:
Test Certificate:
A Certificate
{
with a maximum validity period of 30 days
AND
which:
(i) includes a critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1),
}
OR
{
(ii) is issued under a CA where there are no certificate paths/chains to a root
certificate subject to these Requirements.
}
So it means, that
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate shall
include the critical extension with the specified Test Certificate CABF OID
(2.23.140.2.1) AND the validity period of the test certificate is maximum 30
days
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
any further requirement
In this interpretation the wording seems to be strange, but the requirement
seems to be more realistic and clear.
Which interpretation is correct?
Is it allowed to issue test TLS certificates in an independent test system with
more than 30 days validity?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
