Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

Hi Wayne, On Fri, 3 May 2024 04:29:15 -0700 (PDT) Wayne wrote: > They don't list valid/expired/revoked domains for all of their > sub-CAs CAs are only required to provide one set of test websites per root, not for every sub-CA. > and even the ones they do are running on the same wildcard >

Re: CT Log Inclusion check: get-entry-and-proof unexpectedly returns "Not found"

Hi Felix, On Wed, 1 May 2024 10:18:17 -0700 (PDT) Felix Linker wrote: > Hi everyone, > > I encountered an oddity with an inclusion of a certificate of mine in > a CT log. Namely, I would like to check the inclusion of this > certificate (https://crt.sh/?id=12905498367) in the Yeti 2024 log. It

Re: evaluation of aggregate behaviour for CAs

Hi Mike, On Thu, 2 May 2024 17:09:42 -0400 Mike Shaver wrote: > From also reviewing a number of historical incidents in Bugzilla, it > seems that currently the decision as to whether to sanction a CA is > largely evaluated on a per-incident basis: is this specific incident > sufficient grounds

Re: RCE used by Intermediate CA to issue certificates.

On Fri, 9 Jun 2023 05:42:22 -0700 (PDT) "John Han (hanyuwei70)" wrote: > Here is the story. > https://github.com/acmesh-official/acme.sh/issues/4659 > > Seems like they exploited acme.sh and let user to evade certificate > issuing procedure. > > Do we need to discuss this? The party in

Re: CRL partitioning and IDPs

On Thu, 6 Oct 2022 13:36:03 -0700 "'Aaron Gable' via dev-security-policy@mozilla.org" wrote: > Ah, that's a good point! > > In Let's Encrypt's particular case, we guarantee that all of our CRL > shards in a given "generation" share the same CRL Number, so > detecting one shard substituted from

Re: CRL partitioning and IDPs

On Thu, 6 Oct 2022 12:33:17 -0700 "'Aaron Gable' via dev-security-policy@mozilla.org" wrote: > An older but still sufficiently-recent version of a different shard > would contain serials which also appear on the current version of > that same different shard. These duplicate serials would

Re: CRL partitioning and IDPs

On Thu, 6 Oct 2022 11:32:50 -0700 "'Aaron Gable' via dev-security-policy@mozilla.org" wrote: > A client downloading the full collection of CRL shards can check the > thisUpdate timestamps to ensure it is not receiving old data, and can > check for duplicate shards to ensure it doesn't receive

Invalid URLs in "Full CRL Issued By This CA" field

I'm attempting to download the CRLs referenced by the "Full CRL Issued By This CA" field in CCADB and have noticed a number of invalid or non-functional URLs. For example: Un-resolvable hostname: http://Certera.crl.sectigo.com/CerteraDVSSLCA.crl URL missing protocol: lva.at/files/lva_2016.crl

Re: Add another field to AllCertificateRecordsCSVFormat

Thanks Kathleen for adding the field to the report. I'm trying to process this field, and so far the only well-formed JSON I've found is the empty array (i.e. "[]"). Numerous CAs have failed to put double quotes around the URLs, e.g.: [http://example.com/crl1, http://example.com/crl2] Another

Re: Policy 2.8: Final Review of MRSP v. 2.8

I am concerned by effective date of October 1, 2022 for the last two bullet points of Section 5.4 (Precertificates). Although some CAs have argued that these are "new" requirements, they haven't explained _why_ they need this amount of time to become compliant, and for the reasons I previously

Re: Policy 2.8: Final Review of MRSP v. 2.8

ertificate's issuer's issuer.* Thus, ..." > > Ben > > On Thu, Apr 21, 2022 at 3:07 PM Ben Wilson > wrote: > > > Should it say "final certificate" in this bullet? > > > > On Thu, Apr 21, 2022 at 11:15 AM Jacob Hoffman-Andrews < > > j...@letse

Re: Policy 2.8: Final Review of MRSP v. 2.8

On Tue, 19 Apr 2022 20:56:25 -0600 Ben Wilson wrote: > Hi Rob and Andrew, > > "Corresponding certificate" seems to work, but are you OK with this > for the first bullet? > > " * if a corresponding certificate cannot be verified as matching a > precertificate using the algorithms in RFC 6962,

Re: Policy 2.8: Final Review of MRSP v. 2.8

On Tue, 19 Apr 2022 16:29:29 -0700 (PDT) "'Dustin Hollenback' via dev-security-policy@mozilla.org" wrote: > > Our understanding is that the information in Section 5.4 > Precertificates has been a Recommended Practice >

Re: Policy 2.8: Final Review of MRSP v. 2.8

the final certificate does not actually exist; and > > ·a CA must provide CRL and OCSP services and responses in > accordance with this policy for all certificates presumed to exist > based on the presence of a precertificate, even if the certificate > does not actually ex

Re: Policy 2.8: Final Review of MRSP v. 2.8

Hi Ben, My comments about the precertificates section haven't been fully addressed: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Co65loD9i-0/m/Trt4N9QQAgAJ Regards, Andrew On Wed, 13 Apr 2022 11:18:24 -0600 Ben Wilson wrote: > All, > > Here are links helpful during your

Re: Introducing OCSP Watch to Monitor OCSP Responder Reliability

On Thu, 24 Mar 2022 05:46:37 -0700 (PDT) Viktor Varga wrote: > We found out, that the OCSP Checker gives false positives on OCSP > responder certificates. > The responders have OCSP No Check extension, so the responders are > not giving valid answers on requests. > All the Microsec results are

Re: Introducing OCSP Watch to Monitor OCSP Responder Reliability

The code that OCSP Watch uses to evaluate a certificate's OCSP responder is now public: https://github.com/SSLMate/ocsputil Regards, Andrew -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and

Re: Introducing OCSP Watch to Monitor OCSP Responder Reliability

h amongst other things > does a test for "GET request containing multiple forward-slashes". > > Can you confirm whether or not you're leaving "//" un-URL-encoded? > > Also, is your code for ocspwatch publicly available? > > >

Introducing OCSP Watch to Monitor OCSP Responder Reliability

Recently, we've seen several CA incidents related to the failure to provide OCSP responses, such as not operating OCSP services for abandoned certificate orders , or publishing OCSP responses with lengthy delays

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

I took a look at parts of Certainly's CP/CPS. I'm happy to see Certainly use a combined CP/CPS. However, section 3.2.2 says: "Certainly validates domain control primarily in an automated fashion using the ACME protocol. In exceptional cases control may be validated using methods similar to

Re: Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

On Fri, 3 Sep 2021 15:34:47 -0700 (PDT) Brett L wrote: > Though we always try to land documentation changes with corresponding > code changes sometimes it is simply not always feasible. The above statement is concerning, because section 2.2 of the Baseline Requirements state: "Section 4.2 of a

Re: Public Discussion of Chunghwa Telecom's Root Inclusion Request

On Fri, 3 Sep 2021 19:40:47 -0700 (PDT) Li-Chun CHEN wrote: > > > > 3) if some other status is detected, the system skips over this > > step - i.e. does not consult a RAO, but assumes issuance is > > permitted as far as CAA records are concerned? > > > > Our RA system will made the CAA checking

Re: Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

On Wed, 1 Sep 2021 14:21:47 -0700 (PDT) Brett L wrote: > Hi Andrew, > > Thank you for the questions and checking on details. > > We removed the option to use the DNS operator exception from our > secondary CA platform on 2021-05-13 (60 days before the ballot > changes went into effect, see

Re: Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

Prior to 2021-08-11, Google Trust Services' CPS (version 3.4, https://pki.goog/repo/cps/3.4/GTS-CPS.pdf) contained the following exception to checking CAA: "If Google is the DNS Operator (as defined in RFC 7719) of the domain's DNS." This exception was banned by CABF Ballot SC46, which passed on