On 8/3/17 5:27 PM, Kathleen Wilson via dev-security-policy wrote:
> On Thursday, August 3, 2017 at 4:34:27 PM UTC-7, Ryan Sleevi wrote:
> In bug #1311832 there is a note about cross-signing:
> "[1] The new (replacement) root certificates may be cross-signed by the
> Affected Roots. However, the
Lee,
Different parts of Mozilla does monitor CT, both for internal IT
purposes, as well as research into the WebPKI. It seems like crt.sh does
a great job already of handling cablint/x509lint of newly-observed certs.
What are you looking for Mozilla to provide here that isn't already
being
All,
Today Hanno Böck blogged about performing surgery on ASN.1-encoded RSA
private keys to make them appear to correspond to a target certificate's
public key, and using the franken-key file to appear to legitimately hold
the private key of that target certificate.
On Tue, Jun 27, 2017 at 1:49 PM, Tom . wrote:
> On 27 June 2017 at 11:44, Alex Gaynor wrote:
> > I'll take the opposite side: let's disallow it before it's use expands
> :-)
>
> But is that what we're talking about? I didn't think the question was
> "Should we remove P-521 code from NSS" it's
I share the desire to move faster than these dates, but upon
consideration, I don't think it's much of a boon to web security for
Mozilla to be substantially ahead of Chrome in implementing these trust
changes.
Since Chrome's decision to implement in April is final, their large user
population is
All,
As part of some related research, I did some analysis of availability,
size, and download latency of the CRLs currently known in Censys. There
are a number of CRLs missing, or whose DNS no longer resolves; a number
of graphs of size and latency, and the code.
All,
Just an interesting heads up:
While we were doing some maintenance on the CCADB, Chris Henderson found
Golang could not process several of Wells Fargo's intermediate CAs, such as:
- sha256sum =
3B8812E6F851B6F933DC23ED764082FB5F50DE3C2DDDEBCC9CA240B7ACACE4D1
Niklas,
That's fine. Thanks for the heads up. Note that the format has a
possibility of changing some in 2018, but only in the way of adding fields,
not changing existing data.
Cheers,
J.C.
Crypto Engineering
On Thu, Dec 14, 2017 at 9:03 AM, niklas.bachmaier--- via
dev-security-policy
Ryan -
Originally the Observatory had "Subject+SPKI" hash field. Someone filed a
bug that Subject+SPKI field wasn't as useful for external comparisons as
the SPKI, and the Observatory changed over, replacing the old Subject+SPKI
hash with a pure SPKI hash.
We were proposing to switch to just the
As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
through it in the Validation Working Group. The ADN lookup is DNS, and what
you find when you connect there via TLS, within the certificate, should be
the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
rde...@gmail.com>
wrote:
>
>
> On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
>> through it in the Validati
11 matches
Mail list logo
