On Tue, 4 Dec 2018 14:55:47 +0100
Jakob Bohm via dev-security-policy
wrote:
> Oh, so you meant "CA issuance systems and protocols with explicit
> automation features" (as opposed to e.g. web server systems or
> operating systems or site specific subscriber automation systems).
> That's why I
On Tue, Dec 4, 2018 at 2:08 PM Kurt Roeckx wrote:
> He explained before that the module that generated the corrupt
> signature for the CRL was in a weird state after that and all
> the newly issued certificates signed by that module also had
> corrupt signatures.
>
Ah! Thanks, I misparsed that.
On Tue, Dec 04, 2018 at 01:14:44PM -0500, Ryan Sleevi via dev-security-policy
wrote:
>
> > All issued certificates were unusable due to corrupted signature.
> >
>
> Could you speak to more about how you assessed this? An incorrect signature
> on the CRL would not necessarily prevent the
On Tue, Dec 4, 2018 at 1:29 PM Dimitris Zacharopoulos via
dev-security-policy wrote:
> I tried to highlight in this discussion that there were real cases in
> m.d.s.p. where the revocation was delayed in practice. However, the
> circumstances of these extended revocations remain unclear. Yet,
On Tue, Dec 4, 2018 at 5:02 AM Fotis Loukos
wrote:
> An initial comment is that statements such as "I disagree that CAs are
> "doing their best" to comply with the rules." because some CAs are
> indeed not doing their best is simply a fallacy in Ryan's argumentation,
> the fallacy of
Fotis,
You have quoted only one part of my message which doesn't capture the
entire concept.
CAs that mis-issue and must revoke these mis-issued certificates,
already violated the BRs. Delaying revocation for more than what the BRs
require, is also a violation. There was never doubt about
On November 19, 2018 an SSL certificate was issued with '-' in the ST field of
the subject DN. The certificate has been revoked.
Details of the incident report can be found here,
https://bugzilla.mozilla.org/show_bug.cgi?id=1512018.
Thanks, Bruce.
>
> Thanks for filing this, Wojciech. This is definitely one of the better
incident reports in terms of providing details and structure, while also
speaking to the steps the CA has taken in response. There was sufficient
detail here that I don't have a lot of questions - if anything, it sounds
Hello,
On 4/12/18 4:30 μ.μ., Jakob Bohm via dev-security-policy wrote:
> Hello to you too.
>
> It seems that you are both misunderstanding what the proposal was.
>
> The proposal was apparently to further restrict the ability of CAs to
> make exceptions on their own, by requiring all such
On 04.12.2018 15:16, Kurt Roeckx via dev-security-policy wrote:
I think you misunderstood my question. I think you should never serve an
invalid file. I think it's better to have a file that is 1 or 2 days old
then it is to have an invalid file. So you could check that it's a valid
file before
Hello to you too.
It seems that you are both misunderstanding what the proposal was.
The proposal was apparently to further restrict the ability of CAs to
make exceptions on their own, by requiring all such exceptions to go
through the public forums where the root programs can challenge or
On 2018-12-04 10:25, Wojciech Trapczyński wrote:
On 04.12.2018 10:01, Kurt Roeckx via dev-security-policy wrote:
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between
On 04/12/2018 13:36, Nick Lamb wrote:
On Tue, 4 Dec 2018 07:56:12 +0100
Jakob Bohm via dev-security-policy
wrote:
Which systems?
As far as I'm aware, any of the automated certificate issuance
technologies can be used here, ACME is the one I'm most familiar with
because it is going through
On Tue, 4 Dec 2018 07:56:12 +0100
Jakob Bohm via dev-security-policy
wrote:
> Which systems?
As far as I'm aware, any of the automated certificate issuance
technologies can be used here, ACME is the one I'm most familiar with
because it is going through IETF standardisation and so we get to see
Hello everybody,
First of all, I would like to note that I am writing as an individual
and my opinion does not necessarily represent the opinion of my employer.
An initial comment is that statements such as "I disagree that CAs are
"doing their best" to comply with the rules." because some CAs
On 04.12.2018 10:01, Kurt Roeckx via dev-security-policy wrote:
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35
On 2018-12-04 7:24, Wojciech Trapczyński wrote:
Question 1: Was there a period during which this issuing CA had no
validly signed non-expired CRL due to this incident?
Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) we
were serving one CRL with corrupted signature.
17 matches
Mail list logo
