On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling
> I'm currently running the check against all of the certs on the crt.sh
> DB. I'll report back once this has completed.
Hi Rob,
Did your checks find anything else in the end?
___
Gerv, thank you so much for all of your hard work over the years. I first
contacted you when you reached out for tech evangelism help for SSLv2
(https://blog.gerv.net/2005/09/ssl2_must_die/) back in 2005. You helped me come
up with the plan for contacting sites and I filed
Hmm, CAA records could also potentially be spoofed in this situation, in which
case they would also not be trustworthy (save for cached records with a long
TTL).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
I think it depends on whether the issue has been fixed or not. If it has not
been fixed, then I would say that all CAs need to put a hold on .tg certificate
issuance as a priority. If a registry can be compromised, then potentially the
integrity of all 10 blessed methods is at risk.
If it has
I notice that on https://crt.sh/mozilla-onecrl there are lots of certificates
that have recently been added to OneCRL from the .tg TLD (Togo), including ones
for high-profile domains such as google.tg. The issuances occurred 3 days ago,
on 1st November.
I don't see a thread already for this
On Monday, 16 October 2017 18:32:54 UTC+1, Gervase Markham wrote:
> = Symantec roots to be disabled via code, *not* removed from NSS =
>
> GeoTrust Global CA
> GeoTrust Primary Certification Authority - G2
> GeoTrust Primary Certification Authority - G3
>
> = Symantec roots that will be fully
On Monday, 19 June 2017 20:57:28 UTC+1, Tavis Ormandy wrote:
> I noticed there's an apparently valid facebook.com certificate in there
> (61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that
> seems like it would be in CT already - so maybe I don't know what I'm doing.
>
> Let
This is now on crt.sh here: https://crt.sh/?id=156475584=cablint,x509lint
This is indeed a key compromise event, thanks for the level of detail provided.
An attacker in control of a network could use this to impersonate
https://drmlocal.cisco.com/ and leverage that to potentially steal a user's
On Saturday, 4 March 2017 21:21:41 UTC, Jeremy Rowley wrote:
> Common practice amongst certain cas. There were several cas that have always
> opposed cert validity periods longer than three years. This opposition lead
> to the reducing the validity period first to 60 months then to 39 months.
On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley wrote:
> 1.0 is not the definitive version any more. As of 2015‐04‐01, Section
> 6.3.2 prohibits validity periods longer than 39 months.
>
Thanks for the prompt reply Jeremy. I realise this. My question relates to what
the situation was
Hello,
Version 1.0 of the Baseline Requirements stated that:
"Certificates issued after the Effective Date MUST have a Validity Period no
greater than 60 months".
The effective date for this version was 2012-07-01
(https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf).
I
11 matches
Mail list logo
