Option 1 is the intended interpretation. We specified 30 days because the tokens used for domain validation (Random Number) need to have a useful life of 30 days. The 30-day usage period needed to be put into the definition of the Test Certificate, or into Method 3.2.2.4.9, and we selected the validity period as the means to convey this requirement.
Note that Method 9 has identified security issues as it relates to shared IP
addresses, so currently it's not permitted to be used (according to Google),
even though it remains in the BRs. It should be updated or removed. Method
10 has similar issues which are being mitigated with ALPN approach, but no
work has been done on Method 9 in this regard.
Doug
-----Original Message-----
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On
Behalf Of Sándor dr. Szoke via dev-security-policy
Sent: Tuesday, December 11, 2018 1:24 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
