Hi Wayne. On this particular point...
> They don't list valid/expired/revoked domains for all of their sub-CAs
Please note that the requirement in BR section 2.2 is as follows (emphasis
mine):
"The CA SHALL host test Web pages that allow Application Software Suppliers to
test their software
> Why is this compression scheme likely to take off when there was no interest
> in pursuing my proposal or that of Rob Straddling ten years ago?
Hi Phill. Our 2014 I-D [1] tackled CRL compression, whereas the new proposal
[2] that Watson referred to tackles WebPKI Certificate compression.
> CA operators MUST apply to Mozilla for inclusion of their next generation
> root certificate at least 2 years before the distrust date of the CA
> certificate they wish to replace.
Hi Ben. I would interpret that sentence to mean that if a CA operator misses
the "at least 2 years" deadline
> So ISTM that, per current requirements, Sectigo hasn't done anything wrong in
> these two cases. Nonetheless, since we're actually still issuing CRLs for
> these expired CAs, I will update the disclosed Full CRL URLs to ones that do
> work.
FWIW, I've reviewed, and updated where necessary
Hi Daniel.
> Forbidden responses:
>
> * CA Owner: Sectigo
> * Salesforce Record ID 001o00poU6CAAU
> * CRL URL: http://crl.nicecert.com/eBizNetworksCodeSigningCA.crl
> * Salesforce Record ID 001o00piSaqAAE
> * CRL URL: http://crl.nicecert.com/eBizNetworksLASSLCA.crl
The
Hi Kathleen. Are you planning to move all of the existing bugs relating to the
Mozilla CA program from the "NSS" product to the identically named components
in the "CA Program" product?
If not, then I think (for example) https://wiki.mozilla.org/CA/Closed_Incidents
will still work as expected
> Ok, I wasn't aware up until now that crt.sh has data from pure test logs.
crt.sh doesn't monitor "pure" test logs, such as Google's testtube, crucible
and solera logs.
Dodo was not originally intended to be a test log (see
> I'm also inclined to say HTTPS must not be used here.
I just went through the same thought process regarding the Full CRL field (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1794899#c1). It turns out that
several CAs are currently using HTTPS URLs for CRL.
FWIW, I'm confident that my reading is what was intended when this sentence was
added to the MRSP, because I recall some of the events that led to that
language being proposed. It's very unfortunate that an alternative
interpretation is possible, and that there don't seem to be any Incident
Hi Tim. That's the theoretically correct process, but...
Is filing an erratum actually worth the effort?
I filed a bunch of errata against RFC8555 (ACME) several years ago
(https://www.rfc-editor.org/errata_search.php?rfc=8555_status=0), but
despite several attempts (on-list requests, private
Aaron Gable wrote:
> (Full disclosure: Let's Encrypt does not currently include the Issuing
> Distribution Point extension, and therefore does not include its
> distributionPoint field, in its CRLs. This is because we conducted the
> analysis laid out below and came to the conclusion that it is
Thanks Clint!
To help CAs and any other interested parties track compliance with the various
existing and imminent CCADB disclosure requirements in the Apple Root Program
Policy, I've put together a new crt.sh page...
https://crt.sh/apple-disclosures
This page currently shows evidence of
port includes revoked ICAs, should we exclude those?
*
https://crt.sh/?sha256=4675a0e26d832ab881da9aeac5e1ba1a90a9a445c9145c5a99b25f29be95ecd0=mozilladisclosure
Thanks!
From: 'Rob Stradling' via dev-security-policy@mozilla.org
Sent: Friday, September 23, 2022 11:29 AM
To: dev-security-policy@mozi
To help CAs and any other interested parties track compliance with MRSP Version
2.8's CRL disclosure requirement
(https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements)
before the October 1st deadline, I've updated
Hi all. Kathleen dealt with my request off-list. The "JSON Array of
Partitioned CRLs" field has now been appended to
https://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat.
____
From: 'Rob Stradling' via dev-security-policy@mozilla.
Thanks Clint. Your interpretation of the Apple Root Program's CRL URL
disclosure requirement is crystal clear to me, thanks to your comments here and
in the official communication you mentioned. Sectigo's compliance to this
requirement in Apple's eyes is actually the least of my concerns,
AIUI, the latest published version of a root store policy always takes
precedence over (1) draft updates to that policy, (2) language proposed for
public discussion by the policy's owner, and (3) expressions of intent by the
policy's owner that are at odds with the latest published policy
Kathleen, Ben,
I would like to enhance https://crt.sh/mozilla-disclosures to monitor
compliance to Mozilla's new CRL URL disclosure requirement that comes into
force in about a week and a half from now
> Please do not modify data in the CCADB during this update.
> There will be an "Under Construction" message on the CCADB home page, and I
> will post another update here when the changes have been completed and
> verified.
Hi Kathleen. Do you know when these changes are expected to be
as a key-based blocklist system.
From: Hanno Böck
Sent: 09 September 2022 10:54
To: 'Rob Stradling' via dev-security-policy@mozilla.org
Cc: Rob Stradling
Subject: Re: Debian Weak Keys and ECDSA
CAUTION: This email originated from outside of the organization. Do not click
links
Hanno and Julien, thanks for confirming that EC key generation was enabled in
the affected Debian distributions.
https://github.com/CVE-2008-0166/key_generator is now able to generate the
secp256r1 and secp384r1 keypairs that are predictable (due to the CVE-2008-0166
vulnerability), and I've
> The source of this confusion seems to be a footnote in a paper published
> shortly after that bug [4] ("but the version of OpenSSL deployed on
> Debian-derived distributions ships without any elliptic curve support"). That
> is wrong.
Hi Hanno. I agree that the OpenSSL 0.9.8 branch
and Dimitris,
I think you're correct, but let me confirm and get back to you.
Ben
On Fri, Jun 24, 2022 at 10:10 AM 'Rob Stradling' via
dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org>
mailto:dev-security-policy@mozilla.org>> wrote:
Hi Dimitris. IIUC, you'r
es not include the disclosure of Revoked subCAs as
they are not "technically capable of issuing working server or email
certificates".
Thanks,
Dimitris.
On 24/6/2022 3:13 μ.μ., 'Rob Stradling' via
dev-security-policy@mozilla.org<mailto:dev-security-policy@mozilla.org> wrote:
Hi. T
Hi. This is a friendly reminder about the recent Mozilla Root Store Policy
update[1] that was communicated in ITEM 7 (Publicly Disclose Intermediate CA
Certificates capable of Issuing TLS or SMIME...in the CCADB by July 1, 2022,
even if they are technically constrained) of the May 2022 CA
> I have added a link to RFC 6962, which uses the term "final certificate". I
> could not find any other industry-accepted term that we could use to convey
> the concept.
FWIW, we got rid of the term "final certificate" in RFC9162 (CTv2), which talks
instead about a precertificate and its
26 matches
Mail list logo
