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 "qu
84;
WEEE-Reg.-No. DE 23691322
> -Ursprüngliche Nachricht-
> Von: dev-security-policy Im
> Auftrag von Pedro Fuentes via dev-security-policy
> Gesendet: Montag, 4. Februar 2019 16:40
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Is it allowed th
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.
___
dev-security-pol
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 suppor
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 certifi
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 i
Understanding these arguments, I think it must considered that there are
practical implications for the CAs to have Roots dedicated to each use-case.
Having multiple Roots is neither encouraged nor well seen by some Root
programs. Also, for a CA, adding a new Root is not only relatively onerous,
On Tue, Feb 5, 2019 at 3:56 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Understanding these arguments, I think it must considered that there are
> practical implications for the CAs to have Roots dedicated to each
> use-case. Having multiple Roots is
El martes, 5 de febrero de 2019, 17:03:50 (UTC+1), Ryan Sleevi escribió:
>
> Note that the topic of whether or not subscriber EKUs was significantly
> discussed in the past, and is why the policy is/tries to be very clear that
> it applies to anything technically capable of SSL/TLS issuance, and
9 matches
Mail list logo