Under the Servers tab for Certificate Manager, I see several root
certificates whose expiration dates have passed. I believe these were
all marked untrusted at one time. For example, I see six DigiNotar
certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among
others. Is it safe to
On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5, birg...@princeton.edu wrote:
> We have been considering research in this direction. PEERING controls several
> ASNs and may let us use them more liberally with some convincing. We also
> have the ASN from Princeton that could be used with cooperation
On Monday, July 24, 2017 at 2:50:22 AM UTC-7, Gervase Markham wrote:
> Hi Rick,
>
> Some more thoughts on your post. I continue to invite community
> commentary on the issues we are discussing.
>
> On 21/07/17 07:00, Rick Andrews wrote:
> > In our June 1 post, we stated that we would update the c
Hi Mark,
Are you saying you do intend to revoke all of these certificates in the
next 24 hours?
While subscribers are allowed to continue using bad certificates as long as
they desire, the BRs require CAs to revoke non-compliant certificates
within 24 hours of becoming aware of them.
Alex
On Tu
Op woensdag 19 juli 2017 00:26:16 UTC+2 schreef Charles Reiss:
> - Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to
> Staat der Nederlanden Root CA - G2) has issued certificates which serial
> numbers that appear to be of the form 0x1000 + sequential counter
> with notBefor
On Monday, July 24, 2017 at 5:31:33 AM UTC-7, Jakob Bohm wrote:
> On 22/07/2017 02:38, birge...@princeton.edu wrote:
> > On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
> >> It seems that a group of Princeton researchers just presented a live
> >> theoretical* misissuance by
Each CA is required (under the BRs) to provide public information on how to
submit certificate problem reports, including mis-issued certificates. The
only way to properly notify the CA is through that mechanism as those are
monitored 24 hours. CAs participating on the list usually have a couple of
On Tue, Jul 25, 2017 at 12:57:44PM -0400, Alex Gaynor via dev-security-policy
wrote:
> Following up on this (and really several other threads). The BRs require
> mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
> are required to track m.d.s.p. per the Mozilla Root Policy,
Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.
In any event, here
On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb wrote:
> On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote:
> > The right balance is probably revoking when misuse is shown.
>
> Plus education. Robin has stated that there _are_ suitable CA products for
> this use case in existen
Hello Kai,
On Friday, June 30, 2017 at 7:38:59 PM UTC+3, Kai Engert wrote:
> Hello Gerv,
>
> I think the new format should be as complete as possible, including both trust
> and distrust information, including EV and description of rules for partial
> distrust.
>
> As of today, certdata.txt con
11 matches
Mail list logo