On 17/01/18 13:18, Gervase Markham via dev-security-policy wrote:
On 17/01/18 10:25, Rob Stradling wrote:
However, the Stable version of the Mozilla Root Store Policy [2] still
says 15th January 2018.
Surely the Stable version of the Policy is in force and the Draft
version is not yet in force?
+1
ISTM that Wayne is already doing an excellent job!
On 16/01/18 22:03, Kathleen Wilson via dev-security-policy wrote:
All,
I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I
are distributing the jo
t; wrote:
What about the Mozilla CA communication that said that CAs had until 15
April 2018?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16
[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents
Mozilla's policy and/or current expectations. Thanks!]
Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the
non-disclosure (and, IINM, non-audit) of certain
non-technically-constrained id-kp-emailProtection interme
Hanno, thanks for reporting this to us earlier today.
Mozilla, please consider adding https://crt.sh/?id=245397620 to OneCRL.
Thanks.
On 12/01/18 15:33, Hanno Böck via dev-security-policy wrote:
Hi,
Comodo ITSM (IT Service Management Software) runs an HTTPS server on
localhost and port 21185
On 15/12/17 00:18, Matthew Hardeman via dev-security-policy wrote:
On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote:
Route hijacking your way to what would appear as a proper domain validation is
practical for even a modestly resourceful adversary. I suspect that the
On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:
If you look at where the HTTPS phishing certificates come from, they come
almost entirely from Let's Encrypt and Comodo.
This is perhaps the best argument in favor of distinguishing between CAs
that care about phishing and those tha
Inspired by Paul Kehrer's research a few months ago, I've added a
continuous OCSP Monitoring feature to crt.sh:
https://crt.sh/ocsp-responders
This page shows the latest results of 3 OCSP checks (performed hourly)
against each CA / Responder URL that crt.sh has ever encountered:
1. a GET re
On 24/11/17 12:25, Gervase Markham via dev-security-policy wrote:
On 24/11/17 11:37, Rob Stradling wrote:
When issuing a "single domain" certificate to (for example)
www.example.com or *.example.com, it's fairly common practice for CAs to
also include in the certificate a SAN.dNSName for the "ba
Hi Quirin.
I agree that Comodo should not have issued certificates 1, 3, 4 and 5.
When issuing a "single domain" certificate to (for example)
www.example.com or *.example.com, it's fairly common practice for CAs to
also include in the certificate a SAN.dNSName for the "base domain"
(e.g., exa
On 24/11/17 11:22, Quirin Scheitle via dev-security-policy wrote:
On 24. Nov 2017, at 05:33, Han Yuwei via dev-security-policy
wrote:
Comodo will check CAA before issurance even domain in Cloudflare. I asked it
before
(https://groups.google.com/d/msg/mozilla.dev.security.policy/rFyPQ0o7RMM
On 22/11/17 11:45, marcan via dev-security-policy wrote:
On 22/11/17 20:41, Tom via dev-security-policy wrote:
Although not listed in the Action plan in #1311824, it is noteworthy
that Richard Wang has apparently not been relieved of his other
responsibilities, only the CEO title
Do you have a
On 09/11/17 13:09, Rob Stradling via dev-security-policy wrote:
On 06/11/17 22:26, Rob Stradling via dev-security-policy wrote:
On Monday 6th November, we scanned the certificates that we'd issued
between 20th October and 5th November. 8 further server
authentication certificates were
On 06/11/17 22:26, Rob Stradling via dev-security-policy wrote:
On Monday 6th November, we scanned the certificates that we'd issued
between 20th October and 5th November. 8 further server authentication
certificates were found, all for subdomains of the same registered
domain. We wil
I see all 7 of the certs identified in this thread in crt.sh:
Serial number: 4a907fbfc90eb043c50c9c8ace6305a1
SAN->dNSName: [www.]asik-portal.com
https://crt.sh/?id=13734110
Serial number: 8008c178d0d4cd3d79acc09f6ac132c
SAN->dNSName: *.Thameswater.co.uk
https://crt.sh/?id=249452540
Serial numb
On 16/10/17 15:13, Alex Gaynor via dev-security-policy wrote:
Hi all,
Today researchers announced a vulnerability they discovered in RSA keys
generated by a particular piece of firmware, which allows practical
factorization of the private key given just the public key.
Full details of the resea
On 17/10/17 14:49, Rob Stradling via dev-security-policy wrote:
On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote:
Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation,
Hi Jakob. Today I ended up rewriting the ROCA f
On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote:
Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation,
Hi Jakob. Today I ended up rewriting the ROCA fingerprint checker in C
(using OpenSSL BIGNUM calls) to get it working
On 16/10/17 20:01, Matthew Hardeman via dev-security-policy wrote:
The authors of the paper on the weak RSA keys generated by Infineon TPMs and
smart cards have published code in multiple languages / platforms that provide
for an efficient test for weakness by way of the Infineon TPM bug.
Perh
Hi Adriano.
It was pointed out to me that the doppelganger intermediate certificates
that Actalis issued to Unicredit (https://crt.sh/?id=47081615 and
https://crt.sh/?id=147626411) don't quite meet Mozilla's current
"technically constrained" criteria.
Since v2.3, the Mozilla Root Store Polic
On 04/10/17 13:18, Adriano Santoni via dev-security-policy wrote:
Are these "temporary unconstrained SubCA certificate"s publicly
trusted? That is, do they have valid signatures from your "Actalis
Authentication Root CA" (https://crt.sh/?caid=935) ?
If yes, can you confirm that you have discl
On 03/10/17 17:50, Kathleen Wilson via dev-security-policy wrote:
On Friday, September 29, 2017 at 1:29:26 PM UTC-7, Rob Stradling wrote:
Several CAs have issued intermediate CA certificates with duplicate
serial numbers. This is a clear violation of the serial number
uniqueness requirement of
Hi Adriano. Thanks for providing your incident report so promptly.
Some questions inline...
On 02/10/17 15:26, Adriano Santoni via dev-security-policy wrote:
6) Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
In the particul
Several CAs have issued intermediate CA certificates with duplicate
serial numbers. This is a clear violation of the serial number
uniqueness requirement of the BRs and RFC5280 4.1.2.2. Below is a list
of all those known to crt.sh that chain to at least 1 NSS built-in root:
Issuer: http
On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:
I see, the one I saw in the wild was issued from the intermediate below and
linked to the Gandi document however it was from 2014. That said, I don't
see the intermediate in crt.sh though that could just be me failing to use
the site
On 21/09/17 22:56, richmoore44--- via dev-security-policy wrote:
On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:
Our CPS has now been updated.
Will you be ensuring that CAs like Gandi who are chaining back to your roots
also update their CPS?
Gandi are a managed C
On 08/09/17 20:24, Andrew Ayer via dev-security-policy wrote:
The BRs state:
"Effective as of 8 September 2017, section 4.2 of a CA's Certificate
Policy and/or Certification Practice Statement (section 4.1 for CAs
still conforming to RFC 2527) SHALL state the CA's policy or practice
on processin
On 11/09/17 15:30, Rob Stradling via dev-security-policy wrote:
Hi Hanno. Thanks for reporting this to us. We acknowledge the problem,
and as I mentioned at [1], we took steps to address it this morning.
We will follow-up with an incident report ASAP.
INCIDENT REPORT
We received two
Hi Hanno. Thanks for reporting this to us. We acknowledge the problem,
and as I mentioned at [1], we took steps to address it this morning.
We will follow-up with an incident report ASAP.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c3
On 11/09/17 15:18, Hanno Böck via dev-secur
Hi Conny. Are you able to post those 2 certificates to some CT logs and
provide crt.sh links?
You've said that both certs have the same SHA-1 Fingerprint. Are you
sure about that?
On 06/09/17 20:38, cornelia.enke66--- via dev-security-policy wrote:
SwissSign has identified the following in
Anyone who's using or planning to use these crt.sh APIs might like to
know that I've enhanced them to also run the ZLint certificate linter
(from https://github.com/zmap/zlint).
On 18/08/17 17:39, Rob Stradling via dev-security-policy wrote:
In response to the many BR compliance
In response to the many BR compliance issues [1] that have been reported
here this month, there's been renewed interest in certificate linting.
Various CAs have said that they're considering plugging one or more
certificate linters into their certificate issuance processes.
Some CAs, such as t
On 16/08/17 22:57, alex.gaynor--- via dev-security-policy wrote:
On Wednesday, August 16, 2017 at 11:22:01 AM UTC-4, Rob Stradling wrote:
BTW, I've just asked Alex to look at adding the "CA Owner" field to the
misissued.com reports. :-)
It does this now :-)
Excellent. Thanks Alex. :-)
--
On 15/08/17 13:29, Gervase Markham via dev-security-policy wrote:
Hi Rob,
On 26/07/17 11:21, Rob Stradling wrote:
https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing
Thanks for this. Any chance of saving me a bit of time by
cross-referencing ea
On 11/08/17 16:40, Nick Lamb via dev-security-policy wrote:
On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint)
On 26/07/17 11:44, Kurt Roeckx via dev-security-policy wrote:
On 2017-07-26 12:21, Rob Stradling wrote:
At Jonathan's suggestion, I've used the crt.sh DB to produce this
report of certs that have SAN:dNSName(s) that contain non-permitted
characters:
The report says "CN or dNSName". It's my un
At Jonathan's suggestion, I've used the crt.sh DB to produce this report
of certs that have SAN:dNSName(s) that contain non-permitted characters:
https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing
I've only looked at certs for which there's a ch
On 20/07/17 15:24, Gervase Markham via dev-security-policy wrote:
On 12/07/17 21:18, Ben Wilson wrote:
For CAs with emailProtection and proper name constraints, where would such CAs
appear in https://crt.sh/mozilla-disclosures?
https://crt.sh/mozilla-disclosures#constrainedother? Or a new se
s is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
Alex
On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
O
artment of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
Alex
On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 18/07/17 16:57, Hanno Böck via dev-security-pol
On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)
Here's a report of all "double dot" certs known t
On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote:
On 18/07/2017 16:19, Rob Stradling wrote:
On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni
Enhanced” which chains up to a Baltimore CyberTrust root, c
On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of
“www.intesasanpaolovita..biz” (note the two dots):
https://crt.sh/?q=2B9
CAs,
Version 2.5 of the Mozilla Root Store Policy classifies
EKU=emailProtection intermediates as unconstrained when suitable name
constraints aren't present. As a result, such intermediates need to be
disclosed to the CCADB (although not until 15th January 2018 for those
intermediates issue
On 05/07/17 18:08, Ryan Sleevi wrote:
On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham wrote:
That is, the difference between, say:
"label": "Verisign/RSA Secure Server CA"
And
CKA_LABEL "Verisign/RSA Secure Server CA"
I would argue there isn't a meaningful difference for "human readability",
a
icular root.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.or
means in the Mozilla policy to avoid the debate over this
particular root.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July
https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.
This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new
certificates, that a
On 27/06/17 01:36, Ryan Sleevi via dev-security-policy wrote:
On Mon, Jun 26, 2017 at 9:50 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
A few root store operators at the recent CAB Forum meeting informally
discussed the idea of a common format for
On 23/06/17 14:49, Peter Bowen via dev-security-policy wrote:
On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
wrote:
On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-23 14:59, Rob Stradling wrote:
Reasons:
- Some are only trusted by the
On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-23 14:59, Rob Stradling wrote:
Reasons:
- Some are only trusted by the old Adobe CDS program.
- Some are only trusted for Microsoft Kernel Mode Code Signing.
- Some are very old roots that are no longer trusted.
On 22/06/17 10:51, Rob Stradling via dev-security-policy wrote:
On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
Is this useful? if not, what key usage is interesting?
https://lock.cmpxchg8b.com/ServerOrAny.zip
Thanks for this, Tavis. I pointed my certscraper
(https
ct-tools check will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)
Alex
On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 16/06/17 20:11, A
[CC'ing rev...@digicert.com, as per
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00028]
Annie,
"but these have been known about and deemed acceptable for years"
Known about by whom? Deemed acceptable by whom?
On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
Is there an easy way to check which certificates from my set you're
missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
for fuzzing).
I collected these from p
On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
Hello, I was crawling the pkcs7 blobs in public pdf files and found some
intermediate certificates that don't appear in crt.sh.
I forwarded them to Rob, I don't know if this is useful to anyone else, but
they're available here.
htt
On 08/06/17 14:15, Rob Stradling via dev-security-policy wrote:
On 08/06/17 13:24, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL
Distribution Point URLs for each CA. The CDP URLs listed at
https
On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:
What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?
And would someone please post those alleged certificate chains
*explicitly* here, not just say they saw it "someho
On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:
On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy wrote:
On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy
wrote:
I don't believe that disclosure of root certificates is the responsibility
of
On 08/06/17 13:24, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL Distribution
Point URLs for each CA. The CDP URLs listed at
https://crt.sh/?id=12729173 were observed in other certs issued by
the
On 08/06/17 12:57, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-08 13:31, richmoor...@gmail.com wrote:
This one is interesting since the domain name of the CRL resolves to
an RFC 1918 IP address. Surely that is a violation of the baseline
requirements.
https://crt.sh/?sha256=b82210cd
On 06/06/17 22:26, Jakob Bohm wrote:
On 06/06/2017 22:08, Ryan Sleevi wrote:
Signing data is heavily reliant on CA competency, and that's in
unfortunately short supply, as the economics of the CA market make it
easy to fire all the engineers, while keeping the sales team, and
outsourcing the
On 06/06/17 14:22, Alex Gaynor via dev-security-policy wrote:
On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
Alex, do you have the specific list of CAs at the time of your posting?
Yes, it was:
* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start C
On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote:
Hi Kathleen. I'm not quite sure how to interpret this part...
- I'm not sold on the idea of requiring Symantec to use third-party CAs to
perform validation/issuance on Symantec's behalf. The most serious concerns
that I have
On 17/05/17 15:12, Gervase Markham wrote:
On 17/05/17 15:08, Rob Stradling wrote:
Incidentally, it's true that Mozilla have said that they don't care
about the Code Signing trust bit any more, but the
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
Yes, but a low prior
On 17/05/17 15:21, Gervase Markham via dev-security-policy wrote:
On 17/05/17 15:15, Rob Stradling wrote:
Shall I add the same two fields to
https://crt.sh/mozilla-disclosures#disclosureincomplete as well?
Yes, why not? :-)
Gerv
Done.
The "Listed Here Since" timestamps for the 24 intermedi
On 17/05/17 15:12, Gervase Markham via dev-security-policy wrote:
On 17/05/17 13:32, Rob Stradling wrote:
I've just added two columns to
https://crt.sh/mozilla-disclosures#undisclosed:
- "Earliest SCT".
- "Listed Here Since".
Lovely! Now we just need a cert to be on the list so we can se
On 17/05/17 14:43, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-17 14:40, Rob Stradling wrote:
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Ti
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are
On 11/05/17 18:05, Gervase Markham via dev-security-policy wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are currently provided in the public CSV rep
On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:
在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh
On 16/05/17 19:53, Ryan Sleevi via dev-security-policy wrote:
What is the advantage of that, given that PKCS#7 involves
BER, it introduces C/C2/C3, and you're still supplying the same number of
certs?
I don't think there is any notable advantage.
I asked the question because I thought it wou
On 16/05/17 16:11, Ryan Sleevi via dev-security-policy wrote:
On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
The important point in this is that
On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
The important point in this is that there should not be a non-linear path
of trust (which is implied, I think, by the reading of "group of
cross-certs"). But yes, there would be a linearized path.
If you *rely* on AIA, then why not
On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
Ryan,
If you look at the wide range of user agents accessing google.com today you'd
see many legacy applications and older versions of browsers and custom browsers
built from variants of the commercial browsers. By the time all/mo
On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
Just spitballing ideas here, but in Alex's case, part of me would be
tempted to see if X509 could be extended with a new "CanIssueUntil"
field. Basically, it would act as an off switch for CA:TRUE after a
given date, but certif
On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 13:07, Rob Stradling wrote:
It would seem that DigiCert noticed these 19 intermediates appear on
https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep,
because they've all now been disclosed to the CCADB.
T
Yesterday I knocked together a script that: scrapes a URL (or a list of
URLs) for certificate files; then attempts to build a trust chain (using
https://crt.sh/gen-add-chain) for each certificate found; then submits
to some CT logs any trust chains that crt.sh hasn't previously seen.
I've thro
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.
Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation c
On 06/05/17 10:25, Jesper Kristensen via dev-security-policy wrote:
Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.
Is that what you meant, Peter?
You cannot set up a CNAME without configuring Salesforce, since they
would not k
On 05/05/17 16:08, Gervase Markham via dev-security-policy wrote:
On 05/05/17 10:22, Rob Stradling wrote:
Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.
It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an intr
On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:
On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy wrote:
All,
I think it is time for us to change the domains that we are using for the CCADB
as follows.
Change the links for...
1) CAs to login to the CCAD
On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:
I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of the
On 01/05/17 18:33, Alex Gaynor via dev-security-policy wrote:
Hi Gerv,
One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
On 27/04/17 11:56, Inigo Barreira wrote:
Good to know that our new certs are there :-)
Regarding StartCom, these are the new certs we´ve generated and will be used
to apply for inclusion in the Mozilla root program. Nothing to disclose at
the moment I guess. We´ve not been audited yet nor applied
On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:
(Note: A few of the non-Symantec entries currently listed by
https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
think. It looks like Kathleen has marked some roots as "Removed" on
CCADB ah
On 25/04/17 23:50, Ryan Sleevi via dev-security-policy wrote:
Continuing to look through the audits, I happened to notice a few other
things that stood out, some more pressing than others.
More pressing:
I can find no disclosure with Salesforce or crt.sh of at least two CAs that
are listed 'in s
On 15/04/17 17:05, Peter Bowen via dev-security-policy wrote:
On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy wrote:
On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
On 13/04/17 14:23, Doug Beattie wrote:
There is no statement back to scope
Thanks Gerv. :-)
On 13/04/17 14:46, Gervase Markham via dev-security-policy wrote:
Hi Rob,
You either have a great memory or good search-fu; well done for digging
this out!
On 12/04/17 22:14, Rob Stradling wrote:
Gerv, FYI what you're proposing here
(https://github.com/mozilla/pkipolicy/issu
On 13/04/17 14:50, Gervase Markham wrote:
On 12/04/17 21:21, Rob Stradling wrote:
Mozilla also requires CAs to disclose intermediate cert revocations to
CCADB. Should there be a corresponding time limit in the policy
regarding how soon after revocation this disclosure must occur?
There is:
"
On 12/04/17 10:47, Gervase Markham via dev-security-policy wrote:
Section 5.3.1 of policy 2.4.1 defines what it means to be technically
constrained for email sub-CAs (those with id-kp-emailProtection). It says:
"If the certificate includes the id-kp-emailProtection extended key
usage, then a
On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote:
On 27/03/17 22:12, Andrew Ayer wrote:
[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67
]
This has now been added to the policy 2.5 draft with a one-week deadline.
Gerv
Gerv,
Mozilla also requir
On 30/03/17 13:11, Gervase Markham via dev-security-policy wrote:
On 28/03/17 12:21, Rob Stradling wrote:
Increased attack surface. An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being compromis
On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote:
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?
Actually, I think it
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
On 27/03/17 23:12, Andrew Ayer wrote:
My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away. If the sub-CA is created as a backup that i
On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:
It should also be made a requirement that the issued SubCA certificate
is provided to the CCADB and other root programs before providing it to
the SubCA owner/operator,
That'd be a bit difficult in the common case where the Sub-CA op
This currently unrevoked cert has the serverAuth EKU and
dNSName=qvsslrca3-v.quovadisglobal.com:
https://crt.sh/?id=83114602
Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=1333
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth
EKU and CN=hmrcset.trustis.com:
https://crt.sh/?id=50773741&opt=cablint
It lacks the SAN extension, but that doesn't excuse it from the ban on
SHA-1!
Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=9
101 - 198 of 198 matches
Mail list logo
