SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-15 Thread Rob Stradling via dev-security-policy
This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth EKU and CN=hmrcset.trustis.com: https://crt.sh/?id=50773741=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:

SHA-1 serverAuth cert issued by HydrantID (QuoVadis) in January 2017

2017-02-15 Thread Rob Stradling via dev-security-policy
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

Re: Grace Period for Sub-CA Disclosure

2017-03-28 Thread Rob Stradling via dev-security-policy
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

Re: Grace Period for Sub-CA Disclosure

2017-03-28 Thread Rob Stradling via dev-security-policy
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

Re: Grace Period for Sub-CA Disclosure

2017-03-30 Thread Rob Stradling via dev-security-policy
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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-04-12 Thread Rob Stradling via dev-security-policy
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

Re: Grace Period for Sub-CA Disclosure

2017-04-12 Thread Rob Stradling via dev-security-policy
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

Re: Grace Period for Sub-CA Disclosure

2017-04-13 Thread Rob Stradling via dev-security-policy
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:

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-04-13 Thread Rob Stradling via dev-security-policy
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

Re: Email sub-CAs

2017-04-19 Thread Rob Stradling via dev-security-policy
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

Re: Bad characters in dNSNames

2017-08-16 Thread Rob Stradling via dev-security-policy
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

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

2017-08-14 Thread Rob Stradling via dev-security-policy
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)

Re: Bad characters in dNSNames

2017-08-17 Thread Rob Stradling via dev-security-policy
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. :-)

Disclosing unconstrained emailProtection intermediates to CCADB

2017-07-07 Thread Rob Stradling via dev-security-policy
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

Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

2017-07-18 Thread Rob Stradling via dev-security-policy
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):

Re: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

2017-07-18 Thread Rob Stradling via dev-security-policy
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,

Re: How long to resolve unaudited unconstrained intermediates?

2017-07-21 Thread Rob Stradling via dev-security-policy
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

Re: Bad characters in dNSNames

2017-07-26 Thread Rob Stradling via dev-security-policy
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

Bad characters in dNSNames

2017-07-26 Thread Rob Stradling via dev-security-policy
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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Rob Stradling via dev-security-policy
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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Rob Stradling via dev-security-policy
L, one of the offending certs 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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Rob Stradling via dev-security-policy
tment 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-polic

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-04 Thread Rob Stradling via dev-security-policy
r this particular 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.mozill

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-03 Thread Rob Stradling via dev-security-policy
ozilla 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 3, 2017 5:32 AM To:

DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-03 Thread Rob Stradling via dev-security-policy
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

Re: Machine- and human-readable format for root store information?

2017-07-05 Thread Rob Stradling via dev-security-policy
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",

Re: Symantec Conclusions and Next Steps

2017-04-26 Thread Rob Stradling via dev-security-policy
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

Re: Symantec Conclusions and Next Steps

2017-04-27 Thread Rob Stradling via dev-security-policy
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 C

Re: Symantec Conclusions and Next Steps

2017-04-27 Thread Rob Stradling via dev-security-policy
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

TBSCertificate / Certificate Linting APIs

2017-08-18 Thread Rob Stradling via dev-security-policy
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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

2017-05-11 Thread Rob Stradling via dev-security-policy
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

Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Rob Stradling via dev-security-policy
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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Rob Stradling via dev-security-policy
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.

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-16 Thread Rob Stradling via dev-security-policy
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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-16 Thread Rob Stradling via dev-security-policy
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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

2017-05-17 Thread Rob Stradling via dev-security-policy
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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-16 Thread Rob Stradling via dev-security-policy
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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-17 Thread Rob Stradling via dev-security-policy
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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-17 Thread Rob Stradling via dev-security-policy
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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-17 Thread Rob Stradling via dev-security-policy
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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-17 Thread Rob Stradling via dev-security-policy
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,

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-17 Thread Rob Stradling via dev-security-policy
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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-16 Thread Rob Stradling via dev-security-policy
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

Re: New undisclosed intermediates

2017-06-12 Thread Rob Stradling via dev-security-policy
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

Re: New undisclosed intermediates

2017-06-09 Thread Rob Stradling via dev-security-policy
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:

Re: New undisclosed intermediates

2017-06-09 Thread Rob Stradling via dev-security-policy
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

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

2017-06-20 Thread Rob Stradling via dev-security-policy
[CC'ing rev...@digicert.com, as per https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028] Annie, "but these have been known about and deemed acceptable for years" Known about by whom? Deemed acceptable by whom? Until

Re: Unknown Intermediates

2017-06-22 Thread Rob Stradling via dev-security-policy
cert2.pem, ...> 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

Re: Unknown Intermediates

2017-06-23 Thread Rob Stradling via dev-security-policy
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 <dev-security-policy@lists.mozilla.org> wrote: On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote: On 2017-06-23 14:59, Rob Stradling wrote: R

Re: Unknown Intermediates

2017-06-23 Thread Rob Stradling via dev-security-policy
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.

Re: Unknown Intermediates

2017-06-23 Thread Rob Stradling via dev-security-policy
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

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-19 Thread Rob Stradling via dev-security-policy
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

Re: Google Plan for Symantec posted

2017-05-19 Thread Rob Stradling via dev-security-policy
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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-16 Thread Rob Stradling via dev-security-policy
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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-07 Thread Rob Stradling via dev-security-policy
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

Re: New undisclosed intermediates

2017-06-08 Thread Rob Stradling via dev-security-policy
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.

Re: Unknown Intermediates

2017-06-16 Thread Rob Stradling via dev-security-policy
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.

Re: Changing CCADB domains

2017-05-08 Thread Rob Stradling via dev-security-policy
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

Re: Symantec: Draft Proposal

2017-05-02 Thread Rob Stradling via dev-security-policy
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

Re: Changing CCADB domains

2017-05-05 Thread Rob Stradling via dev-security-policy
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

Re: Changing CCADB domains

2017-05-05 Thread Rob Stradling via dev-security-policy
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

Re: CA Validation quality is failing

2017-05-02 Thread Rob Stradling via dev-security-policy
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

Re: New undisclosed intermediates

2017-06-06 Thread Rob Stradling via dev-security-policy
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

Re: Machine- and human-readable format for root store information?

2017-06-27 Thread Rob Stradling via dev-security-policy
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

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-22 Thread Rob Stradling via dev-security-policy
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

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-22 Thread Rob Stradling via dev-security-policy
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

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-21 Thread Rob Stradling via dev-security-policy
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

Re: Doppelganger/tripleganger intermediate certificates

2017-10-04 Thread Rob Stradling via dev-security-policy
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

Re: Doppelganger/tripleganger intermediate certificates

2017-10-04 Thread Rob Stradling via dev-security-policy
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

Re: Doppelganger/tripleganger intermediate certificates

2017-10-10 Thread Rob Stradling via dev-security-policy
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

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

2017-10-16 Thread Rob Stradling via dev-security-policy
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.

Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

2017-10-17 Thread Rob Stradling via dev-security-policy
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

Re: Lack of CAA checking at Comodo

2017-09-11 Thread Rob Stradling via dev-security-policy
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

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

2017-09-06 Thread Rob Stradling via dev-security-policy
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

Incident Report - CAA misissuance (was Re: Lack of CAA checking at Comodo)

2017-09-12 Thread Rob Stradling via dev-security-policy
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

Re: Doppelganger/tripleganger intermediate certificates

2017-10-02 Thread Rob Stradling via dev-security-policy
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

Doppelganger/tripleganger intermediate certificates

2017-09-29 Thread Rob Stradling via dev-security-policy
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:

Re: TBSCertificate / Certificate Linting APIs

2017-09-04 Thread Rob Stradling via dev-security-policy
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 issues [1

ROCA fingerprints found on crt.sh (was Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards)

2017-10-18 Thread Rob Stradling via dev-security-policy
/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 fingerprint

Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

2017-11-24 Thread Rob Stradling via dev-security-policy
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

Re: On the value of EV

2017-12-14 Thread Rob Stradling via dev-security-policy
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

Fox-IT hack (was Re: On the value of EV)

2017-12-15 Thread Rob Stradling via dev-security-policy
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

Re: Incident report - ROCA fingerprints in certificates issued by Comodo CA (was Re: RSA key generation vulnerability in Infineon firmware)

2017-11-09 Thread Rob Stradling via dev-security-policy
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 found

Re: Incident report - ROCA fingerprints in certificates issued by Comodo CA (was Re: RSA key generation vulnerability in Infineon firmware)

2017-11-09 Thread Rob Stradling via dev-security-policy
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 will get

Re: DigiCert ROCA fingerprint incident report

2017-11-08 Thread Rob Stradling via dev-security-policy
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

OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

2017-12-11 Thread Rob Stradling via dev-security-policy
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: Unrevoked/unexpired certificate with Debian Weak Key

2018-05-14 Thread Rob Stradling via dev-security-policy
On 14/05/18 11:39, Jakob Bohm via dev-security-policy wrote: On 14/05/2018 10:42, Hanno Böck wrote: Hi, Yesterday was the 10y anniversary of the Debian OpenSSL random number generator bug. A few days ago I did a re-check of the CT logs for vulnerable keys. I found one unexpired, unrevoked

Re: Mis-issuance of certificate with https in CN/SAN

2018-05-09 Thread Rob Stradling via dev-security-policy
On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote: On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote: Please see https://crt.sh/?id=353098570=cablint Note: This is the CT precertificate. Note 2: According to crt.sh, the OCSP response for this precertificate

Re: Unrevoked/unexpired certificate with Debian Weak Key

2018-06-18 Thread Rob Stradling via dev-security-policy
On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote: On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling I'm currently running the check against all of the certs on the crt.sh DB. I'll report back once this has completed. Hi Rob, Did your checks find anything else in the end?

CCADB disclosure of id-kp-emailProtection intermediates

2018-01-16 Thread Rob Stradling via dev-security-policy
[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

Re: Add Wayne Thayer as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

2018-01-17 Thread Rob Stradling via dev-security-policy
+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

Re: Compromised certificate for localhost.cmdm.comodo.net / Comodo ITSM

2018-01-12 Thread Rob Stradling via dev-security-policy
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

Re: Certificate for com and it

2018-02-08 Thread Rob Stradling via dev-security-policy
On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote: On 08/02/18 13:47, Hanno Böck wrote: Is a revoked intermediate cert a license for operating a yolo CA that signs everything? Given the fragility of revocation checking I'd find that a problematic precedent. In this case, the

Re: GlobalSign certificate with far-future notBefore

2018-01-24 Thread Rob Stradling via dev-security-policy
On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date This incident makes me think that two changes should be made: 1) The Root Store Policy should explicitly ban forward and

Re: CCADB disclosure of id-kp-emailProtection intermediates

2018-01-17 Thread Rob Stradling via dev-security-policy
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, 2018 2:29 PM To: m

Re: Camerfirma's misissued certificate

2018-01-18 Thread Rob Stradling via dev-security-policy
Hi Juan. Is there a particular technical reason why you feel the need to include "all the certs chaining up to the roots" in your OCSP responses? When an OCSP response is signed directly by the CA that issued the corresponding certificate, the OCSP response does not need to contain any

Re: How do you handle mass revocation requests?

2018-03-01 Thread Rob Stradling via dev-security-policy
On 01/03/18 10:51, Ben Laurie via dev-security-policy wrote: On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Wed, 28 Feb 2018 20:03:51 + Jeremy Rowley via dev-security-policy wrote:

Re: Mis-issuance of certificate with https in CN/SAN

2018-03-16 Thread Rob Stradling via dev-security-policy
On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote: Please see https://crt.sh/?id=353098570=cablint Note: This is the CT precertificate. Note 2: According to crt.sh, the OCSP response for this precertificate is not correct.  (error message: "OCSP response contains bad number of

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

2018-04-20 Thread Rob Stradling via dev-security-policy
On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote: First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

2018-04-22 Thread Rob Stradling via dev-security-policy
On 22/04/18 21:04, Eric Mill via dev-security-policy wrote: On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: First of all, it's important to distinguish between the BR r But even if you accept my premise there, then you have

  1   2   >