Thanks everyone for your input on this topic.
As a result of this discussion, I have concluded that this is not a clear
violation of Mozilla policy. I've closed the DFN bug as INVALID, and I am
planning to propose a ballot to the CAB Forum to clarify this requirement.
- Wayne
On Wed, Jan 30,
On Mon, Feb 4, 2019 at 1:33 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> As you know, CCADB sends audit reminder emails regarding root certs in
> Mozilla's program on the 3rd Tuesday of each month.
>
> We are going to update the date checks
I can't speak for the BRs, but I think root programs have considered this,
and have discouraged it in the absence of strong technically-enforcable
controls (e.g. being technically prevented from TLS certificates). Some
root programs have gone to a further extreme, and suggested that no
divergence
Thanks Wayne.
Definitely, these things, the less left to interpretation, the better... I
personally think BR should consider the fact that under a Root there can be
different certificate policies, because as you say the strict reading of BR
implies that suspension is forbidden also for
All,
As you know, CCADB sends audit reminder emails regarding root certs in
Mozilla's program on the 3rd Tuesday of each month.
We are going to update the date checks for determining when the email
gets sent, so that rather than keying off of the Audit Statement Date,
the check will key off
While a certain amount of latency in OCSP updates is expected when a
certificate is first issued or revoked, KIR intended this to be a permanent
"unknown" status for a revoked certificate. My conclusion from this
discussion is that such a policy is not permitted, and the existing
requirements are
On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via
dev-security-policy wrote:
> Hi,
>
> Today we've bought a wildcard certificate [0] for our cofano.io domain
> from Sectigo (previously ComodoCA) via a reseller. Our CAA policy
> describes that only "comodoca.com" can issue wildcards. The
The BRs define Repository as:
Repository: An online database containing publicly-disclosed PKI governance
documents (such as Certificate Policies and Certification Practice
Statements) and Certificate status information, either in the form of a CRL
or an OCSP response.
I see no evidence to
Well... my understanding is that “Repository” refers there to the one of the
Issuing CA, not the whole repository under a Root, because a Root could have
subordinates that don’t issue SSL, and for which suspension could be allowed.
___
Hi Pedro!
Why do you believe that BRGs 4.9.13 is only applicable for EE / Subscriber
certs?
> 4.9.13. Circumstances for Suspension
> The Repository MUST NOT include entries that indicate that a Certificate is
> suspended.
With best regards,
Rufus Buschart
Siemens AG
Information Technology
Hi,
Today we've bought a wildcard certificate [0] for our cofano.io domain
from Sectigo (previously ComodoCA) via a reseller. Our CAA policy
describes that only "comodoca.com" can issue wildcards. The
certificate has been issued and signed by Sectigo's 'new' intermediate
and root [1] [2].
My
Hello,
sorry if this is a silly question, but I was wondering if it is allowed that a
Root or Intermediate CA suspends the certificate of an issuing CA.
We can imagine the case of a suspected key compromise, or even a contractual
breach, that could lead to recommend putting the Issuing CA in
12 matches
Mail list logo
