Thank you for the clarification. This would appear to introduce a new
requirement for clients verifying SCTs from CT2: a get-proof-by-hash call
to the log server (or a mirror) is now required to know if a SCT from
before May 2 is valid. Do CT-enforcing clients do this in practice today?
(I suspect
The timestamp on a SCT is fully controlled by the signer, so why should
SCTs bearing a timestamp before May 2 still be considered trusted?
Alex
On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey all,
>
> The key used to sign
On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy
wrote:
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via
> dev-security-policy wrote:
> > Hi,
> >
> > I recently noticed that a lot of leaf certificates [0] have
> > organizationalUnitName specified without o
Neil's interpretation of my poorly-worded question was correct - thank you
and apologies for the confusion.
On Thu, Sep 12, 2019 at 5:39 PM Ryan Sleevi wrote:
>
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as
> if corresponding certificat
On Mon, Sep 2, 2019 at 1:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/09/2019 20:13, Alex Cohn wrote:
> > On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > Waiting until
On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If an OCSP server supports returning (or always returns) properties of
> the actual cert, such as the CT proofs, then it really cannot do its
> usual "good" responses until the proc
On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond g
Inspired by Nick Lamb's comment a week or so ago on m.d.s.p about "Default
City" being an OpenSSL default value in CSRs, I ran some more searches on
the OpenSSL defaults and found almost 100 certificates with a
stateOrProvinceName of "Some-State". BR section 7.1.4.2.2(f) requires this
field to be v
On Thu, May 2, 2019 at 3:45 PM Nick Lamb wrote:
> Alex, you say you "came across" these certificates, do you think it is
> likely that there are many more, or was that in practice a fairly
> thorough search?
I've been adding certificates found in Censys scans to CT logs, and
happened to spot one
Hi all,
I came across a number of certificates issued by Sectigo, SECOM, and
DigiCert that list "Default City" as the subject's locality. Unless there
are actually localities named "Default City" that I'm unaware of, it seems
to me this is a violation of the BRs, sections 3.2.2.1 and 7.1.4.2.2.e.
Hi,
It appears AlwaysOnSSL is not completely disabled - if we trust CT as
a timestamping service, [1] was issued after Hanno's email.
I believe AlwaysOnSSL has at least two separate paths to issuance - in
addition to the website, there's also an API on CertCenter's website.
[2] While reading the
On Sat, Dec 8, 2018 at 5:01 AM Richard Moore via dev-security-policy
wrote:
>
> > the scope of the main project if ~120 certs across a similar number of
> > vendors. One of the home grown applications also hardcode the name of the
> > certificate into the application and will require not only ce
On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck wrote:
>
> As of today this is still unrevoked:
> https://crt.sh/?id=630835231&opt=ocsp
>
> Given Comodo's abuse contact was CCed in this mail I assume they knew
> about this since Sunday. Thus we're way past the 24 hour in which they
> should revoke it.
The certificate [1] in the GitHub link you posted was issued by Comodo, not
by GeoTrust. The two share a private key, though, so both the Comodo and
GeoTrust certs should be considered compromised at this point. I've added
the Comodo-issued cert to several CT logs for tracking, and I'm CCing
ssl_ab
I'm currently grabbing certs from Censys's BigQuery extracts and
submitting them to the Argon logs (and Daedalus/Rocketeer for certs
that fall before/after Argon's not-after range).
There's a fair bit of latency in the process; I'm only running this
script weekly (it costs about $4 a pop in BigQue
remy
>
> -Original Message-
> From: dev-security-policy
>
> On Behalf Of Alex Cohn via dev-security-policy
> Sent: Sunday, March 11, 2018 9:37 PM
> To: dev-security-policy@lists.mozilla.org
> Subject: DigiCert .onion certificates without Tor Service Descriptor Has
In the EV Guidelines [1], Appendix F states "The CA MUST include the
CAB Forum Tor Service Descriptor Hash extension in the TBSCertificate
convey hashes of keys related to .onion addresses." This language was
added in Ballot 201 [2], which had an effective date of 8 July 2017.
The following certif
I logged two of those five certificates (https://crt.sh/?id=308392091
and https://crt.sh/?id=307753186) to Argon, as part of a project to
log every certificate in the censys.io database to a public CT log. I
believe Censys found them by scanning all of IPv4 and grabbing the
default (i.e. no SNI) ce
19 matches
Mail list logo
