Re: Mozilla's Response to Camerfirma's Compliance Issues

[Jonathan Rudenberg via dev-security-policy]

On Tue, Jan 26, 2021, at 00:21, Ben Wilson via dev-security-policy wrote:
> 
> - Do the proposed actions in the Remediation Plan address the underlying
> issues?
> 
> - If Camerfirma fully executes on this plan, will that be sufficient to
> regain trust so that they can remain a CA in Mozilla's root store?
> 
> - Do you have additional recommendations for steps that you think
> Camerfirma should take?

Given the history of major failures and inadequate response over a long period 
of time, I don't believe that there is a remediation plan that can work here.

Mozilla should move forward with distrusting this CA.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Camerfirma's Compliance Issues

[Jonathan Rudenberg via dev-security-policy]

On Tue, Jan 19, 2021, at 12:01, Andrew Ayer via dev-security-policy wrote:
> Camerfirma was warned in 2018 that trust in their CA was in jeopardy,
> yet compliance problems continued.  There is no reason to believe
> Camerfirma will improve, and there are many indications that they won't.
> Mozilla's users deserve CAs that take security more seriously than this.
> It's time to take action to protect Mozilla's users by distrusting
> Camerfirma.

I strongly agree. The consistent pattern of documented failures and 
insufficient remediation is deeply problematic, and reflects a level of danger 
to Mozilla users that can only be mitigated by distrusting the CA.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Jonathan Rudenberg via dev-security-policy]

On Tue, Aug 11, 2020, at 15:20, nathali...--- via dev-security-policy wrote:

> The problem report was answered by Let's Encrpyt with an answer 
> indicating that they will continue to issue and hence are not following 
> BRG 4.2.1. requiring them to have procedures in place for such High 
> Risk Certificate Requests.

Not revoking this certificate and continuing issuance does not indicate that 
they are not complying with the Baseline Requirements.

> The CA SHALL develop, maintain, and implement documented procedures that 
> identify and require additional verification activity for High Risk 
> Certificate Requests prior to the Certificate’s approval, as reasonably 
> necessary to ensure that such requests are properly verified under these 
> Requirements.

The issuance of a specific certificate doesn't indicate that they don't have 
the required "documented procedures" in place. There is no language in the 
Baseline Requirements or Mozilla Requirements that require specific criteria or 
procedures for High Risk Certificate Requests. However, since their CA software 
is open source, we can confirm that they do in fact have procedures implemented 
for High Risk Certificate Requests: 
https://github.com/letsencrypt/boulder/blob/e2c8f6743a3c3539a75ee59b8e3c152e069a7a1e/policy/pa.go#L53-L73

The Baseline Requirements and Mozilla Requirements also do not have any 
requirements to revoke or block future issuance in cases like this, so I don't 
see any "malpractise" or policy violations here.

> So the question now is what the community intends to do to retain trust 
> in a certificate issuer with such an obvious malpractise enabling 
> phishing sites?

TLS is the wrong layer to address phishing at, and this issue has already been 
discussed extensively on this list. This domain is already blocked by Google 
Safe Browsing, which is the correct layer (the User Agent) to deal with 
phishing at. I'd suggest reading through these posts before continuing so that 
we don't waste our time rehashing old arguments: 
https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Jonathan Rudenberg via dev-security-policy]

On Sun, Apr 19, 2020, at 17:41, Ben Wilson via dev-security-policy wrote:
> Recently at least one CA has expressed concern about Action 3 of Mozilla's
> January 2020 CA Communication [3] and enforcement of Section 5.2 of
> Mozilla’s Root Store Policy

Please have the CA post complete details of their concerns publicly on the 
list. Unlike other root programs, the Mozilla program operates publicly on this 
list and in Bugzilla, as guided by Principle 8 of the Mozilla Manifesto: 
"Transparent community-based processes promote participation, accountability 
and trust." 
 
> Some CAs (and their customers) located in Japan, the U.S., and elsewhere
> are dealing with new priorities that were not apparent back in January.  Some
> have had to reorganize to deal with reduced staff and reallocate resources,
> while other companies have modified their schedules to delay changes that
> might cause instability.[5], [6]

While this may be true generally, it's not clear how this applies to the 
specific case of the EKU requirement. It is important to hear from CAs that 
have not implemented this change yet (if any) with far more detail before 
jumping to the conclusion that changes need to be made to the requirement. 
Given that this is an extremely simple requirement codifying already widely 
implemented best practices that was known many weeks before the impact of 
COVID-19 was felt in most places, it's not immediately clear why it should be a 
problem to deploy with over two months left before the deadline.

> For some parties, the benefit of a 3-month delay (to 1-October-2020) in
> enforcement of Mozilla’s EKU requirement may result in more flexibility,
> resilience and secure operations.

It's not clear to me how changing the EKU field in a certificate profile would 
impact resilience or security. I think it would be more productive to have 
specific public discussions with CAs about challenges in implementing this 
change by the deadline instead of speculating about possible issues.

> Several options are being considered:

Given the complete lack of public discussion about this deadline being a 
problem, I don't think discussing options for a problem that hasn't been 
established as existing yet is productive. Additionally, as Ryan points out, 
most of these options are not compatible with how the program has operated to 
date.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Germany's cyber-security agency [BSI] recommends Firefox as most secure browser

[Jonathan Rudenberg via dev-security-policy]

Hi Kirk,

On Thu, Oct 17, 2019, at 19:53, Kirk Hall via dev-security-policy wrote:
> I hope the Mozilla community will celebrate this honor, but will also 
> reconsider its proposal to drop support for EV certificates – that 
> would mean that Firefox no longer meets all BSI requirements for a 
> secure browser.

I'm not sure where you're getting this information, there has been no proposal 
to drop support for EV certificates. Can you point me to your source for this?

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: An honest viewpoint: Move Extended Validation Information out of the URL bar

[Jonathan Rudenberg via dev-security-policy]

On Wed, Sep 4, 2019, at 14:53, browserpadlock--- via dev-security-policy wrote:
> It seems that the Certificate Authorities are doing their jobs quite 
> well in regards to EV certs and making sure that it is very difficult 
> for non-qualified/verified sites to get them according to a recently 
> concluded study by Georgia Tech CyFI Lab 
> (https://www.helpnetsecurity.com/2019/08/01/ev-ssl-certificate/), a 
> well respected technical institution, NOT funded by the CA industry.

This paper was paid for by Sectigo, this was clearly noted in their press 
release:
https://sectigo.com/blog/new-research-in-ev-ssl-security-from-georgia-tech-ev-domains-99-99-free-of-online-crime

The methodology is deeply flawed, for example these are some of the "malicious" 
domains from their dataset:

extended-validation-ssl.websecurity.symantec.com
hotmail.co.jp
math.northwestern.edu
downloads.comodo.com

 (there are a bunch more but I don't really care enough to keep going)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jonathan Rudenberg via dev-security-policy]

On Mon, Aug 26, 2019, at 20:44, Jakob Bohm via dev-security-policy wrote:
> On 26/08/2019 21:49, Jonathan Rudenberg wrote:
> > On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
> >>  and
> >>  both took advantage of weaknesses in two
> >> government registries to create actual dummy companies with misleading
> >> names, then trying to get EV certs for those (with mixed success, as at
> >> least some CAs rejected or revoked the certs despite the government
> >> failures).
> > 
> > There were no "weaknesses" or "government failures" here, everything was 
> > operating exactly as designed.
> > 
> 
> The weakness is that those two government registries don't prevent 
> conflicting or obviously bad registrations, not even by retroactively 
> aborting the process in a few business days.
> 
> Even without the Internet this constitutes an obvious avenue for frauds.

There was no conflict. In the US, each state has unique laws around 
incorporation of entities. There is certainly no requirement that you can't 
have a corporate entity with the same name in two different states. There was 
nothing "conflicting" or "obviously bad" about Ian's corporation.

> >> At least the first of those demonstrations involved a no
> >> longer trusted CA (Symantec).
> > 
> > This doesn't appear to be relevant. The process followed was compliant with 
> > the EVGLs, and Symantec was picked because they were one of the most 
> > popular CAs at the time.
> > 
> 
> Symantec was distrusted for sloppy operation, that document version 
> (which we have since been informed was not the final version) claimed 
> that the only other CA tried did in fact reject the cert application, 
> indicating that issuing may not have been following "best current 
> practice" at the time.  The revised link posted tonight reverses this 
> information.

The original decision not to issue an EV certificate by Comodo was arbitrary 
and not based on any documented practices or guidelines. Additionally, as James 
mentioned and you can see here, Comodo issued the certificate: 
https://crt.sh/?id=438718367

> > 
> >> Both demonstrations caused the
> >> researchers real name and identity to become part of the CA record,
> >> which was hand waved away by claiming that could have been avoided by
> >> criminal means.
> > 
> > It's not handwaving to make the assertion that a fraudster would be willing 
> > to commit fraud while committing fraud. Can you explain why you think this 
> > argument is flawed?
> > 
> 
> The EVG requires the CA to attempt to verify the personal identity 
> information.  Stating without evidence that this verification is easily 
> defrauded is hand waving it away.

This is incorrect, Private Organization subjects (EVG 8.5.2) do not require any 
individual identity verification. Additionally, assuming that "personal 
identity information" can be validated without the opportunity for fraud has no 
basis in reality.

> >> Studies quoted by Tom Ritter on 24/08/2019:
> >>
> >>>
> >>> "By dividing these users into three groups, our controlled study
> >>> measured both the effect of extended validation certificates that
> >>> appear only at legitimate sites and the effect of reading a help file
> >>> about security features in Internet Explorer 7. Across all groups, we
> >>> found that picture-in-picture attacks showing a fake browser window
> >>> were as effective as the best other phishing technique, the homograph
> >>> attack. Extended validation did not help users identify either
> >>> attack."
> >>>
> >>> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> >>>
> >>
> >> 12 years old study involving en equally outdated browser.
> > 
> > Can you explain why you believe the age this study is disqualifying? What 
> > components of the study do you believe are no longer valid due to their 
> > age? Are you aware of subsequent studies showing different results?
> > 
> 
> IE7 may have had a bad UI since changed.  12 years ago, there had not 
> been any big outreach campaigns telling users to look for the green bar, 
> nor a 10 year build up of user expectation that it would be there for 
> such sites.
>

Can you provide some references to these "big outreach campaigns" and 
documentation of the "build up of user expectation"?

> >>> "Our results showed that the identity indicators used in the
> >>> unmodified FF3browser did not influence decision-making for the
> >>> participants in our study interms of user trust in a web site. These
> >>> new identity indicators were ineffectivebecause none of the
> >>> participants even noticed their existence."
> >>>
> >>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf
> >>>
> >>
> >> An undated(!) study involving highly outdated browsers.  No indication
> >> this was ever in a peer reviewed journal.
> > 
> > This is a peer-reviewed paper that was published in the 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jonathan Rudenberg via dev-security-policy]

On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
>  and
>  both took advantage of weaknesses in two
> government registries to create actual dummy companies with misleading
> names, then trying to get EV certs for those (with mixed success, as at
> least some CAs rejected or revoked the certs despite the government
> failures).

There were no "weaknesses" or "government failures" here, everything was 
operating exactly as designed.


> At least the first of those demonstrations involved a no
> longer trusted CA (Symantec).

This doesn't appear to be relevant. The process followed was compliant with the 
EVGLs, and Symantec was picked because they were one of the most popular CAs at 
the time.


> Both demonstrations caused the
> researchers real name and identity to become part of the CA record,
> which was hand waved away by claiming that could have been avoided by
> criminal means.

It's not handwaving to make the assertion that a fraudster would be willing to 
commit fraud while committing fraud. Can you explain why you think this 
argument is flawed?


> Studies quoted by Tom Ritter on 24/08/2019:
> 
> > 
> > "By dividing these users into three groups, our controlled study
> > measured both the effect of extended validation certificates that
> > appear only at legitimate sites and the effect of reading a help file
> > about security features in Internet Explorer 7. Across all groups, we
> > found that picture-in-picture attacks showing a fake browser window
> > were as effective as the best other phishing technique, the homograph
> > attack. Extended validation did not help users identify either
> > attack."
> > 
> > https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> > 
> 
> 12 years old study involving en equally outdated browser.

Can you explain why you believe the age this study is disqualifying? What 
components of the study do you believe are no longer valid due to their age? 
Are you aware of subsequent studies showing different results?


> > "Our results showed that the identity indicators used in the
> > unmodified FF3browser did not influence decision-making for the
> > participants in our study interms of user trust in a web site. These
> > new identity indicators were ineffectivebecause none of the
> > participants even noticed their existence."
> > 
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf
> > 
> 
> An undated(!) study involving highly outdated browsers.  No indication
> this was ever in a peer reviewed journal.

This is a peer-reviewed paper that was published in the proceedings of ESORICS 
2008: 13th European Symposium on Research in Computer Security, Málaga, Spain, 
October 6-8, 2008. Dates are actually (unfortunately) uncommon on CS papers 
unless the publication metadata/frontmatter is intact.


> > DV is sufficient. Why pay for something you don't need?
> > 
> 
> Unproven claim, especially by studies from before free DV without
> traceable credit card payments became the norm.

I don't follow your argument here. The evidence shows that DV is sufficient for 
phishing, as has been repeatedly explained on this thread.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jonathan Rudenberg via dev-security-policy]

On Fri, Aug 16, 2019, at 07:56, Doug Beattie via dev-security-policy wrote:
> Peter,
> 
> I'm not claiming that EV reduces phishing globally, just for those sites
> that use them. Do you have a chart that breaks down phishing attacks by SSL
> certificate type? 
> 
> Here is some research that indicates EV sites have a reduced phishing
> percentage, so customers accessing EV protected sites are safer:
> https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf

Doug,

Can you point me to the specific research you're referring to? All I see in 
this presentation that's remotely relevant is a breakdown of the certificate 
types used on detected phishing sites across a couple months. If this data is 
correct, it doesn't seem to be useful information, and actually proves one of 
the points that is behind the removal of EV UI.

If EV is required for a successful phishing attack, then attackers will just 
get EV certificates. But all of the research that has been repeatedly brought 
up in this thread shows that users don't use the EV UI when making decisions 
about whether to trust a website, explaining why phishing sites don't use EV 
very much.

Additionally, the idea that sites that use EV experience less phishing seems 
deeply flawed. Banks are a huge target for phishing, and most of their websites 
have EV certificates.

An interesting and clear recent example of this is PayPal, which is obviously a 
very popular target for phishing. paypal.com technically has an EV certificate, 
but due to the certificate chain used since early 2018, the EV UI does not show 
up in the most popular browser (Chrome) on the most popular desktop operating 
system (Windows)[1]. Given the amount of phishing that PayPal experiences, it 
seems likely to me that they would have figured out how to fix this if they 
thought it was worth the effort. They haven't.

Jonathan

[1] 
https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certinomis Issues

[Jonathan Rudenberg via dev-security-policy]

On Tue, May 7, 2019, at 19:48, Wayne Thayer via dev-security-policy wrote:
>2.
> 
>Constrain it to use for gouv.fr domains in an upcoming Firefox release.
> 
> 
> While there are only a few thousand unexpired TLS certificates (the root is
> not trusted for email) known to chain to this root, a few are in use by
> major French government websites (e.g. ants.gouv.fr). I have suggested
> option #2 to minimize disruption to those subscribers and relying parties.
> 
> I will greatly appreciate everyone’s input on my recommendation and the
> proposed options.


Hi Wayne,

My preference would be removing the root entirely. So far there have been no 
requests from either the CA or any subscribers for special treatment of 
specific sites or certificates. If Certinomis isn't trustworthy (which I think 
is documented in the current record), why should a high assurance use case 
(government websites) be special cased as trusted?

It's also worth noting that the certificate issued for ants.gouv.fr has a three 
year validity period, and the lower we push validity periods, the lower the 
impact is for removing individual CAs from root stores.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CFCA certificate with invalid domain

[Jonathan Rudenberg via dev-security-policy]

On Fri, Mar 15, 2019, at 10:58, bstephens822--- via dev-security-policy wrote:
> On Wednesday, February 27, 2019 at 10:28:00 AM UTC-5, 
> michel.le...@gmail.com wrote:
> > Hello,
> > 
> > I noticed this certificate 
> > https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an 
> > invalid domain `mail.xinhua08.con` in SANs. This looks like a typo and 
> > `mail.xinhua08.com` is present in other certificates. Such an issue makes 
> > me wonder about the quality of their validation.

I've noted this on a similar bug and asked for details: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1524733
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jonathan Rudenberg via dev-security-policy]

Hi Scott,

On Tue, Mar 5, 2019, at 09:02, Scott Rea via dev-security-policy wrote:
> 
> • DM has resolved all technical and policy issues raised in the UAE and 
> DM Roots submission process on Mozilla list: see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
> 
> • Since the inception of the DM CA we have had two technical compliance 
> issues during its three years of operation, both were addressed 
> immediately and resolved.

Your count is incorrect. This certificate was misissued and appears to be a 
third incident that is not mentioned in your summary: 
https://crt.sh/?id=271084003=zlint

> • The first was that DM misissued 2 TLS certificates that were not in 
> compliance with the BRs as reported by Rob Stradling - specifically the 
> FQDN listed in the CN was not also included in the SAN. The 2 offensive 
> certs were already flagged by DM and were held and revoked and were 
> only in existence for approximately 18hrs and at NO TIME were they LIVE 
> on the internet protecting any services. They were promptly replaced by 
> properly attributed BR-compliant certificates. Comment 31 of the UAE 
> and DM Root inclusion Bug is where the two misissued certs were 
> documented see https://bugzilla.mozilla.org/show_bug.cgi?id=1427262

Since we are summarizing, it's worth noting again that no incident report was 
provided, one was requested in this comment: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c32

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jonathan Rudenberg via dev-security-policy]

On Tue, Feb 26, 2019, at 10:06, Scott Rea via dev-security-policy wrote:
> G’day Folks,
> 
> DarkMatter CEO (Karim Sabbagh), has provided an official response to 
> Mozilla on the recent media article about the UAE that referenced 
> security and intelligence matters. Per Wayne’s request to potentially 
> share this on the list, I am attaching a copy of that letter to this 
> post.

Since attachments tend to not come through on this list, here's a link: 
https://bugzilla.mozilla.org/attachment.cgi?id=9046699

This statement does not appear to me to directly deny any of the media reports, 
it simply calls them "misleading". There is no  standard definition for 
"defensive cyber activities", which could mean a lot of things.

As far as I know DarkMatter has not provided a comment directly to Reuters at 
all, let alone denied the report.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jonathan Rudenberg via dev-security-policy]

On Fri, Feb 22, 2019, at 16:21, Wayne Thayer via dev-security-policy wrote:
> Despite the lack of
> direct evidence of misissuance by DarkMatter, this may be a time when we
> should use our discretion to act in the interest of individuals who rely on
> our root store.

It's worth noting that DarkMatter has already been documented to have misissued 
certificates, though not in a way that is obviously for malicious purposes.

1)  As discovered by Rob Stradling[1], they issued at least two certificates 
with a CN that was not included in the SAN extension. An incident report was 
requested[2], but I was unable to find it in Bugzilla or on this mailing list.

2) https://crt.sh/?id=271084003=zlint - This certificate has an invalid 
domain `apiuat.o`. I'm not aware of prior discussion about this.

With regards to the broader question, I believe that DarkMatter's alleged 
involvement with hacking campaigns is incompatible with operating a trustworthy 
CA. This combined with the existing record of apparent incompetence by 
DarkMatter (compare the inclusion bugs for other recently approved CAs for 
contrast), makes me believe that the approval request should be denied and the 
existing intermediates revoked via OneCRL. I don't see how approving them, or 
the continued trust in their intermediates, would be in the interests of 
Mozilla's users or compatible with the Mozilla Manifesto.

Jonathan

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c29
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c32
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: P-521 Certificates

[Jonathan Rudenberg via dev-security-policy]

On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote:
> (Posting in a personal capacity as I am no longer employed by Trustwave)
> 
> Mozilla Root Store Policy section 5.1 
> (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
>  
> prohibits the use of P-521 keys in root certificates included in the 
> Mozilla trust store, as well as in any certificates chaining to these 
> roots. This prohibition was made very clear in the discussion on this 
> list in 2017 at 
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC8/fsKobHABAwAJ.
>  
> 
> Below is a list of unexpired, unrevoked certificates which contain P-521 
> public keys (grouped by CA Owner and ordered by notBefore):

I've created https://misissued.com/batch/43/ to track these.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[Jonathan Rudenberg via dev-security-policy]

Oops, I missed item 1, disregard :)

On Fri, May 18, 2018, at 13:45, Jonathan Rudenberg via dev-security-policy 
wrote:
> On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote:
> > 2. Performing a scan of current CAA records for the domain names we have 
> > issued for in the past 90 days, specifically looking for tags in CAA 
> > records with non-lowercase characters. We’ll examine such instances on a 
> > case-by-case basis to determine the appropriate action.
> 
> Do you log the full CAA record set (if any) for each authorized domain? 
> If so, can you use those instead of the "current" records to find 
> potentially unauthorized issuance?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[Jonathan Rudenberg via dev-security-policy]

On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote:
> 2. Performing a scan of current CAA records for the domain names we have 
> issued for in the past 90 days, specifically looking for tags in CAA 
> records with non-lowercase characters. We’ll examine such instances on a 
> case-by-case basis to determine the appropriate action.

Do you log the full CAA record set (if any) for each authorized domain? If so, 
can you use those instead of the "current" records to find potentially 
unauthorized issuance?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Jonathan Rudenberg via dev-security-policy]

On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy wrote:
> It was injudicious of a CA to issue another certificate in this name for
> this entity after the already well documented controversy.  Did they just
> not care that it would invite trouble or did they not know that it would
> invite controversy and trouble because they didn't track it the first time
> around?

What "trouble" is being invited? I don't see a problem. Everything is operating 
exactly as expected. GoDaddy did nothing wrong.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Jonathan Rudenberg via dev-security-policy]

On Wed, Apr 11, 2018, at 14:48, Matthew Hardeman via dev-security-policy wrote:
> Additionally, I think it's fair to say that I'm aghast that another CA 
> (who by their inclusion in the Mozilla root program has agreed to stay 
> abreast of developments on this list) has issued for the exact same 
> entity and name that already led to significant controversy covered on 
> this list less than a year ago.

This is a real legal entity, which almost certainly went through proper EV 
validation. Everything appears to be in order.

> I believe that speaks to inattention to the list or failure to 
> incorporate lessons learned from controversies on this list into 
> issuance and/or validation practice.

I strongly disagree. Everything is operating correctly. Corporate entity names 
are not unique, which is why EV is not useful. There were no lessons to be 
learned from the previous thread other than the fact that EV does not provide 
any useful guarantees to Mozilla's users.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com>
> wrote:
> 
>> 
>>> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> 
>>>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>> 
>>>> This request has been in public discussion for more than 6 months, so I
>>>> would like to make a decision soon. If you have comments or concerns
>> with
>>>> this request, please post them here by 6-March 2018.
>>> 
>>> Given the misissued certificates in CT under the existing root, I
>> believe this request should be rejected, and a new clean root with audits
>> should be required before moving forward.
>>> 
>> 
> This course of action doesn't seem consistent with our treatment of the
> many included CAs that have experienced these problems.

Given that revocation checking doesn’t work, and CT doesn’t provide a complete 
picture, especially without browser enforcement, accepting this root would have 
the result of exposing Mozilla's users to certificates that are known to be 
misissued.

I realize that some inclusion requests have been accepted in the past despite 
existing misissued certificates, but I don’t think that is sufficient 
justification for continuing to do so. Why shouldn’t we require CAs to cut a 
new root when the data indicates that accepting the existing root will put 
users at risk?

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> 
>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy 
>> <dev-security-policy@lists.mozilla.org> wrote:
>> 
>> This request has been in public discussion for more than 6 months, so I
>> would like to make a decision soon. If you have comments or concerns with
>> this request, please post them here by 6-March 2018.
> 
> Given the misissued certificates in CT under the existing root, I believe 
> this request should be rejected, and a new clean root with audits should be 
> required before moving forward.
> 
> The errors in the issued certificates indicate a lack of technical controls 
> in addition to improperly implemented certificate profiles. Given this, an 
> explanation should also be provided of what changes have been made to the 
> issuance environment to ensure these types of mistakes will not happen under 
> the new root.

I just took a closer look at the thread, and it appears that some misissuance 
was pointed out in July and most of the controls that were suggested as a 
solution relied on humans. These controls appear to have predictably failed, as 
multiple misissued certificates are from this fall, well after the fixes should 
have been in place.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> This request has been in public discussion for more than 6 months, so I
> would like to make a decision soon. If you have comments or concerns with
> this request, please post them here by 6-March 2018.

Given the misissued certificates in CT under the existing root, I believe this 
request should be rejected, and a new clean root with audits should be required 
before moving forward.

The errors in the issued certificates indicate a lack of technical controls in 
addition to improperly implemented certificate profiles. Given this, an 
explanation should also be provided of what changes have been made to the 
issuance environment to ensure these types of mistakes will not happen under 
the new root.

There are a bunch of warnings, but these jumped out at me as being very serious:

These certificates have a commonName that is not included as a dNSName SAN:

- https://crt.sh/?id=99182607=cablint
- https://crt.sh/?id=242366304=cablint

This certificate has a SAN with a domain ending in .local, which is a reserved 
special-use TLD:

- https://crt.sh/?id=79470561=cablint

It’s important to remember that these are only the certificates that we know 
about via CT. There may be certificates with similar or other issues that are 
not logged.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public trust of VISA's CA

[Jonathan Rudenberg via dev-security-policy]

> On Feb 13, 2018, at 19:16, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg 
> wrote:
> 
>> 
>>> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> In the light of this, I believe it is reasonable to discuss the question
>>> of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
>>> https://crt.sh/?id=896972 , which is the one includes in our store)
>>> meets the criteria for inclusion in Mozilla's Root Store Policy, and
>>> whether it is appropriate for them to continue to hold public trust.
>>> Your comments are welcome.
>> 
>> I don’t think this issue ever got a conclusion. It is clear to me that
>> Visa should be removed from the Mozilla root program immediately.
>> 
> We did reach a conclusion on the original question that Gerv raised in
> this thread: does Visa meet the following requirement from section 2.1 of
> the Mozilla root store policy:
> 
> CAs whose certificates are included in Mozilla's root program MUST provide
> some service relevant to typical users of our software products.

This is an answer to the first question, the second part is “whether it is 
appropriate for them to continue to hold public trust.”

> In the thread on this list titled "Updating Root Inclusion Criteria" it was
> decided that we will not attempt to restrict organizations from
> participating in the Mozilla CA program based on a judgement of their value
> to our users.

Right, but a judgement based on risk to users seems prudent.

> The most recent BR audit report for the Visa eCommerce Root contains 3
> qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf

And one of these qualifications is for a critical component of the job:

> We were unable to obtain evidence of the domain validation documentation for 
> a certificate issued.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public trust of VISA's CA

[Jonathan Rudenberg via dev-security-policy]

> On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy 
>  wrote:
> 
> In the light of this, I believe it is reasonable to discuss the question
> of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
> https://crt.sh/?id=896972 , which is the one includes in our store)
> meets the criteria for inclusion in Mozilla's Root Store Policy, and
> whether it is appropriate for them to continue to hold public trust.
> Your comments are welcome.

I don’t think this issue ever got a conclusion. It is clear to me that Visa 
should be removed from the Mozilla root program immediately.

Visa has been extremely unresponsive in general. The most recent case was their 
non-compliant OCSP responder: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1398261

It took them five months to fix the problem, and there is still no incident 
report.

In their response to January CA Communication Action 2 (about insecure domain 
validation methods), they did not provide a comment response, but selected the 
option indicating they were using these vulnerable methods and required a date 
for an update in the comment field:

> We have active (not expired or revoked) certificates issued using these 
> methods. We will review our implementation for vulnerabilities and report our 
> findings on the mozilla.dev.security.policy list by the date specified in the 
> comments section below.

There are currently only 90 unexpired certificates issued by this CA known to 
CT: https://crt.sh/?Identity=%25=1414=expired (last time we 
looked, there were only 27 and two were revoked)

Additionally, the telemetry shows an extremely small number of validations.

It’s not clear to me from their responses whether they are even currently 
BR-compliant, and as of September 13, 2017 it seems like they weren’t:

> Regarding BR compliance, we completed our initial BR audit in September of 
> 2016.  Since that time, we have been addressing the observations noted by our 
> external auditors.  This also would encompass any certificate issues that 
> have been publically reported.  Understanding that such changes in adopting a 
> new process will have business impact, it is difficult to provide an accurate 
> timeline of complete compliance as we are required to assess the impact to 
> our client and payment systems to avoid any operational impact.  We are 
> committed to aligning with BR and Mozilla requirements as we have 
> continuously move forward in making the necessary changes .

Given all this, I don’t think there is a lot of risk to Mozilla’s users with no 
benefit if Visa continues to be included in the root program.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ccadb.org

[Jonathan Rudenberg via dev-security-policy]

Hrm, I didn’t realize it had been restricted. The gist is that bug is closed as 
incomplete as of three months ago and there is a new bug that I don’t have 
access to: https://bugzilla.mozilla.org/show_bug.cgi?id=1409786


> On Jan 29, 2018, at 20:02, James Burton  wrote:
> 
> Hi Jonathan,
> 
> I haven't got the required permission to access bug 1376996. 
> 
> Thank you,
> 
> James 
> 
> 
> On Tue, Jan 30, 2018 at 12:57 AM, Jonathan Rudenberg  
> wrote:
> 
> > On Jan 29, 2018, at 19:48, James Burton via dev-security-policy 
> >  wrote:
> >
> > I was doing research on the ccadb.org site and was surprised to find that
> > the site is running only in HTTP and is not using HTTPS.
> 
> There is already a bug about this: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1376996
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ccadb.org

[Jonathan Rudenberg via dev-security-policy]

> On Jan 29, 2018, at 19:48, James Burton via dev-security-policy 
>  wrote:
> 
> I was doing research on the ccadb.org site and was surprised to find that
> the site is running only in HTTP and is not using HTTPS.

There is already a bug about this: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1376996
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Jonathan Rudenberg via dev-security-policy]

> On Jan 25, 2018, at 13:09, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an
> explanation of the new method 12 is too much detail for this message, and
> it can be found in the ballot that I've referenced.
> 
> In order to move ahead with this communication to CAs while our timeline
> for the deprecation of BR 3.2.2.4 methods 1 and 5 is still being discussed,
> I'd like to propose modifying item #2 as follows:
> 
> 2. On 19-December, significant concerns were raised about the reliability
> of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
> [3] Since then, discussions on the CA/Browser Forum Public list have
> resulted in a proposed ballot to prohibit the use of these methods after
> 1-August 2018. [4] Rather than accept the risk of continued use of these
> methods, Mozilla may decide to set an earlier deadline such as 1-March
> 2018. If your CA uses either of these methods, please evaluate your
> implementation for vulnerabilities, follow the discussion closely, and be
> prepared to quickly discontinue your use of these methods of domain
> validation.
> 
> Please comment on this change.

This is a great improvement. I think we should also ask that any CAs using 
these methods immediate disclose that they are and the procedures they are 
using, as well as the date they expect to complete a review of their 
implementation, and then provide the review when it is complete.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Jonathan Rudenberg via dev-security-policy]

> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> We could still choose to set that date in our own policy if the ballot were
> to fail. The reasoning behind that date has been discussed on the
> CA/Browser Forum lists. I would summarize the argument as (1) a number of
> smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
> agreed that 6 months was enough time to migrate away from it.

While these CAs might want six months, it’s not clear that a good argument has 
been made for this. Let’s Encrypt stopped validating using the TLS-SNI-01 
method under two hours after learning that there was a *potential* security 
vulnerability in the validation method. Why should we expect any less from 
other CAs? We should err on the side of protecting users, not CAs using 
insecure validation methods that don’t even stand up to a small amount of 
adversarial scrutiny.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Jonathan Rudenberg via dev-security-policy]

> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> 2. On 19-December, significant concerns were raised about the reliability
> of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
> [3] Since then, discussions on the CA/Browser Forum Public list have
> resulted in a proposed ballot to prohibit the use of these methods after
> 1-August 2018. [4] If your CA uses either of these methods, please evaluate
> your implementation for vulnerabilities and be prepared to discontinue
> their use prior to the deadline if ballot 218 succeeds.

Is there a reason to make this deprecation conditional on the ballot? Given 
what we know about how the vulnerable methods are used in the wild, they have 
the same level of brokenness as TLS-SNI-01/02 and it’s not clear how evaluating 
for vulnerabilities would fix anything. August is a long time from now, and 
even that date would be conditional on the ballot.

I strongly believe that requiring CAs to disclose their use of these methods 
immediately, and setting a date not more than a couple months from now where 
these methods and previous validations using them must not be used would be the 
correct choice to protect Mozilla’s users.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

GlobalSign certificate with far-future notBefore

[Jonathan Rudenberg via dev-security-policy]

A certificate issued by GlobalSign showed up in CT today with a notBefore date 
of March 21, 2018 and a notAfter date of April 23, 2021, a validity period of 
~1129 days (more than three years).

https://crt.sh/?id=311477948=zlint

CA/B Forum ballot 193 modified the Baseline Requirements to set a maximum 
validity period of 825 days for certificates issued after March 1, 2018.

While the BRs do not appear to have any rules about forward-dating 
certificates, Mozilla’s CA Forbidden or Problematic Practices say:

> Certificates do not contain an issue timestamp, so it is not possible to be 
> certain when they were issued. The notBefore date is the start of the 
> certificate's validity range, and is set by the CA. It should be a reasonable 
> reflection of the date on which the certificate was issued. Minor tweaking 
> for technical compatibility reasons is accepted, but backdating certificates 
> in order to avoid some deadline or code-enforced restriction is not.

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 back-dating the 
notBefore date.
2) Firefox should implement a technical check to enforce the validity period so 
that issuance practices like this do not impact users (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 18, 2018, at 08:53, Ryan Sleevi  wrote:
> 
> If Mozilla was committed to an equitable set of criteria for both incumbents 
> and newcomers, then one natural consequence of this is that all incumbents 
> should be required to rotate their keys to new roots, created under audit 
> criteria acceptable to Mozilla, and to transition issuance to these roots. 
> This is, for what it's worth, notably similar to the consensus proposal 
> regarding Symantec and the Managed Partner Infrastructure, and serves to 
> mitigate a broad swath of risks.
> 
> So I don't see any argument suggesting it *shouldn't* apply to existing roots 
> - if anything, such a policy requirement would go substantially to both 
> reduce the benefits afforded to incumbents through entropy, and to ensure 
> that Mozilla's users are adequately protected as the emerging security and 
> threat landscape changes. It does not prevent devices which cannot update (as 
> you can cross-certify), but ensures that the security critical, 
> responsibly-developed applications that do update can ensure their users are 
> protected. 

Yes, this is what I was thinking when I wrote the initial email. There are 
massive security benefits to Mozilla’s users if all CAs roll their roots and 
are re-evaluated after implementing an updated inclusion policy and ongoing 
requirements based on the goals that Alex described.

I don’t think the conversations are separate. They are necessarily the same. It 
doesn’t make sense to update the inclusion policies and not look at roots that 
are already included unless you want to continue favoring incumbents.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 17/01/2018 21:14, Jonathan Rudenberg wrote:
>>> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy 
>>>  wrote:
>>> 
>>> On 17/01/2018 16:13, Jonathan Rudenberg wrote:
> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Hi Wayne,
> 
> After some time thinking about it, I struggled to articulate what the 
> right
> rules for inclusion were.
> 
> So I decided to approach this from a different perspective: which is that 
> I
> think we should design our other policies and requirements for CAs around
> what we'd expect for organizations operating towards a goal of securing 
> the
> Internet as a global public resource.
> 
> Towards that goal we should continue to focus on things like transparency
> (how this list is run, visibility of audit statements, certificate
> transparency) and driving technical improvements to the WebPKI (shorter
> certificate lifespans, fewer allowances for non-compliant certificates or
> use of deprecated formats and cryptography). If organizations wish to hold
> themselves to these (presumably higher) standards for what could equally
> well be a private PKI, I don't see that as a problem. On the flip side, we
> should not delay improvements because CAs with limited impact on the 
> public
> internet struggle with compliance.
>>> 
>>> I would say, that to limit the danger that such an essentially unused CA 
>>> operator turns rogue, only CAs that provide certificates for public trust 
>>> should be admitted in the future, more on that in another post.
>>> 
 I like this concept a lot. Some concrete ideas in this space:
 - Limit the validity period of root certificates to a few years, so that 
 the criteria can be re-evaluated, updated, and re-applied on a rolling 
 basis.
>>> 
>>> This may be fine for TLS root CAs that are distributed in frequently
>>> updated browsers (such as Firefox and Chrome).
>>> 
>>> It is absolutely fatal for roots that are also used for any of the
>>> following:
>>> 
>>> - Distributed in browsers that don't get frequent updates (due to
>>>  problems in that distribution channel), such as many browsers
>>>  distributed in the firmware of mobile devices, TVs etc.
>> Distributing WebPKI roots in infrequently updated software is a bad idea and 
>> leads to disasters like the issues around the SHA-1 deprecation.
> 
> But what should then be done when that infrequently updated software is
> in fact a general end user web browser (as opposed to the previously
> discussed special cases of certain payment terminals)?  Remove TLS
> support?  Trust all certificates without meaningful checks?  Pop up
> certificate warnings for every valid certificate?

Don’t ship browsers that don’t get updates. The surface area is huge and there 
are many security bugs that are fixed regularly. Shipping browsers in a way 
that prevents them from being updated frequently is deeply irresponsible.

> The way the SHA-1 deprecation was done, with no widely implemented way
> for TLS clients to signal their ability to support stronger algorithms,
> has in fact created a situation where unreliable hacks are needed to
> support older mobile browsers, including feeding unencrypted pages to
> some of them.  The public stigma attached to this makes this something
> that is rarely discussed in public, but is quietly done by webmasters that 
> need to communicate with those systems.

This is false. TLS clients absolutely signal their ability to support specific 
algorithms, and there are several implementations of serving SHA-1 certificates 
to insecure clients.

> 
>>> - Used to (indirectly) sign items of long validity, such as e-mails
>>>  (Thunderbird!), timestamps and software.
>> I don’t know much about S/MIME, but this doesn’t sound right. Of course 
>> certificates used to sign emails expire! That’s obviously expected, and I’d 
>> hope that the validation takes that into account.
> 
> The mechanisms vary by recipient software.  But a typical technique
> combines a known-unmodified-since date (such as the date of reception or
> a date certified by a cryptographic timestamps) to compare the relevant
> validity dates in certificates against.
> 
> This obviously needs continued trust in the root certificates
> that were relevant at that earlier time, including the ability
> if the corresponding CAs to publish and update revocation
> information after the end certificates expiry date.  (Consider the
> case where an e-mail sender's personal certificate was
> compromised 1 day before expiry, but that fact was not reported
> to the CA until later, thus requiring the CA to publish changed
> revocation information for an already expired certificate 

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 17/01/2018 16:13, Jonathan Rudenberg wrote:
>>> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
>>>  wrote:
>>> 
>>> Hi Wayne,
>>> 
>>> After some time thinking about it, I struggled to articulate what the right
>>> rules for inclusion were.
>>> 
>>> So I decided to approach this from a different perspective: which is that I
>>> think we should design our other policies and requirements for CAs around
>>> what we'd expect for organizations operating towards a goal of securing the
>>> Internet as a global public resource.
>>> 
>>> Towards that goal we should continue to focus on things like transparency
>>> (how this list is run, visibility of audit statements, certificate
>>> transparency) and driving technical improvements to the WebPKI (shorter
>>> certificate lifespans, fewer allowances for non-compliant certificates or
>>> use of deprecated formats and cryptography). If organizations wish to hold
>>> themselves to these (presumably higher) standards for what could equally
>>> well be a private PKI, I don't see that as a problem. On the flip side, we
>>> should not delay improvements because CAs with limited impact on the public
>>> internet struggle with compliance.
> 
> I would say, that to limit the danger that such an essentially unused CA 
> operator turns rogue, only CAs that provide certificates for public trust 
> should be admitted in the future, more on that in another post.
> 
>> I like this concept a lot. Some concrete ideas in this space:
>> - Limit the validity period of root certificates to a few years, so that the 
>> criteria can be re-evaluated, updated, and re-applied on a rolling basis.
> 
> This may be fine for TLS root CAs that are distributed in frequently
> updated browsers (such as Firefox and Chrome).
> 
> It is absolutely fatal for roots that are also used for any of the
> following:
> 
> - Distributed in browsers that don't get frequent updates (due to
>  problems in that distribution channel), such as many browsers
>  distributed in the firmware of mobile devices, TVs etc.

Distributing WebPKI roots in infrequently updated software is a bad idea and 
leads to disasters like the issues around the SHA-1 deprecation.

> - Used to (indirectly) sign items of long validity, such as e-mails
>  (Thunderbird!), timestamps and software.

I don’t know much about S/MIME, but this doesn’t sound right. Of course 
certificates used to sign emails expire! That’s obviously expected, and I’d 
hope that the validation takes that into account.

> - Apply for inclusion in other root programs with slow/costly/
>  inefficient distribution of new root certificates (At least one
>  major software vendor has these problems in their root program).

This isn’t Mozilla’s problem, and one can come up with a variety of 
straightforward workarounds.

>> - Make all certificates issued by CAs under a root that is trusted for TLS 
>> in scope for the Baseline Requirements, and don’t allow issuing things like 
>> client certificates that have much more relaxed requirements (if any). This 
>> helps avoid ambiguity around scope.
> 
> Again this would be a major problem for roots that are used outside web
> browsers, including roots used for e-mail certificates (Thunderbird).
> 
> The ecosystem already suffers from the need to keep multiple trusted
> root certificates per CA organization due to artifacts of existing
> rules, no need to make this worse by multiplying this with the number
> of certificate end uses.

I’m having trouble seeing how sharding roots based on compliance type is a 
problem. Not doing so complicates reasoning about compliance unnecessarily.

>> - Limit the maximum validity period of leaf certificates issued to a sane 
>> upper bound like 90 days. This will help ensure that we don’t rust old 
>> crypto and standards in place and makes it less likely that a CA is “too big 
>> to fail” due to a set of customers that are not expecting to replace their 
>> certificates regularly.
> 
> This would be a *major* problem for any end users not using Let's
> encrypt, and would seemingly seek to destroy a major advantage of using
> a real CA over Let's encrypt.

Obviously this is completely false. Ridiculous diversions about “real” CAs 
aside, many other CAs issue certificates to automated management systems and 
this is obviously the way forward. Humans should not be managing certificate 
lifecycles.

> The only "too big to fail" problem we had recently was when the oldest,
> and biggest CA ever was forced out of business by some very loud people
> on this list.  And the problem was that those people demanded rushed
> punishment in the extreme with little or no consideration for who would
> be hurt in the process.

This is not true. Readers of this list are almost certainly quite familiar with 
the events that caused Google 

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Hi Wayne,
> 
> After some time thinking about it, I struggled to articulate what the right
> rules for inclusion were.
> 
> So I decided to approach this from a different perspective: which is that I
> think we should design our other policies and requirements for CAs around
> what we'd expect for organizations operating towards a goal of securing the
> Internet as a global public resource.
> 
> Towards that goal we should continue to focus on things like transparency
> (how this list is run, visibility of audit statements, certificate
> transparency) and driving technical improvements to the WebPKI (shorter
> certificate lifespans, fewer allowances for non-compliant certificates or
> use of deprecated formats and cryptography). If organizations wish to hold
> themselves to these (presumably higher) standards for what could equally
> well be a private PKI, I don't see that as a problem. On the flip side, we
> should not delay improvements because CAs with limited impact on the public
> internet struggle with compliance.


I like this concept a lot. Some concrete ideas in this space:

- Limit the validity period of root certificates to a few years, so that the 
criteria can be re-evaluated, updated, and re-applied on a rolling basis.
- Make all certificates issued by CAs under a root that is trusted for TLS in 
scope for the Baseline Requirements, and don’t allow issuing things like client 
certificates that have much more relaxed requirements (if any). This helps 
avoid ambiguity around scope.
- Limit the maximum validity period of leaf certificates issued to a sane upper 
bound like 90 days. This will help ensure that we don’t rust old crypto and 
standards in place and makes it less likely that a CA is “too big to fail” due 
to a set of customers that are not expecting to replace their certificates 
regularly.

I think with these and other similar requirements, we move closer towards 
ensuring that the roots accepted are operated with the high level goals 
described by Alex in mind, and allow more agility at the root store level to 
respond to issues.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Jonathan Rudenberg via dev-security-policy]

> On Jan 9, 2018, at 19:31, Peter Gutmann via dev-security-policy 
>  wrote:
> 
> Jonathan Rudenberg  writes:
> 
>> For communicating with other machines, the correct thing to do is to issue a
>> unique certificate for each device from a publicly trusted CA. The way Plex
>> does this is a good example:
>> https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
> 
> But the Plex solution required DynDNS, partnering with a CA for custom hash-
> based wildcard certificates (and for which the CA had to create a new custom
> CA cert), and other tricks, I don't think that generalises.  In effect this
> has given Plex their own in-house CA (by proxy), which is a point solution for
> one vendor but not something that any vendor can build into a product.

There is nothing special about this, hardware vendors regularly do a similar 
amount of work around discovery/provisioning for their devices. Additionally, 
there is nothing special about the CA, it can be done with Let’s Encrypt! For 
example: https://crt.sh/?q=%25.myfritz.net

These types of use cases (“IOT”) are regularly brought up by CAs on mailing 
lists, so I assume there are several that are quite happy to help you set 
something similar up.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Jonathan Rudenberg via dev-security-policy]

> On Jan 9, 2018, at 18:42, Peter Gutmann via dev-security-policy 
>  wrote:
> 
> Ryan Sleevi  writes:
> 
>> Of course, if that doesn’t tickle your fancy, there are other ways that are
>> supported that you may not have heard about - for example:
>> https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging
>> 
>> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
>> 
>> https://developer.chrome.com/apps/nativeMessaging
> 
> So I've had a quick look at these and unless I've missed something they're
> just a means of talking to an app on your local machine.  As soon as you go
> outside that boundary, e.g. to configure a router or printer on your local
> network via a browser, you're back to having to add a new root CA to the cert
> store for it to work.  Or have I missed something?

Yes, the native messaging API is for communication with local apps. 

For communicating with other machines, the correct thing to do is to issue a 
unique certificate for each device from a publicly trusted CA. The way Plex 
does this is a good example: 
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Jonathan Rudenberg via dev-security-policy]

> On Dec 12, 2017, at 08:36, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> A lot of people have posed suggestions for countermeasures so extreme
> they should not be taken seriously.  This includes discontinuing EV,

I don’t think that removing the EV UI is extreme, and it should definitely be 
taken seriously. The default Android browsers do not have EV at all, and many 
mobile browsers on iOS and Android including Chrome, Firefox, and Brave do not 
either. Those browsers combined have a huge number of pageviews that do not 
have any EV UI right now.

Additionally, all of the research I’ve seen shows that most users have no idea 
what is going on with EV and that it doesn’t help protect users.

> Here is a more reasonable suggestion:
> 
> 1. In the Fx UI, display the actual jurisdictionOfIncorporation instead
>  of just the country, especially where those differ (For example
>  Kentucky versus all-of-US).

It’s not clear how this will help. The jurisdiction that a business entity is 
incorporated in is unrelated to the physical location that the user associates 
with a website (if any) is based on factors related to corporate law and 
taxation. Even if all users were able to use the EV UI constructively somehow 
(they aren’t), adding a piece of information that is effectively arbitrary is 
not useful.

> 2. Add a rule that if there is a big national or international company
>  with a name, other companies cannot get certificates for the same
>  name in related jurisdictions.  For example if there is a company
>  listed on NYSE or NASDAQ, no similarly named US company can get an
>  EV or OV certificate for that name.  Ditto for a reasonable list of
>  national registries in each country.  CAs should be required to
>  publicly state which "big-status" lists beat local
>  company/organization registrations in each country, and similar for
>  any special lists of major global organizations, such as Google or
>  The Red Cross.

How similar is similar? What if Bancorpsouth Inc, The Bancorp Inc., and U.S. 
Bancorp all want your EV++ certificates? What about Apple Inc. and Apple Corps 
Ltd? Business entity names are not unique. Trying to enforce a unique 
constraint against them, especially with an additional “similarity” fuzzy layer 
is just asking for trouble. Trying to have users also make that determination 
(which is the current state of EV) is similarly troublesome.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: On the value of EV

[Jonathan Rudenberg via dev-security-policy]

> On Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy 
>  wrote:
> 
> 
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases. 

This isn’t a validation issue. Both certificates were properly validated and 
have correct (but very misleading information) in them. Business entity names 
are not unique, so it’s not clear how validation changes could address this.

I think it makes a lot of sense to get rid of the EV UI, as it can be trivially 
used to present misleading information to users in the most security-critical 
browser UI area. My understanding is that the research done to date shows that 
EV does not help users defend against phishing attacks, it does not influence 
decision making, and users don’t understand or are confused by EV.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom inclusion request: next steps

[Jonathan Rudenberg via dev-security-policy]

> On Sep 14, 2017, at 04:49, Gervase Markham via dev-security-policy 
>  wrote:
> 
> We should add the existing Certnomis cross-signs to OneCRL to revoke
> all the existing certificates. As of 10th August (now a month ago)
> StartCom said they have 5 outstanding SSL certs which are valid due
> to the Certnomis cross-sign. Revoking them all by adding intermediates
> to OneCRL would therefore lead to non-negligible disruption. But these
> were issued by an org whose most recent audits are qualified, which is
> under sanction, and about whose issuance practices and process safety
> there is a reasonable amount of doubt. We may allow a grace period for
> customers to replace them with certs from a trusted provider.

I’m not yet convinced a grace period is necessary. StartCom does not list 
Firefox as a compatible browser on their website (they have the logos for 
Internet Explorer, Microsoft Edge, Android, and Windows).

Additionally, there are multiple steps in the StartCom issuance flow that 
contain the following in red text:

> Notice: 
> 1. Mozilla and Google decided to distrust all StartCom root certificates as 
> of 21st of October, 2016, meaning that since January all the SSL certificates 
> issued from that date will no longer be trusted in Firefox and Chrome newest 
> releases. 
> Besides, Google has gone further and as explained here: 
> https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html 
> will not trust even those SSL certificates issued before that date until the 
> final disruption. 
> Apple's decision announced on Nov 30th, 2016 was to distrust all StartCom 
> root certificates as of 1st of December, meaning that SSL cert issued after 
> December 1st, 2016 will no longer be trusted in Apple’s systems. 
> 2. Any subscribers that paid the validation fee after Oct. 21st, 2016 can get 
> full refund by request. 
> 3. Currently StartCom is able to provide an interim solution for organization 
> users in case of requested. 
> Meanwhile StartCom is updating all systems and is following all requirements 
> requested by Mozilla to regain the trust in these browsers and re-apply after 
> the 6 months time penalty.

Given this explicit notification, I do not believe that subscribers would ever 
have had the expectation that their certificates would work with Firefox.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> 
>>> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> That seems like very poor logic and justification.
>>> 
>>> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
>>> literally years now, perhaps it's worth asking why CAs are only now
>>> discovering issues. That is, is the only reason we're discovering issues
>>> because CAs waited for the last possible moment? If so, why.
>> 
>> I think the BR clause that brings DNSSEC in is poorly drafted.
> 
> 
> Why?

As written, it’s not clear what the point is, as I describe below. If the 
intent was to require DNSSEC validation, it should say that clearly.

>> Additionally, it may be a stretch to say that DNSSEC in the context of CAA
>> has been discussed extensively.
> 
> 
> I'm not sure I understand why you feel some special discussion is or was
> necessary, given the discussion that occurred in IETF on this. That is, are
> you asserting that these issues - such as CAs not even checking CAA - are
> because of the ballot language?

I’m only talking about the DNSSEC-related issues here, I’m not aware of any CAs 
that are not or were not checking CAA due to DNSSEC.

Some CAs have interpreted this clause to not require DNSSEC validation when 
doing CAA queries, do you believe that interpretation is valid?

My interpretation is that DNSSEC validation is required to the point to the 
domain’s zone (but not to the CAA record set itself) if a CA wants to treat a 
record lookup failure as permission to issue. If the goal is to address the 
relevant security considerations in RFC 6844 with DNSSEC, this appears to leave 
a pretty gaping hole where a CA could:

1) not implement DNSSEC at all, and treat lookup failures as issuance-blocking 
errors; or
2) implement enough DNSSEC to decide if a zone has a “validation chain” without 
ever validating the CAA queries themselves

Thus, the clause as I interpret it only prevents a specific attack that drops 
CAA query answers and doesn't provide any authenticity or integrity guarantees. 
Instead of dropping an answer, an attacker could just replace the answer with 
one that they want.

> I’m not familiar with relevant discussions that are not indexed by Google,
>> but when I researched this I only found a few exchanges about this specific
>> requirement on the public mailing list.
> 
> 
> This was discussed at nearly every single F2F since late 2013/early 2014.
> The DNSSEC discussion was very much part of the IETF discussions.
> 
> What discussions do you feel should have happened, but didn’t?

So far I’ve been working of the interpretation above, and so I’ve been trying 
to understand why DNSSEC is brought in while not addressing any meaningful 
security considerations.

>>> I think arguments that suggest that failing to do the right thing makes
>> it
>>> OK to do the wrong thing are the worst arguments to make :)
>> 
>> My argument is not that it’s okay to do the wrong thing. Instead, I think
>> it’s worth evaluating the DNSSEC requirement to decide whether it should
>> continue to be defined as "the right thing” in the BRs. I did not see any
>> such analysis on cabfpub.
> 
> 
> I'm surprised to even see the suggestion that it isn't. Do you feel the
> security considerations are insufficiently documented in the CAA RFC? Do
> you feel it's not sufficiently obvious the risks of not using DNSSEC?

The security considerations are clear, and if properly implemented, DNSSEC 
would help there. These security considerations also apply to all online domain 
validation methods, and DNSSEC isn’t required there, so I’m not yet convinced 
by this argument.

What isn’t clear is whether DNSSEC should be deployed at all. There have been 
many large outages caused by DNSSEC[0], the tooling is horrible, weak crypto is 
rampant throughout the system, and the specification is extraordinarily 
complex. The footgun potential is greater than HPKP in scale, and the end 
result is something that even if deployed widely won’t even protect the average 
user from spoofed DNS answers on open WiFi. So, no, I’m not convinced that it’s 
the right thing.

Jonathan

[0] https://ianix.com/pub/dnssec-outages.html

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> That seems like very poor logic and justification.
> 
> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
> literally years now, perhaps it's worth asking why CAs are only now
> discovering issues. That is, is the only reason we're discovering issues
> because CAs waited for the last possible moment? If so, why.

I think the BR clause that brings DNSSEC in is poorly drafted. It seems like 
the intent may be to require full DNSSEC validation for CAA lookups, but that’s 
not what it says. I don’t think the issues under discussion have anything to do 
with the last moment. There appear to be significant differences in 
understanding, which were not discussed publicly until now. The ideal path here 
would have been for CAs to consult with the community about the interpretation 
and implementation details of this clause well before it came into force.

Additionally, it may be a stretch to say that DNSSEC in the context of CAA has 
been discussed extensively. I’m not familiar with relevant discussions that are 
not indexed by Google, but when I researched this I only found a few exchanges 
about this specific requirement on the public mailing list.

https://cabforum.org/pipermail/public/2016-November/008831.html
https://cabforum.org/pipermail/public/2017-February/009732.html

> I think arguments that suggest that failing to do the right thing makes it
> OK to do the wrong thing are the worst arguments to make :)

My argument is not that it’s okay to do the wrong thing. Instead, I think it’s 
worth evaluating the DNSSEC requirement to decide whether it should continue to 
be defined as "the right thing” in the BRs. I did not see any such analysis on 
cabfpub.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> For a little more context, the idea is that we can speed up the CAA check for 
> all customers while working with those who have DNSSEC to make sure they 
> aren't killing performance.  If there's a way to group them easily into 
> buckets (timeout + quick does DNSSEC exist check), working on improving the 
> experience for that particular set of customers is easier. That bucket can 
> then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy 
>  wrote:
> 
> In all three of these cases, the "domain's zone does not have a DNSSEC
> validation chain to the ICANN root" -- I requested SOA, DNSKEY, NS,
> and CAA records types for each zone and in no case did I get a
> response that had a valid DNSSEC chain to the ICANN root.

This comes down to what exactly “does not have a valid DNSSEC chain” means.

I had assumed that given the reference to DNSSEC in the BRs that the relevant 
DNSSEC RFCs were incorporated by reference via RFC 6844 and that DNSSEC 
validation is required. However, this is not entirely the case, using DNSSEC 
for CAA lookups is only RECOMMENDED in section 4.1 and explicitly “not 
required.” Which means this is all pretty pointless. The existence or 
non-existence of DNSSEC records doesn’t matter if there is no requirement to 
use them.

Given this context, I think that your interpretation of this clause is not 
problematic since there is no requirement anywhere to use DNSSEC.

I think this should probably be taken to the CAB Forum for a ballot to either:

1) purge this reference to DNSSEC from the BRs making it entirely optional 
instead of just having this pointless check; or
2) add a requirement to the BRs that DNSSEC validation be used from the ICANN 
root for CAA lookups and then tweak the relevant clause to only allow lookup 
failures if there is a valid non-existence proof of DNSSEC records in the chain 
that allows an insecure lookup.

None of my comments in this thread should be interpreted as support for DNSSEC 
:)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

For reference, here is the relevant bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1398428

> On Sep 9, 2017, at 05:21, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> big.basic.caatestsuite.com
> 
> [JR] We only check CAA records with UDP to keep performance good on certs
> with hundreds of SANs. I couldn't find a requirement that mandates use of
> TCP to check CAA records.  Should TCP be required? 

Not using TCP is fine. However, if the TC (truncation) bit is set (as it is in 
this case), you cannot know if you’ve received the complete CAA record set and 
must refuse to issue.

> refused.caatestsuite-dnssec.com
> 
> [DC] This will always issue. A refusal is treated as a failure.  Under the
> BRs a failure is permission to issue if we retry and DNSSec is not present.
> However, although DNSSec is present on the test suite's side, we can't see
> it.  Therefore, we get refused (a lookup failure), retry (resulting in
> another lookup failure), followed by a DNSSec check (which fails because
> retrieving the RSSIG record is refused).  There's no path under which this
> won't issue because we can't see whether DNSSec is present.

It sounds like your DNSSEC implementation is incorrect. To do the lookup 
properly, you’d walk down from the root zone doing DNSSEC validation and find 
that the lookup state is ‘Bogus’ due to the refused DNSKEY query.

Here’s a graphic that shows this: 
http://dnsviz.net/d/refused.caatestsuite-dnssec.com/dnssec/

> missing.caatestsuite-dnssec.com 
> 
> [DC]  I believe this is properly issued.  We retrieved the DNS record (no
> failure) and found no CAA record present.  The relevant portion of the BRs
> state: "CAs are permitted to treat a record lookup failure as permission to
> issue if: . the failure is outside the CA's infrastructure; . the lookup has
> been retried at least once; and . the domain's zone does not have a DNSSEC
> validation chain to the ICANN root." Although there is a valid DNSSEC chain
> to the root, issuance is still permitted because there was no lookup
> failure. 

The DNSSEC lookup state is Bogus here too, because there is no valid RRSIG 
record. There is a lookup failure when using a properly implemented client.

http://dnsviz.net/d/missing.caatestsuite-dnssec.com/dnssec/
https://dns.google.com/query?name=missing.caatestsuite-dnssec.com=CAA=true


> expired.caatestsuite-dnssec.com
> 
> [DC]  As with 4, I believe this is properly issued.  We retrieved the DNS
> record (no failure). The DNS lacked a CAA record. Although there is a valid
> DNSSEC chain to the root, issuance is still permitted because there was no
> lookup failure. 

Again, the lookup state is Bogus, due to the expired RRSIG. This should result 
in a lookup failure.

http://dnsviz.net/d/expired.caatestsuite-dnssec.com/dnssec/
https://dns.google.com/query?name=expired.caatestsuite-dnssec.com=CAA=true


> blackhole.caatestsuite-dnssec.com 
> 
> [DC] Retrieval of the RSSIG record is failing, which we interpreted as the
> lack of DNSSec.  If the DNSSec check times out, we issue because 1) The DNS
> lookup failed, 2) we retried the DNS lookup and it failed again, and 3)
> DNSSec is absent (because the RSSIG record lookup failed).

The eTLD+1 has a DNSSEC validation chain to the ICANN root, so it is not absent.

http://dnsviz.net/d/blackhole.caatestsuite-dnssec.com/dnssec/

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

[Jonathan Rudenberg via dev-security-policy]

> On Sep 8, 2017, at 12:27, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
>> I have updated the list again to note the additional responders fixed (in
>> this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly
>> less enormous I've also started removing everything but the CA's name when
>> I have confirmed that all the reported responders are now properly
>> responding to my queries.
> 
> Should I still file a bug for those, so that the incident report is recorded 
> in Bugzilla?

Yes, it will be much easier to track there instead of being buried in this 
thread.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Misissuance response status update

[Jonathan Rudenberg via dev-security-policy]

For those who aren’t following Bugzilla closely, here’s a quick update on where 
things are with the large batch of misissuance bugs that was filed this week.

Most CAs have provided an initial response, and many have finished their 
initial incident reviews and provided details.

Only two CAs have not responded at all yet:

- Entrust
- Godaddy (note that this bug was filed a day later than the rest due to an 
oversight on my part)

I suspect that many community members will be interested in the ongoing 
response and some may want to provide helpful feedback. You can see a list of 
all the bugs here: 
https://wiki.mozilla.org/CA/Incident_Dashboard#Open_CA_Compliance_Bugs

If you want to get email updates on a specific bug, log into Bugzilla and press 
the ‘Follow’ button.

If you’d like to follow all of the bugs via email, you can subscribe to the 
whole component by going to this link: 
https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch and selecting 
the NSS product and the “CA Certificate Mis-Issuance" component.

Another recent item that is relevant is a discussion about “Metadata-only 
subject fields” on the CAB Forum public mailing list: 
https://cabforum.org/pipermail/public/2017-August/011846.html

Cheers,

Jonathan


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

[Jonathan Rudenberg via dev-security-policy]

+mdsp

> On Aug 18, 2017, at 05:56, ramirommu...@gmail.com wrote:
> 
> Hi Jonathan
> You are right, we are going to look into this, taken into account that the 
> same serial number should be in the real certificate.
> 
> Regards
> 
> El jueves, 17 de agosto de 2017, 19:54:31 (UTC+2), Jonathan Rudenberg 
> escribió:
>> 
>> 
>> > On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy 
>> >  wrote: 
>> > 
>> > https://crt.sh/?id=112929021=cablint 
>> > is a precertificate. You can see the CT Precertificate Poison critical 
>> > extention. 
>> 
>> The serial number of this certificate should still be added to the relevant 
>> CRL, as it is not possible to prove the non-existance of a corresponding 
>> certificate without the CT Poison extension. 
>> 
>> Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 19:18, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> Bugs filed...

Hi Kathleen,

It looks like a bug was not created for GoDaddy about these certificates with 
invalid dnsNames, containing a space at the beginning of the eTLD+1:

https://crt.sh/?id=93578583=cablint
https://crt.sh/?id=110219638=cablint
https://crt.sh/?id=20950698=cablint
https://crt.sh/?id=25047430=cablint
https://crt.sh/?id=108417123=cablint

Additionally, I don’t believe that any communication was received from the 
following CAs about “double-dot” certificates[0][1] which they revoked after 
Rob found them and posted here (they are technically a subset of “invalid 
dnsNames” but the certificates were not listed in any of the threads linked in 
the bugs).

- GoDaddy
- GlobalSign
- T-Systems
- Symantec

I will post comments on the bugs that are already open for the last three.

Jonathan

[0] https://misissued.com/batch/13/
[1] 
https://groups.google.com/d/topic/mozilla.dev.security.policy/5bpr9yBgaYo/discussion
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
>  wrote:
> 
> Hello, In reference to 3)"Certificates that appear to be intended as client 
> certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for 
> the Mozilla Root Policy."
> The following 6 client certificates that have been identified as server 
> certificates and have been flagged as non-compliant.  However, these 
> certificates do not contain FQDN, IP Address, nor ‘TLS Web Server 
> Authentication’ EKU.  As such in order for us to proceed with our analysis 
> and determine if any remediation is required, we need clarification in the 
> exact nature of non-compliance as it relates to Mozilla Root Policy or CAB 
> Forum Baseline Requirement (ideally with pointer to the specific requirement 
> in the corresponding documents).

The Mozilla Root Store Policy section 1.1 (Scope) says:

> This policy applies, as appropriate, to certificates matching any of the 
> following (and the CAs which control or issue them):
> …
> 3. End-entity certificates which have at least one valid, unrevoked chain up 
> to such a CA certificate through intermediate certificates which are all in 
> scope, such end-entity certificates having either:
>   - an Extended Key Usage (EKU) extension which contains one or more of 
> these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, 
> id-kp-emailProtection; or: …

The six certificates linked contain the anyExtendedKeyUsage KeyPurposeId and 
were issued by an intermediate that is also in scope, so they are in scope for 
the Mozilla Root Policy and by extension the Baseline Requirements.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Miss-issuance: URI in dNSName SAN

[Jonathan Rudenberg via dev-security-policy]

> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy 
>  wrote:
> 
> https://crt.sh/?id=112929021=cablint
> is a precertificate. You can see the CT Precertificate Poison critical 
> extention. 

The serial number of this certificate should still be added to the relevant 
CRL, as it is not possible to prove the non-existance of a corresponding 
certificate without the CT Poison extension.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed Camerfirma intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 23:35, Aaron Wu via dev-security-policy 
>  wrote:
> 
> Hi Jonathan,
> 
> Thanks for reminding! I've sent mail to POC of AC Camerfirma and these two 
> intermediate certs has been disclosed in CCADB now.

One of these intermediates is missing audit details:

https://crt.sh/?sha256=247a6d807ff164031e0eb22ca85de329a3a4e6603dbc6203f0c6e282a9c9ea84=mozilladisclosure
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.

If anyone is interested in looking through the expired/revoked certificates 
issued by these intermediates, these two links will show all of the 
certificates that are known to CT:

https://crt.sh/?Identity=%25=718
https://crt.sh/?Identity=%25=5738

After clicking on a certificate ID, you can click the “Run cablint” link on the 
left to see the cablint output.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> I looked through the CT logs and found 15 more unexpired unrevoked 
> certificates that are trusted by NSS and appear to have the same inaccurate 
> organizationName of “U.S. Government” for a non-USG entity.
> 
> The list is here: https://misissued.com/batch/10/
> 
> Can you explain why your review missed these? Are there any more in addition 
> to these 15 and previous 5?
> 
> Jonathan

After looking into this more, I’ve found that the majority of certificates 
issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates are 
not BR-compliant.

The issues fall into three categories:

1) Certificates with HTTPS OCSP URLs
2) Certificates with otherName SANs
3) Certificates that appear to be intended as client certificates, but have the 
anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root Policy.

I’ve found 33 certificates that have one or more of these issues that are 
unexpired and unrevoked.

Here is the full list: https://misissued.com/batch/11/ (note that it is a 
superset of the batch I posted earlier today)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy 
>  wrote:
> 
> On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote:
>> On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote:
>>> IdenTrust is fully aware of the situation and has consulted with internal 
>>> and external parties to ensure that our course of action is appropriate and 
>>> commensurate with our business practices and accommodates our customer’s 
>>> needs.
>>> When IdenTrust initially established the ACES SSL profile, it was intended 
>>> to apply only to US government entities.  At that time, the Organization 
>>> was defined as a static value of “U.S. Government” in our profiles.  Later, 
>>> when non-agencies applied, IdenTrust reasoned at that time that this static 
>>> value continued to be acceptable as these entities must identify themselves 
>>> as organizations that act as relying parties, accepting certificates issued 
>>> under the ACES program, and are in some capacity associated with the U.S. 
>>> Government.  We have discussed internally and taken a fresh look at this 
>>> decision.   As a result, IdenTrust has updated the ACES SSL profile to use 
>>> the applicant Organization name in the Subject DN organization field.  This 
>>> change will accommodate all applications for ACES SSL certificates, both 
>>> U.S. agencies and non-agencies.  At the same time, we have modified the 
>>> OCSP validation URL from HTTPS to HTTP.  
>>> It is important to note that all certificates that are impacted by this 
>>> situation have been appropriately vetted by the IdenTrust Registration team 
>>> according to Identity Validation requirements stated in the ACES CP, 
>>> therefore the need to revoke affected certificates immediately is less 
>>> critical.  Our key objective is to revoke all incorrect certificates as 
>>> quickly as possible, while minimizing the impact to our customers and 
>>> avoiding disruption to critical business processes.  As such, IdenTrust is 
>>> working directly with these customers to initiate a replacement for the 
>>> offending certificates.  The replacement process allows the client to use 
>>> an online mechanism to request a new certificate with the correct 
>>> attributes and immediately download the new certificate.  The replacement 
>>> process also automatically revokes the certificate being replaced.  This 
>>> will enable our clients to receive a newly vetted certificate and they will 
>>> not be inconvenienced by a forced revocation, which would likely adversely 
>>> impact their business processes. IdenTrust will ultimately force a 
>>> revocation, in the event that the clients do not initiate a certificate 
>>> replacement in response to our communications.
>>> 
>>> Thank you for the opportunity to represent our position.
>> 
>> Is it Identrust's contention that the revocation rules required under the 
>> requirements they are audited under do not apply to these certificates 
>> because it would inconvenience their customers? This is a clear violation of 
>> the baseline requirements and I'd like some clarity on why Identrust 
>> believes it's permissible to pick and choose what their revocation timelines 
>> will be.
>> 
>> -Paul
> No, IdenTrust is not insinuating that the revocation rules do not apply here. 
>  IdenTrust, upon notification, immediately started reviewing our historical 
> understanding of our ACES SSL program and how it complied with both the ACES 
> CP and CA/B CP. This review involving internal and external resources began 
> in earnest. As previously stipulated, all certificates impacted were 
> appropriately vetted by the IdenTrust Registration team according to Identity 
> Validation requirements stated in the ACES CP.  IdenTrust worked to bridge 
> the gap between historical definitions and CA/B forum compliance while 
> balancing the needs of the community and IdenTrust customers alike. 
> Concurrently, IdenTrust reviewed, implemented and validated programmatic 
> controls prohibiting the population of the "U.S. Government" for ACES 
> non-agency entities. Once our technical fix was verified, our priority 
> objective has been to revoke all non-compliant certificates as quickly as 
> possible, while minimizing the impact to our customers and avoiding 
> disruption to critical business processes.   IdenTrust has been working with 
> the certificate sponsors to initiate a replacement for these identified 
> certificates.  One certificate has been successfully replaced.  For one 
> certificate, the customer has requested an extension until Wednesday 
> (tomorrow) to replace--we have granted this extension, but will revoke if the 
> replacement in not completed by 5 p.m. MT on Wednesday.  For the three 
> certificates where we were not successful in facilitating a replacement, we 
> have completed a revocation.  We will confirm replacement or revocation of 
> the last remaining 

Re: Bad characters in dNSNames

[Jonathan Rudenberg via dev-security-policy]

> On Aug 16, 2017, at 11:37, Amus via dev-security-policy 
>  wrote:
> 
> What's wrong with the two Well's Fargo certs? I don't see any invalid 
> characters in them.

https://crt.sh/?opt=cablint=19558707
https://crt.sh/?opt=cablint=11382596

Both have trailing spaces in one of the dnsNames: "ceomobilefix.wf.com “ and 
"ceomobile.wf.com “

Note that they are also expired.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> Feedback will be appreciated on the following draft for the Bugzilla Bugs 
> that I will be filing for the problems listed below.

It would be useful to know when and through what channel the CA learned about 
each of the problems listed. (problem report via email at date/time; 
known/unresolved issue since date; mailing list post at date/time; when I saw 
this bug; etc.)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 18:21, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> Feedback will be appreciated on the following draft for the Bugzilla Bugs 
> that I will be filing for the problems listed below.

I think we should ask for the CAs to provide a complete list of certificates 
that they find with each of the listed issues during the remediation process. 
The best way to handle this is to ensure each certificate is logged to CT and 
then provide a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one 
list per distinct problem.

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Jonathan Rudenberg via dev-security-policy]

+mdsp

> On Aug 15, 2017, at 16:45, Adriano Santoni <adriano.sant...@staff.aruba.it> 
> wrote:
> 
> Hi, we did receive your message about 1 certificate issued by us and 
> containing some invalid domain names. Those are internal server names and 
> their inclusion in SSL certificates was still permitted at the time when that 
> certificate was issued.
> We should have revoked that certificate however, by now, so we are 
> investigating on why it's still active. In the meantime we have contacted our 
> customer and are explaining the need to revoke that certificate.
> Thank you for letting us know of this issue.
> 
> Regards
> Adriano Santoni
> Actalis
> 
> 
> 
> 
> Inviato dal mio dispositivo Samsung
> 
> 
> ---- Messaggio originale 
> Da: Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> 
> Data: 15/08/2017 21:59 (GMT+01:00) 
> A: r...@sleevi.com 
> Cc: mozilla-dev-security-policy 
> <mozilla-dev-security-pol...@lists.mozilla.org>, Kathleen Wilson 
> <kwil...@mozilla.com> 
> Oggetto: Re: Bugzilla Bugs re CA issuance of non-compliant certs 
> 
> 
> > On Aug 15, 2017, at 15:45, Ryan Sleevi via dev-security-policy 
> > <dev-security-policy@lists.mozilla.org> wrote:
> > 
> > I would note that any CA which does not or has not promptly revoked these
> > within 24 hours of contact should, at a minimum, contact all root programs
> > that they participate in to acknowledge this non-compliance and discuss
> > what expectations other, non-Mozilla Root Programs have with respect to
> > these certificates. Similarly, if such programs have requirements around
> > "Security Incident Reporting," that CAs are timely in such reports.
> 
> It’s worth noting that with the exception of the metadata-only subject fields 
> issue, Alex and I have attempted to contact every CA listed directly via 
> their public certificate problem reporting channels. In addition to this, the 
> Mozilla Root Store policy requires all CAs to monitor this mailing list. So 
> there are only two categories for a CA that has not taken action yet:
> 
> 1) They are not monitoring either this list or their problem reporting 
> channels (or in some cases, those channels are inoperative) and as a result 
> are not aware of the issues; or
> 2) They are aware of the issues and have not taken action.
> 
> I believe that both of these categories are extremely concerning.
> 
> Jonathan
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 15:37, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> ** Common Name not in SAN
> https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ
> It is not clear to me if I need to add this item to the Bugzilla Bugs that I 
> will be filing. Please let me know if you think I need to add this item to 
> the bugs.

This is a legitimate BR violation and should be listed. In addition to the 
basic issue, this also uncovered a variety of certificates with invalid domains 
in the CN field.

The only CA that has contested this is Symantec[0], who have issued 
certificates with U-labels in the CN that do not match the capitalization of 
the corresponding SAN A-label. It’s not clear that U-labels are allowed at all 
in the CN, let alone labels that do not match any dnsNames, and none of the 
ballots that attempt to explicitly allow this have been adopted.

Jonathan

[0] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/rxEptYe7BwAJ

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bugzilla Bugs re CA issuance of non-compliant certs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 15:45, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> I would note that any CA which does not or has not promptly revoked these
> within 24 hours of contact should, at a minimum, contact all root programs
> that they participate in to acknowledge this non-compliance and discuss
> what expectations other, non-Mozilla Root Programs have with respect to
> these certificates. Similarly, if such programs have requirements around
> "Security Incident Reporting," that CAs are timely in such reports.

It’s worth noting that with the exception of the metadata-only subject fields 
issue, Alex and I have attempted to contact every CA listed directly via their 
public certificate problem reporting channels. In addition to this, the Mozilla 
Root Store policy requires all CAs to monitor this mailing list. So there are 
only two categories for a CA that has not taken action yet:

1) They are not monitoring either this list or their problem reporting channels 
(or in some cases, those channels are inoperative) and as a result are not 
aware of the issues; or
2) They are aware of the issues and have not taken action.

I believe that both of these categories are extremely concerning.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

New undisclosed Camerfirma intermediates

[Jonathan Rudenberg via dev-security-policy]

Two intermediates issued by AC Camerfirma that are not disclosed in the CCADB 
were logged today:

- 
https://crt.sh/?sha256=201c0617cc3310c7f29fcbe46b57459bc6786a8ba2753018eb27c1e800168a2e=mozilladisclosure
 (issued on 2017-05-25)
- 
https://crt.sh/?sha256=247a6d807ff164031e0eb22ca85de329a3a4e6603dbc6203f0c6e282a9c9ea84=mozilladisclosure
 (issued on 2017-07-06)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Jonathan Rudenberg via dev-security-policy]

Hi Arno and Martin,

> On Aug 14, 2017, at 11:44, Arno Fiedler  wrote:
> 
> Dear Forum,  
> 
> since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at least 
> 64 bits of entropy in the serial number.
> 
> Since 01-12-2016 D-TRUST TLS certificates requested via our enterprise 
> platform have a serial number which includes at least 64 bits of entropy. We 
> informed the CA-Program Manager about the 3 Month delay in moving the entropy 
> from the "DNqualifier” to the “SerialNumber” via eMail on 27-10-16.

Does this mean that you knew you would not be complying with Ballot 164 / BRs 
1.3.7 by the effective date of 2016-09-30? When did you realize this? Did you 
receive permission for this non-compliance from the relevant Application 
Software Suppliers, including Mozilla?

> Between 2012 and 06-07-2017 we still produced a smaller number of 
> certificates using our retail platform with additional entropy in the 
> “DNqualifier” field instead of the serial number field, because our certified 
> third party software was not able to handle long serial numbers earlier.  We 
> defined this issue as minor nonconformity, because the requirement for 
> entropy in the certificate was fulfilled.

What other issues have you defined as a "minor nonconformity"?

> On 20-07-17 Mozilla asked D-TRUST for clarification, due to the holiday 
> period this message reached us on 07-08-17, AF answered on 08-08-17 and 
> 10-08-17: “the certificate has 64 bits of entropy in the "DNqualifier" field 
> instead of the serial number field. Since 2012 we used this way of adding 
> random bits to certificates to mitigate preimage attacks. From a security 
> perspective the amount of Entropy in the certificate should be reasonable”.
> 
> On 10-08-2017 we got the information, that we issued in the Individual 
> Certificate Registration process a certificate with less entropy than 64 bit, 
> Jonathan reported “The DNqualifier appears to have a 33-bit number, not a 
> 64-bit number”.
> 
> On the 11-08-2017 we defined this case as a major issue, because our internal 
> examinations confirmed, that just using numeric characters causes entropy 
> less than 64 bit.
> 
> The review with our tool “PKI-watcher” gave the following result of effected 
> certificates:
> D-TRUST SSL Class 3 CA 1 2009 (607) 
> D-TRUST SSL Class 3 CA 1 EV 2009 (63)

To provide transparency, can you please add all of these certificates to at 
least one CT log and post the serial numbers, certificate fingerprints, or 
crt.sh IDs?

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

More certificates with invalid dnsNames

[Jonathan Rudenberg via dev-security-policy]

I’ve found 54 additional unexpired unrevoked certificates that are known to CT 
and trusted by NSS containing dnsNames that are invalid. The errors include 
invalid characters, internal names, and wildcards in the wrong position.

The full list is here: https://misissued.com/batch/8/

There are a few threads from the past few weeks about similar certificates, but 
as far as I know none of the certificates on this list have been discovered yet.

I’ve included a summary of the CCADB owners and intermediates at the end of 
this email.

Jonathan

—

DigiCert (18)
TI Trust Technologies Global CA (16)
Justica (1)
WellsSecure Certification Authority 01 G2 (1)

DocuSign (OpenTrust/Keynectis) (10)
CLASS 2 KEYNECTIS CA (8)
KEYNECTIS SSL RGS (2)

AC Camerfirma, S.A. (4)
AC CAMERFIRMA AAPP (2)
Camerfirma Corporate Server II - 2015 (2)

Certinomis (4)
Certinomis - Easy CA (2)
Certinomis Serveurs et Equipements (2)

Symantec / VeriSign (3)
Symantec Class 3 Secure Server CA - G4 (2)
Symantec Class 3 Secure Server SHA256 SSL CA (1)

Visa
Visa eCommerce Issuing CA (2)

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
EC-SectorPublic (2)

Taiwan-CA Inc. (TWCA)
TWCA Secure SSL Certification Authority (1)

WoSign CA Limited
StartCom Class 3 OV Server CA (1)

CA Disig a.s.
CA Disig R2I2 Certification Service (1)

Actalis
Actalis Authentication CA G3 (1)

PROCERT
PSCProcert (1)

Comodo
Intel External Basic Issuing CA 3B (1)

Izenpe S.A.
EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (1)

WISeKey
WISeKey CertifyID Advanced Services CA 4 (1)

T-Systems International GmbH (Deutsche Telekom)
Uni-Osnabrueck RZ-CA G-002 (1)

QuoVadis
QuoVadis Global SSL ICA G2 (1)

Symantec / GeoTrust
RapidSSL SHA256 CA - G3 (1)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with reserved IP addresses

[Jonathan Rudenberg via dev-security-policy]

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
containing IANA reserved IP addresses and any certificates containing them 
should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and 
trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates 
contain dnsNames with internal names, which are prohibited under the same BR 
section.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> Can anyone point out a real world X.509 framework that gets confused by
> a redundant pathlen:0 in a CA:FALSE certificate?  (Merely to assess the
> seriousness of the issue, given that the certificate was already
> revoked).

Yes, the cryptography Python package: 
https://github.com/pyca/cryptography/issues/3856

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with improperly normalized IDNs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 10/08/2017 22:22, Jonathan Rudenberg wrote:
>> RFC 5280 section 7.2 and the associated IDNA RFC requires that 
>> Internationalized Domain Names are normalized before encoding to punycode.
>> Let’s Encrypt appears to have issued at least three certificates that have 
>> at least one dnsName without the proper Unicode normalization applied.
>> https://crt.sh/?id=187634027=cablint
>> https://crt.sh/?id=187628042=cablint
>> https://crt.sh/?id=173493962=cablint
>> It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
>> requires normalization form KC, but RFC 5891 which replaces RFC 3491 
>> requires normalization form C. I believe that the BRs and/or RFC 5280 should 
>> be updated to reference RFC 5890 and by extension RFC 5891 instead.
>> Jonathan
> 
> All 3 dnsName values exist in the DNS and point to the same server (IP
> address). Whois says that the two second level names are both registered
> to OOO "JilfondService" .
> 
> This raises the question if CAs should be responsible for misissued
> domain names, or if they should be allowed to issue certificates to
> actually existing DNS names.
> 
> I don't know if the bad punycode encodings are in the 2nd level names (a
> registrar/registry responsibility, both were from 2012 or before) or in
> the 3rd level names (locally created at an unknown date).
> 
> An online utility based on the older RFC349x round trips all of these.
> So if the issue is only compatibility with a newer RFC not referenced from 
> the current BRs, these would probably be OK under the current BRs and 
> certLint needs to accept them.

In this case, the NFC and NFKC representations are the same:

$ irb
irb(main):001:0> require 'simpleidn'
=> true
irb(main):002:0> a = "xn--109-3veba6djs1bfxlfmx6c9g"
=> "xn--109-3veba6djs1bfxlfmx6c9g"
irb(main):003:0> u = SimpleIDN.to_unicode(a)
=> "؈؜ب1؈ؘؑ؞؈ءؒؔ0؛9ؘؚ؜"
irb(main):004:0> u.unicode_normalize(:nfc) == a
=> false
irb(main):005:0> u.unicode_normalize(:nfc) == u.unicode_normalize(:nfkc)
=> true
irb(main):006:0> n = SimpleIDN.to_ascii(u.unicode_normalize(:nfc))
=> "xn--109-3veba6djs0bgykfmx6c9g"
irb(main):007:0> n == a
=> false
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with improperly normalized IDNs

[Jonathan Rudenberg via dev-security-policy]

RFC 5280 section 7.2 and the associated IDNA RFC requires that 
Internationalized Domain Names are normalized before encoding to punycode.

Let’s Encrypt appears to have issued at least three certificates that have at 
least one dnsName without the proper Unicode normalization applied.

https://crt.sh/?id=187634027=cablint
https://crt.sh/?id=187628042=cablint
https://crt.sh/?id=173493962=cablint

It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
requires normalization form KC, but RFC 5891 which replaces RFC 3491 requires 
normalization form C. I believe that the BRs and/or RFC 5280 should be updated 
to reference RFC 5890 and by extension RFC 5891 instead.

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with common names not present in their SANs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy 
>  wrote:
> 
> Hi all,
> 
> 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always 
> be an element from the SAN.
> 
> Here are 62 certs, from a variety of CAs which do not meet that requirement: 
> https://misissued.com/batch/1/

I sent a problem report to Symantec about these certificates via their web form 
on 2017-08-07 and received this response from them a few minutes ago:

> Thank you for reporting the issue for Symantec, Thawte and RapidSSL 
> certificates; however, we feel that the certificates we have issued are 
> compliant.  We consider the puny-coded SAN to match the native-coded CN and 
> to best cover both human consumers and machine consumers that need to be able 
> to read the name. Therefore, the certificates should not be revoked.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with less than 64 bits of entropy

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> QuoVadis (560)
>Siemens Issuing CA Internet Server 2016 (560)
> 
> D-TRUST (224)
>D-TRUST SSL Class 3 CA 1 2009 (178)
>D-TRUST SSL Class 3 CA 1 EV 2009 (45)
>D-TRUST Root Class 3 CA 2 EV 2009 (1)
> 
> DigiCert (85)
>Siemens Issuing CA Class Internet Server 2013 (82)
>InfoCert Web Certification Authority (3)
> 
> Izenpe S.A. (62)
>EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
> 
> Government of The Netherlands, PKIoverheid (Logius) (55)
>Digidentity Services CA - G2 (55)
> 
> Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
>Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)

It looks like my summary missed one QuoVadis intermediate:

Bayerische SSL-CA-2016-01 (3)

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with less than 64 bits of entropy

[Jonathan Rudenberg via dev-security-policy]

Baseline Requirements section 7.1 says:

> Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate 
> serial numbers greater than zero (0) containing at least 64 bits of output 
> from a CSPRNG.

There are 1027 unexpired unrevoked certificates known to CT with a notBefore 
date greater than or equal to 2016-09-30 that are trusted by NSS for server 
authentication and have a serial number that has less than 64 bits of entropy.

The full list can be found here: https://misissued.com/batch/6/

Some of these were brought up in a previous thread[0], but I though a 
comprehensive picture of this issue would be helpful.

I’ve included a breakdown at the end of this email, and here are a few things 
that stood out to me while researching this:

- The "Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4” intermediate appears to 
use randomly generated 48-bit numbers.
- Three intermediates, "TeleSec ServerPass Class 2 CA”, "Go Daddy Secure 
Certificate Authority - G2”, and "Starfield Secure Certificate Authority - G2”, 
(which are not in this list) appear to issue certificates with serial numbers 
that are based on exactly 64 bits of entropy. This means that a small 
percentage of the certificates that they issue have serial numbers that are 
smaller than 8 bytes, requiring additional filtering to avoid false positives. 
It would be helpful if the policy was adjusted to require serial numbers always 
be at least 8 bytes before DER encoding to avoid these false positives.

Jonathan

[0] 
https://groups.google.com/d/topic/mozilla.dev.security.policy/vl5eq0PoJxY/discussion

—

QuoVadis (560)
Siemens Issuing CA Internet Server 2016 (560)

D-TRUST (224)
D-TRUST SSL Class 3 CA 1 2009 (178)
D-TRUST SSL Class 3 CA 1 EV 2009 (45)
D-TRUST Root Class 3 CA 2 EV 2009 (1)

DigiCert (85)
Siemens Issuing CA Class Internet Server 2013 (82)
InfoCert Web Certification Authority (3)

Izenpe S.A. (62)
EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)

Government of The Netherlands, PKIoverheid (Logius) (55)
Digidentity Services CA - G2 (55)

Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 07:55, Fiedler, Arno via dev-security-policy 
>  wrote:
> 
> Hello Jonathan,
> 
> the certificate has 64 bits of entropy in the "DNqualifier" field instead of 
> the serial number field. 
> 
> Since 2012 we used this way of adding random bits to certificates to mitigate 
>  preimage attacks
> From a security perspective the amount of Entropy in the certificate should 
> be reasonable.
> 
> Do you see a security need for revoking the certificate?

1) The dnQualifier appears to have a 33-bit number, not a 64-bit number.

2) One of the SAN dnsNames is "www.lbv-gis.brandenburg.de/lbvagszit”, which is 
clearly invalid.

3) The Baseline Requirements are extremely clear about this:

> The CA SHALL revoke a Certificate within 24 hours if one or more of the 
> following occurs:
> […]
> 9. The CA is made aware that the Certificate was not issued in accordance 
> with these Requirements or the CA’s Certificate Policy or Certification 
> Practice Statement;

So yes, I believe this certificate needs to be revoked immediately. It should 
have been revoked within 24 hours of learning about it. I believe July 20th was 
the latest date that you could have learned about it, when Gerv sent a 
notification to you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy 
>  wrote:
> 
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>> 
>>> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
>>> 
>>> The point of certlint was to help identify issues.  While I appreciate
>>> it getting broad usage, I don't think pushing for revocation of every
>>> certificate that trips any of the Error level checks is productive.
>> 
>> I agree, and I don’t really have a position on the revocation of 
>> certificates with errors that do not appear to have any security impact like 
>> these.
>> 
>> Jonathan
>> 
>> 
> 
> I strongly disagree.  Errors like this make me question whether the
> certification authority is sufficiently competent to be trusted.  Small
> errors can indicate an increased likelihood of serious errors.

I’m not saying the errors are okay. They aren’t. All I’m saying is that for 
this batch I’m not requesting revocation directly from CAs using their problem 
reporting contact details, as I’ve done with other more serious issues.

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
> 
> The point of certlint was to help identify issues.  While I appreciate
> it getting broad usage, I don't think pushing for revocation of every
> certificate that trips any of the Error level checks is productive.

I agree, and I don’t really have a position on the revocation of certificates 
with errors that do not appear to have any security impact like these.

Jonathan


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

Baseline Requirements section 7.1.4.2.2(j) says:

> All other optional attributes, when present within the subject field, MUST 
> contain information that has been verified by the CA. Optional attributes 
> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, 
> and/or any other indication that the value is absent, incomplete, or not 
> applicable.

There are 522 unexpired unrevoked certificates known to CT issued after 
2015-11-01 that are trusted by NSS for server authentication and have at least 
one subject field that only contains ASCII punctuation characters.

The full list can be found here: https://misissued.com/batch/5/

Since there are so many, I have included a list of the CCADB owner, 
intermediate commonName, and count of certificates for the 311 certificates in 
this batch that were issued in the last 365 days so that the relevant CAs can 
add the appropriate technical controls and policy to comply with this 
requirement in the future. Please let me know if there is any additional 
information that would be useful.

Jonathan

—

DigiCert (131)
Cybertrust Japan Public CA G3 (64)
DigiCert SHA2 Extended Validation Server CA (36)
DigiCert SHA2 High Assurance Server CA (12)
TERENA SSL CA 3 (7)
DigiCert SHA2 Secure Server CA (6)
Cybertrust Japan EV CA G2 (6)

GlobalSign (62)
GlobalSign Organization Validation CA - SHA256 - G2 (46)
GlobalSign Extended Validation CA - SHA256 - G2 (8)
GlobalSign Extended Validation CA - SHA256 - G3 (8)

Symantec / VeriSign (35)
Symantec Class 3 Secure Server CA - G4 (32)
Symantec Class 3 EV SSL CA - G3 (2)
Wells Fargo Certificate Authority WS1 (1)

Symantec / GeoTrust (34)
GeoTrust SSL CA - G3 (25)
GeoTrust SHA256 SSL CA (5)
RapidSSL SHA256 CA (2)
GeoTrust Extended Validation SHA256 SSL CA (2)

Comodo (19)
COMODO RSA Organization Validation Secure Server CA (11)
COMODO RSA Extended Validation Secure Server CA (8)

Symantec / Thawte (17)
thawte SSL CA - G2 (12)
thawte SHA256 SSL CA (3)
thawte EV SSL CA - G3 (2)

T-Systems International GmbH (Deutsche Telekom) (6)
Zertifizierungsstelle FH Duesseldorf - G02 (3)
TeleSec ServerPass Class 2 CA (2)
Helmholtz-Zentrum fuer Infektionsforschung (1)

QuoVadis (3)
QuoVadis EV SSL ICA G1 (2)
QuoVadis Global SSL ICA G2 (1)

SECOM Trust Systems Co. Ltd. (2)
NII Open Domain CA - G4 (2)

SwissSign AG (1)
SwissSign Server Gold CA 2014 - G22 (1)

Entrust (1)
Entrust Certification Authority - L1K (1)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy 
>  wrote:
> 
> Dear Mozilla Security Policy Community,
> 
> Thanks for the advice about the short serial numbers and apologies for the 
> delayed response.
> 
> Since 2016, all D-TRUST TLS certificates based on electronic Certificate 
> Requests have a certificate serial number which includes 64 bits of entropy.
> 
> Between 2012 and July 6th, 2017 we produced a small number of certificates 
> with  paper-based Certificate Registration Requests using 64 bits of entropy 
> in the "DNqualifier" field instead of the serial number field.
> 
> Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of 
> entropy in the serial number.
> 
> I hope this helps and please do not hesitate to contact us if there are any 
> further questions.

Hi Arno,

It doesn’t look like this certificate has been revoked yet? 
https://crt.sh/?id=174827359=cablint

Can you explain why it hasn’t been revoked yet and when it will be?

Thanks,

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy 
>  wrote:
> 
> On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
>> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
>> is required to have the plaintext HTTP scheme according to Baseline 
>> Requirements section 7.1.2.2(c).
>> 
>> Here’s the list of certificates: https://misissued.com/batch/4/
>> 
>> Jonathan
> 
> IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
> context.  That being said, we have altered our profiles for certificates 
> issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
> issued going forward will contain an HTTP OCSP URL.  We will also examine all 
> other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for 
> giving 
> us an opportunity to address this with the community

Thanks for the update.

Can you also clarify why the subject organizationName is "U.S. Government” for 
all of these certificates, despite the other subject fields indicating 
organizations that are not a component of the US Government?

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy 
>  wrote:
> 
> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>> 
>>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>>>  wrote:
>>> 
>>> On 16/05/17 02:26, userwithuid wrote:
 After skimming the responses and checking a few CAs, I'm starting to
 wonder: Wouldn't it be easier to just add another mandatory field to
 the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
 policy and just use that to provide a public list?
>>> 
>>> Well, such contacts are normally per CA rather than per root. I guess we
>>> could add it on the CA's entry.
>> 
>> I’ve been reporting a fair amount of misissuance this week, and the 
>> responses to the Problem Reporting question in the April CA communication 
>> leave a lot to be desired. Several CAs do not have any contact details at 
>> all, and others require filling forms with captchas.
>> 
>> I think it’d be very useful if CAs were required maintain a problem 
>> reporting email address and keep it current in the CCADB, this requirement 
>> could go in the Mozilla Root Store policy or the CCADB policy. If they want 
>> to also maintain other modes of contact, they can but no matter what an 
>> email address should be required.
>> 
>> Jonathan
>> 
> 
> I think that a public point of contact for a certification authority was
> a requirement under Mozilla's policy.  I cannot find such a requirement
> now unless the Baseline Requirements, which are included by reference in
> Mozilla's policy, require it.

Yes, section 4.9.3 of the Baseline Requirements says:

> The CA SHALL provide Subscribers, Relying Parties, Application Software 
> Suppliers, and other third parties with clear instructions for reporting 
> suspected Private Key Compromise, Certificate misuse, or other types of 
> fraud, compromise, misuse, inappropriate conduct, or any other matter related 
> to Certificates. The CA SHALL publicly disclose the instructions through a 
> readily accessible online means.

However, it does not specify that email is required. I’m proposing that Mozilla 
require that one of the methods for reporting be email and that the email 
address be recorded in the CCADB.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AC FNMT Usuarios and anyExtendedKeyUsage

[Jonathan Rudenberg via dev-security-policy]

The "AC FNMT Usuarios” intermediate operated by the Government of Spain, 
Fábrica Nacional de Moneda y Timbre (FNMT) issues certificates that are not 
BR-compliant. This was acknowledged during the FNMT root inclusion request 
discussion and allowed as long as the intermediate "never issues TLS/SSL 
certificates”[0].

Recently, some certificates issued from this intermediate were logged to CT, so 
we can see what they look like[1].

While they do not contain dnsName SANs, they do contain the anyExtendedKeyUsage 
EKU which makes them technically usable for TLS server authentication and in 
scope for the Mozilla Root Store Policy.

Additionally, I was able to find one of these certificates[2] served from a TLS 
server in Censys[3].

This is information that does not appear to have been available at the time of 
the root inclusion discussion last year, so I thought I’d point it out.

Jonathan

[0] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7wIZmwp4qGQ/wRQgVVz2CQAJ
[1] https://crt.sh/?Identity=%25=6664
[2] https://crt.sh/?opt=cablint=145250473
[3] https://censys.io/ipv4/213.96.188.218


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[Jonathan Rudenberg via dev-security-policy]

> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 16/05/17 02:26, userwithuid wrote:
>> After skimming the responses and checking a few CAs, I'm starting to
>> wonder: Wouldn't it be easier to just add another mandatory field to
>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
>> policy and just use that to provide a public list?
> 
> Well, such contacts are normally per CA rather than per root. I guess we
> could add it on the CA's entry.

I’ve been reporting a fair amount of misissuance this week, and the responses 
to the Problem Reporting question in the April CA communication leave a lot to 
be desired. Several CAs do not have any contact details at all, and others 
require filling forms with captchas.

I think it’d be very useful if CAs were required maintain a problem reporting 
email address and keep it current in the CCADB, this requirement could go in 
the Mozilla Root Store policy or the CCADB policy. If they want to also 
maintain other modes of contact, they can but no matter what an email address 
should be required.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 7, 2017, at 16:57, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 07/08/2017 22:47, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
>> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
>> is required to have the plaintext HTTP scheme according to Baseline 
>> Requirements section 7.1.2.2(c).
>> Here’s the list of certificates: https://misissued.com/batch/4/
>> Jonathan
> 
> Why are you so obsessed with the least significant BR requirements?

I’m not convinced this is insignificant. NSS only supports http:// URLs for 
OCSP, and I suspect the majority of OCSP clients do the same.

https://hg.mozilla.org/projects/nss/file/3c4f0e9f6e45/lib/certhigh/ocsp.c#l2844
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 7, 2017, at 16:47, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
> that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
> required to have the plaintext HTTP scheme according to Baseline Requirements 
> section 7.1.2.2(c).
> 
> Here’s the list of certificates: https://misissued.com/batch/4/

I also note that these certificates all have an organizationName of "U.S. 
Government”, but the rest of the subject details indicate organizations that 
are not components of the US Government.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

“IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
required to have the plaintext HTTP scheme according to Baseline Requirements 
section 7.1.2.2(c).

Here’s the list of certificates: https://misissued.com/batch/4/

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with invalidly long serial numbers

[Jonathan Rudenberg via dev-security-policy]

RFC 5280 section 4.1.2.2 says:

> Conforming CAs MUST NOT use serialNumber values longer than 20 octets.

There are two CAs that appear to misissue certificates with serial numbers that 
are longer than 20 octets on an ongoing basis:

- Certinomis
- TI Trust Technologies (chains up to a Baltimore/DigiCert root)

Here is a list of 40 certificates with this error: 
https://misissued.com/batch/2/

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

English translation for Certinomis root CP/CPS?

[Jonathan Rudenberg via dev-security-policy]

The Common CCADB Policy states:

> CAs must provide English versions of any Certificate Policy, Certification 
> Practice Statement and Audit documents which are not originally in English, 
> with version numbers matching the document they are a translation of.

The page at https://www.certinomis.fr/documents-et-liens/nos-politiques 
contains links to the Certinomis policies, but there is no English translation 
of "Politique Racine”, the CP/CPS that appears to cover the "Certinomis - Root 
CA” certificate.

Can anyone help answer these questions?

1) Does the document titled "POLITIQUE DE CERTIFICATION AUTORITE DE 
CERTIFICATION RACINE” contain the policies for the Certinomis root? 
(https://crt.sh/?caid=5676)

2) Is an English translation available somewhere for this document but not 
linked from the Certinomis policy documents page?

3) If there is no English translation available, is Certinomis required to 
provide one?

Thanks,

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Jonathan Rudenberg via dev-security-policy]

> On Aug 3, 2017, at 12:26, Kathleen Wilson via dev-security-policy 
>  wrote:
> 
> All,
> 
> I have conflicting opinions about this situation:
> 
> On the one hand, I want to see better behavior, and am inclinded to add these 
> two intermediate certs to OneCRL, and tell StartCom and Certinomis to start 
> over and do things right.
> 
> On the other hand, I'm not convinced yet that the issued non-BR-compliant 
> certs are any worse than we've seen from other CAs for whom we tell them to 
> fix the problem but do not add their relevant intermediate certs to OneCRL.
> 
> Kathleen

Even absent the BR-violating certificates and disclosure timeline, I believe 
this cross-sign is problematic because it appears to circumvent the 
prerequisites and process described in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 for StartCom’s application 
for re-inclusion into the Mozilla root store. It’s not clear to me what the 
point of those requirements is if they can be avoided by obtaining 
cross-signatures from other CAs that are currently trusted by Mozilla.

As far as the misissued certificates are concerned, here are a couple points to 
consider:

1) Many of the certificates are improperly validated “test” certificates, a 
practice that is extremely problematic and indicates a lack of or circumvention 
of technical controls.

2) StartCom's systems are apparently new, but they have failed to correctly 
implement simple aspects of the certificate profile such as keyUsage bits and 
character encodings. These issues are trivially detected by running tools like 
certlint and should have been caught well before the system made it into 
production.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Jonathan Rudenberg via dev-security-policy]

> On Aug 3, 2017, at 04:47, Inigo Barreira via dev-security-policy 
>  wrote:
> 
> For those which are not revoked are due to use different curves (P-384,
> P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB
> Forum and there´s no conclusion yet, but in any case we´re not allowing to
> use them anymore. There´re curves allowed in the BRs that Mozilla does not
> include. 
> 
> 2. Other un-revoked certificates have the same error “ ERROR: Unallowed key
> usage for EC public key (Key Encipherment) ”
> https://crt.sh/?opt=cablint=153404034
> https://crt.sh/?opt=cablint=160150786
> https://crt.sh/?opt=cablint=149445010
> https://crt.sh/?opt=cablint=150133570

Let’s break this down, as you have confused a few issues with this subset of 
the misissued certificates. Two certificates were issued with P-521 ECDSA keys, 
which is not allowed by Mozilla policy (note that P-384 keys are allowed):

- 
https://crt.sh/?q=87304EBF0F9391B8FFF7C8ED8D567F0340BCBAA6741972C030364DE5618C6757
- 
https://crt.sh/?q=962C955ABC03FC00F514EA41B2838D85826CA7CAA419A85EC186F1646AD5C9B5

Thirteen certificates (including the two P-521 certificates) were issued with 
the keyEncipherment bit set in the keyUsage extension (this is the message you 
mentioned above) which is not allowed (RFC 3279 section 2.3.5, incorporated by 
reference by RFC 5280 section 4.2.1.3, incorporated by reference by Baseline 
Requirements section 7.1.2.4).

One certificate linked above was issued without the key parameters field set, 
which is not allowed (RFC 3279 section 2.3.1, incorporated by reference by RFC 
5280 section 4.1.2.7, incorporated by reference by Baseline Requirements 
section 7.1.2.4):

- https://crt.sh/?opt=cablint=160150786

Hopefully this clarifies any misunderstandings around the problems with these 
specific certificates.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid CN and dnsName issued by certSIGN

[Jonathan Rudenberg via dev-security-policy]

> On Aug 2, 2017, at 12:28, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> This certificate, issued on July 27 by certSIGN, has an invalid common name 
> of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading 
> space):
> 
> https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96=cablint

The above is not the first certificate issued by certSIGN with a leading space 
in a dnsName, which points to a failure in technical controls. Here is another 
one:

https://crt.sh/?q=91782A8F1182E239D49FABA796CFDF17AFC22A0D035838FD77FDD633FC72C416=cablint

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate with invalid CN and dnsName issued by certSIGN

[Jonathan Rudenberg via dev-security-policy]

This certificate, issued on July 27 by certSIGN, has an invalid common name of 
“todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading space):

https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96=cablint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediates missing audit disclosures (Firmaprofesional)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 2, 2017, at 12:02, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> There are still three intermediates (one issued by Firmaprofesional and two 
> issued by Swisscom) that are missing audit disclosures in the CCADB and do 
> not have a pending OneCRL revocation:
> 
> - 
> https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b
>  (see https://bugzilla.mozilla.org/show_bug.cgi?id=1368171)
> 

Actually it looks like I missed that the two Swisscom intermediates are only 
trusted for email by Mozilla, so it’s just the Firmaprofesional intermediate 
that is currently in scope.

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Intermediates missing audit disclosures (Firmaprofesional and Swisscom)

[Jonathan Rudenberg via dev-security-policy]

There are still three intermediates (one issued by Firmaprofesional and two 
issued by Swisscom) that are missing audit disclosures in the CCADB and do not 
have a pending OneCRL revocation:

- 
https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b
 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1368171)
- 
https://crt.sh/?sha256=5299ea42b7ee3d4422be47d0bfc64217426b57ee55a8e5465836a741c97e628a
- 
https://crt.sh/?sha256=801c82cbc298c07f082b9d2d22a0f23427e638f94f75dee4d0e081abc9046e52

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Undisclosed Taiwan GRCA intermediates

[Jonathan Rudenberg via dev-security-policy]

Two intermediates were issued by the Taiwan Government Root Certification 
Authority two weeks ago and have not been disclosed in CCADB:

- 
https://crt.sh/?sha256=a423a33493b31953226df96477627dbd056756704211001b6161fb5f8299dc3a
- 
https://crt.sh/?sha256=dd9c545d6b645c2bfbe1b6ecb60376006464e97bb1304b7978cfe83a4099b227

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

For reference, I’ve added crt.sh links for the replacement certificates below.

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy 
>  wrote:
> 
> https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; 
> notAfter March 2017) issued by this CA which has a wildcard name in the 
> common name while the SAN contains specific domain names that would be 
> covered by the wildcard only. 
> 
> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
> 2016-03-21 when the CA discover the mistake in the SAN extension. A new 
> certificate is issued on the same day (2016-03-21) with the right SAN 
> (*.sonede.com.tn). See the certificate below:
> 

https://crt.sh/?id=15597407

> https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 
> 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 
> 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name 
> certs with validity past November 2015.) 
> 
> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
> IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
> (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
> certificate below:

https://crt.sh/?id=180718609

> https://crt.sh/?id=79470561=cablint is a certificate for the internal 
> name 'adv-ail.calladvance.local' issued by this CA with a not Before of 2017. 
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=79470561=cablint. The certificate is revoked on 
> 28/07/2017 and replaced by a new certificate which does not contain  in SAN 
> extension the internal name "adv-mail.calladvance.local". See ertificate 
> below:

https://crt.sh/?id=180718608
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy 
>  wrote:
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new 
> certificate is issued by TunServerCA2.to this end entity.
> 
> ==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 
> 2017-03-03 and issue a new one for the end entity 
> https://crt.sh/?id=99462700. The new certificate contains both names in SAN 
> (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at 
> the time of issuance, has  verified that the Applicant had the right to use 
> and had the control of the both Domain Names.
> 
> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
> 2016-03-21 when the CA discover the mistake in the SAN extension. A new 
> certificate is issued on the same day (2016-03-21) with the right SAN 
> (*.sonede.com.tn). See the certificate below:
> 
> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
> IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
> (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
> certificate below:
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=79470561=cablint. The certificate is revoked on 
> 28/07/2017 and replaced by a new certificate which does not contain  in SAN 
> extension the internal name "adv-mail.calladvance.local". See ertificate 
> below:
> 
> Olfa Kaddachi

These incidents appear to demonstrate a lack of sufficient technical controls 
to prevent certificates from being issued with unvalidated and invalid data. 
Would you please describe:

1) the technical controls currently implemented in the issuance process;
2) the deficiencies identified in those controls after the misissuance of each 
of these certificates;
3) the implemented and planned improvements to the technical controls to 
prevent these errors from happening again.

Thanks,

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Jonathan Rudenberg via dev-security-policy]

> On Jul 28, 2017, at 09:34, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Frankly I was surprised to see Chromium reverse course on this -- they have
> a history of aggressive leadership in their handling of CA failures, it's a
> little disappointing to see them abandon that.
> 
> I'd strongly advocate for us perusing an earlier date -- December 1st at
> the latest.

I strongly agree. Even if an organization has a conservative freeze in October 
for Black Friday/Cyber Monday at the end of November, replacing certificates 
issued before 2016-06-01 within the next two months should be feasible. If 
re-issuing these old certificates is problematic in any way, I would have 
expected Symantec to warn their customers and provide a solution immediately in 
March after Chrome released the first version of their plan for distrust based 
on validity period or in April/May when Chrome’s subsequent revisions of the 
plan included the 2017-08-08 distrust date.

Actions are much more compelling than delay tactics and counter-proposals, so 
the complete lack of proactive measures from Symantec indicates to me that they 
do not consider the implementation of the various detailed proposals of 
distrust over the next few months to be a problem for their customers.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Jonathan Rudenberg via dev-security-policy]

> On Jul 17, 2017, at 15:27, Nick Lamb via dev-security-policy 
>  wrote:
> 
> On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
>> Thank you for bringing this to our attention.  We have contacted Intesa 
>> Sanpaolo regarding this error and have asked them to correct it as soon as 
>> possible.
> 
> "Correcting" the error is surely the smaller of the two tasks ahead.
> 
> This CA is trusted in the Web PKI, and should have technical controls in 
> place to ensure that subject details in any certificates issued are 
> appropriately validated.
> 
> There cannot possibly have been appropriate validation of this name, because 
> it cannot exist in the Internet DNS.

I just did a quick check, and this is actually the second certificate issued 
with this error, here is the first one:

https://crt.sh/?q=A8F200048358EBC31F77D90D30BF640B7E9D39D2BFCCA93C08517BCACC1CC2CA=cablint,x509lint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate with invalid dnsName issued from Baltimore intermediate

[Jonathan Rudenberg via dev-security-policy]

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=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint

This raises some questions about the technical controls in place for issuance 
from this CA.

Jonathan


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

More improperly disclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

There are several intermediates on the dashboard 
(https://crt.sh/mozilla-disclosures) that have been incorrectly disclosed and 
have not been brought up on this list yet:

a) One intermediate issued by SECOM is undisclosed:

- 
https://crt.sh/?sha256=d8df7e1183d6def561d84d56e621a6f36a065dc717f3959bb3bafc824556d48c

b) Two intermediates issued by Swisscom do not have audit details disclosed:

- 
https://crt.sh/?sha256=5299ea42b7ee3d4422be47d0bfc64217426b57ee55a8e5465836a741c97e628a
- 
https://crt.sh/?sha256=801c82cbc298c07f082b9d2d22a0f23427e638f94f75dee4d0e081abc9046e52

(there are a few other intermediates on this list, but they are discussed 
elsewhere)

c) Two intermediates issued by Wells Fargo and one issued by SwissSign were 
revoked via CRL but have not been marked as revoked in the CCADB:

- 
https://crt.sh/?sha256=766bed35f9a700f74cec8ef941be03e5d04633d032330a06a0735715fe163c53
- 
https://crt.sh/?sha256=e8a159a056f8f67553941228ce5dff7ef72a76f34f25b225837cfc334cf6fede
- 
https://crt.sh/?sha256=98c967747ed97a1d9e1767a986b796165d9e95efad3d68fc5712e4ae97d5f21c

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign new system passed Cure 53 system security audit

[Jonathan Rudenberg via dev-security-policy]

> On Jul 11, 2017, at 06:53, okaphone.elektronika--- via dev-security-policy 
>  wrote:
> 
> On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang  wrote:
>> 
>> Please note this email topic is just for releasing the news that WoSign new 
>> system passed the security audit, just for demonstration that we finished 
>> item 5:
>> " 5. Provide auditor[3] attestation that a full security audit of the CA’s 
>> issuing infrastructure has been successfully completed. "
>> " [3] The auditor must be an external company, and approved by Mozilla. "
> 
> It also seems a bit strange to report item 5 "successfully completed" before 
> we hear anything about the other items. How about starting with item 1? What 
> are your plans voor fixing the problems?

It’s worth noting that the problems have not stopped yet. There are a bunch of 
certificates issued over the past few months that do not comply with the 
Baseline Requirements issued from the new "StartCom BR SSL ICA”, for example:

https://crt.sh/?opt=cablint=8BDFE4A526BFB35C8A417B10F4D0ABE9E1D60D28A412539D5BC71C19B46FEF21
https://crt.sh/?opt=cablint=124AAD38DAAC6B694D65F45226AB5152FC46D229CBC203E0814D175F39977FF3
https://crt.sh/?opt=cablint=9B78C78B32F4AC717B3DEFDABDACC4FEFA61BFD17782B83F75ADD82241147721
https://crt.sh/?opt=cablint=AAB0B5A08F106639A5C9D720CD37FDB30E7F337AEBAF9407FD854B5726303F7B
https://crt.sh/?opt=cablint=9DCE6A924CE837328D379CE9B7CDF4A2BA8A0E8EC01018B9DE736EBC64442361
https://crt.sh/?opt=cablint=62A9A9FDCDC04A043CF2CB1A5EAFE33CF9ED8796245DE4BD5250267ADEFF005A
https://crt.sh/?opt=cablint=6A72FA5DCC253D2EE07921898B9A9BB263FD1D20FE61B1F52F939C0C1C0DCFEE
https://crt.sh/?opt=cablint=238E2E96665748D2A05BAAEEC8BAE6AFE7B7EF4B1ADA4908354C855C385ECD81
https://crt.sh/?opt=cablint=C11C00EB0E14EEB30567D749FFD30445E0B490D1DCA7B7E082FD1CB0A40A71C0
https://crt.sh/?opt=cablint=4DEF4CFD21A969E8349E4428FDEC73767C01DE6127843312511B71029F4E3836
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jonathan Rudenberg via dev-security-policy]

> On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy 
>  wrote:
> 
> Apparently, in at least one case, the certificate was issued directly(!) to 
> localhost by Symantec.
> 
> https://news.ycombinator.com/item?id=14598262
> 
> subject=/C=US/ST=Florida/L=Melbourne/O=AuthenTec/OU=Terms of use at 
> www.verisign.com/rpa (c)05/CN=localhost
> issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
> https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
> reply
> 
> Is this a known incident?

Here is the (since expired) certificate: 
https://crt.sh/?q=07C4AD287B850CAA3DD89656937DB1217067407AA8504A10382A8AD3838D153F
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

[Jonathan Rudenberg via dev-security-policy]

> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy 
>  wrote:
> 
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
>> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via 
>> dev-security-policy wrote:
>>> If you should find such an issue again in a Cisco owned domain, please
>>> report it to ps...@cisco.com and we will ensure that prompt and proper
>>> actions are taken.
>> 
>> I don't know, this way seems to have worked Just Fine.
>> 
>> - Matt
> 
> Does no-one else see the lack of responsible disclosure in this thread 
> distressing?
> 
> Yes, the cert was revoked, and for all you know during the race that was this 
> public disclosure there could have been compromise. There are APT actors 
> watching this thread right now looking for opportunities.

The disclosure looks responsible to me.

The domain resolves to 127.0.0.1, which means that the private key can only be 
effectively leveraged by a privileged attacker that can forge DNS responses. An 
attacker that can do this can almost certainly also block online OCSP/CRL 
checks, preventing the revocation from being seen by clients. In general, 
revocation will not have any meaningful impact against misuse unless the 
certificate is included in OneCRL/CRLSets (for Firefox/Chrome).

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy