Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

[Cynthia Revström via dev-security-policy]

Hi Daniela,

Sorry if I am missing something, but what do you mean by "incorrect
revocation reason"?
The first sentence in the email sent to you by Sandy sounds pretty clear to
me "Request you revoke the all certificate associated with this
compromised key".

Also I don't see how any of what you have said you have done would help to
prevent it from taking over 24h again, could you please elaborate?

- Cynthia

On Wed, Jun 3, 2020 at 8:13 PM Daniela Hood via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello all,
>
> We appreciate the concerns and your questions to this thread. GoDaddy
> takes such issues very seriously and recognize the importance to the
> industry and health of the ecosystem.
>
> ​In the case where the user selected the incorrect revocation reason, we
> identified the error shortly before it was reported as part of a standard
> review. We reviewed the error with the user and corrected it the same day,
> per our procedure. Upon reviewing with the user, we identified an
> opportunity to enhance our process through additional visual cues to enable
> the agent to perform a final review prior to committing a revocation.
> Additionally, our process includes team calibrations where prior errors are
> used as training opportunities for the entire team. We also include any
> areas that have changed or where we notice an increased instance of errors
> in our annual training program. All of these efforts in combination help us
> to keep the instance of errors down and address situations as they arise.
>
> We hope this information helps address concerns regarding this error.
>
> Thank you,
>
> Daniela Hood
> GoDaddy
>
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Daniela Hood via dev-security-policy
> Sent: Friday, May 29, 2020 9:16 PM
> To: 'r...@sleevi.com' 
> Cc: dev-security-policy@lists.mozilla.org
> Subject: RE: GoDaddy: Failure to revoke certificate with compromised key
> within 24 hours
>
> Notice: This email is from an external sender.
>
>
>
> GoDaddy acknowledges the inquiry and we will work to have a response to
> the community by Wednesday, June 3rd.
>
>
> Daniela Hood
> GoDaddy | Compliance Manager
> [https://email-sig.gd-resources.net/img/godaddy-logo-outline.png]
> +16026881766
> Gilbert, Arizona, United States
> dxh...@godaddy.com
>
>
> From: Ryan Sleevi 
> Sent: Friday, May 29, 2020 7:52 AM
> To: Daniela Hood 
> Cc: dev-security-policy@lists.mozilla.org
> Subject: Re: GoDaddy: Failure to revoke certificate with compromised key
> within 24 hours
>
> Notice: This email is from an external sender.
>
>
> Thank you for your update.
>
> This does not appear to answer the questions raised. I would appreciate if
> GoDaddy shared a more meaningful response, in line with addressing the
> concerns Nick raised, as well as the outstanding matters on the bug.
>
> In particular, this response fails to analyze what went wrong, what has
> been done systemically by GoDaddy to prevent future incidents, and what are
> practices other CAs should consider to prevent similar incidents.
>
> In addition to the outstanding question from Nick, for this sort of
> response to be acceptable at all, more detail is needed:
> - What improvements were made, and why?
> - What training was done? What was changed? How is the training performed
> and evaluated? Why did the previous training fail to address this? Why is
> training seen as an acceptable answer, given previous training failed? What
> is done to support and monitor compliance to training?
> - What changes were made to the system? Why would they address this issue?
> How does that relate to why the issue?
>
> In 2020, publicly trusted CAs should not be expecting that such “incident
> reports”, if this can even be called that, are sufficient. As stewards of
> the trust placed in them by Mozilla and the broader community, and by other
> root stores, substantive and highly detailed, technical responses are
> expected. The goal of these reports is to both simultaneously address
> concerns caused by the failure to adhere to expectations and to help ensure
> that all CAs have an opportunity to learn from and implement similar
> mechanisms. If the response does not have sufficient information to allow
> for an independent implementation of whatever mitigations, and to the same
> level of assurance, it quite simply is not a response that meets
> expectations. We need to be able to work together, as an industry, to move
> things forward, and that requires complete transparency.
>
> On Thu, May 28, 2020 at 7:55 PM Daniela Hood via dev-security-policy <
> dev-security-policy@lists.mozilla.org dev-security-policy@lists.mozilla.org>> wrote:
> Hello,
>
> We have made improvements on our problem reporting process, provided more
> training to our agents and made changes in our system to assure that such
> error would not happen again. We will keep on working with the community to
> find 

Re: Policy Module Ownership

[Cynthia Revström via dev-security-policy]

Thank you Wayne for all you have done!

>From what I have seen in my limited experience with the MDSP, you have done
an excellent job, and you will be missed.

Good luck with whatever you are doing next!

- Cynthia

On Tue, Jan 21, 2020 at 11:10 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I have decided to leave Mozilla, effective this Friday.
>
> I expect Mozilla to hire a replacement, but that will of course take time.
> In the interim, I will remain the CA Certificate Policy Module Owner and
> contribute to the best of my ability in a volunteer capacity.
>
> Please feel free to contact me or Kathleen with any questions or concerns.
>
> I want to take this opportunity to once again thank everyone for your
> support and contributions to this amazing community.
>
> - Wayne
> ___
> 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: DNS records and delegation

[Cynthia Revström via dev-security-policy]

Hello,

I just want to add that Let's Encrypt also allows for this (at least if I
understand what you correctly)

This following is from https://letsencrypt.org/docs/challenge-types/
> Since Let’s Encrypt follows the DNS standards when looking up TXT records
for DNS-01 validation, you can use CNAME records or NS records to delegate
answering the challenge to other DNS zones. This can be used to delegate
the _acme-challenge subdomain to a validation-specific server or zone. It
can also be used if your DNS provider is slow to update, and you want to
delegate to a quicker-updating server.

Now you don't delegate it to Let's Encrypt, however you can delegate it to
a hosting provider or similar, which seems to be about the same as what AWS
is doing if I understand you correctly.

- Cynthia Revström

On Fri, Oct 11, 2019 at 7:32 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Question, is there any prohibition against demonstration of domain
> control
> > being delegated to a third party or even the CA itself? I don't think so,
> > but figured we've discussed differences in interpretation a lot lately so
> > wanted to see if people agreed.
> >
>
> Huge thanks for bringing this up early :) Definitely the example for all
> CAs :)
>
> That said, you probably could have worded better, "demonstration of domain
> control being delegated to a third party" is... probably not the best way
> of framing ;)
>
>
> > I mean, the obvious issue is the customer.com domain would need to want
> > to delegate this domain.com. But if you had a pretty non-technical
> person
> > operating the DNS, they could set it to the domain.com name and leave
> > their DNS settings forever.
> >
> > This looks allowed under the BRs, but should it be? Or is it like key
> > escrow - okay if a reseller does it (but frowned upon). Totally not cool
> if
> > the CA does it.
> >
>
> This is definitely a good way of looking at it!
>
> I'm familiar with at least one CA using an approach like this - Amazon
> Trust Services, with
> https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html
> .
> There's subtlety here, though, which is why I like how you drew the
> comparison to key escrow.
>
> On first glance, it seems Amazon Trust Services is issuing certificates to
> Amazon Web Services, both (through a complex structure) Affiliates, on
> behalf of the user. And so it might seem that the user is pointing their
> DNS to the CA, and that's how it's working.
>
> However, when you look through the CCADB disclosures, along with the
> certificates actually issued, it's clearer that the user is pointing those
> records to Amazon Web Services, but the actual issuing CA is DigiCert (as
> disclosed at https://www.amazontrust.com/repository/ ). It's also the case
> that, if you look at how things are setup, the domain holder isn't the one
> applying for the certificate - it's Amazon Web Services applying for the
> certificate (i.e. they are the Applicant, not the domain owner), and AWS
> configuring their own DNS records to contain a random value, to demonstrate
> to the CA (DigiCert) that AWS, the Applicant, is authorized for the domain.
>
> It's a really elegant solution, but it turns out it's not a "CA
> self-dealing" kind of thing, which would have been useful as an example if
> it was already allowed.
>
> Now let's discuss how this idea could all go wrong, because it teases out a
> little why the question of who is Applicant is relevant and important to
> understanding.
>
> Let's imagine that I setup the following (and I'm going to butcher this
> pseudo-code, so bear with me)
> _validation.sleevi.example 3600 IN CNAME .ca.example
> .ca.example 1 IN CNAME .random.ca.example
> .random.ca.example 1 IN TXT "{the CA challenge goes here}"
>
> Now, whenever the CA receives a request to validate "sleevi.example", they
> map that to a domain-id. They then update the CNAME, and the TXT record, to
> match the CA-defined challenge value. Then, they issue a TXT record lookup
> for _validation.sleevi.example, get the challenge value back, and huzzah,
> the cert is authorized!
>
> But there's a small problem with this. Who was the Applicant requesting
> sleevi.example? From the CA's perspective, how does it distinguish me, the
> legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the
> Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear -
> only AWS can do this, and they're who the user delegated to.
>
> However, if the "party doing this domain dance" is != "the applicant", then
> a lot can go wrong here, because they might do the dance for two different
> applicants. The easiest example would be if the CA, for every CSR it
> received, regardless of the Applicant, it updated the  for
> sleevi.example - at that point, anyone in the world could get a cert for my

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Cynthia Revström via dev-security-policy]

Kirk, may I remind you that Ryan Sleevi is posting in personal capacity
here, as is the default on m.d.s.p unless otherwise specified.
So please do not drag his employer into this discussion.

Ryan SleeviPeer of the CA Certificates Module
; Works for Google
; PKI policy for Chrome/ChromeOS; Posting in a
personal capacity, with posts not necessarily representing the views of
Google or the Mozilla CA Certificate Module, except where otherwise noted.
From: https://wiki.mozilla.org/CA/Policy_Participants

- Cynthia

On Sun, Sep 22, 2019 at 6:56 AM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Saturday, September 21, 2019 at 6:19:29 PM UTC-7, Ryan Sleevi wrote:
> > On Sat, Sep 21, 2019 at 7:52 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server
> > > certificate customers over three days (19-21 September 2019) concerning
> > > website identity in browsers, browser UIs in general, and EV browser
> UIs in
> > > particular.  We have received 504 responses from customers to date, and
> > > more responses are still coming in. Respondent company size ranged all
> the
> > > way from 1-99 employees to over 20,000 employees.
> >
> >
> > Thanks for sharing this interesting marketing data by Entrust DataCard.
> > It's always good to see the marketing teams able to reach out to their
> > customers, as it gives hope that there's improvements being made to
> ensure
> > timely revocation.
> >
> > Since numbers like "92%" sound quite large, unless and until they're put
> > into context, I wanted to make sure there was a clear picture about what
> > those 504 responses represent.
> >
> > 1) Based on Entrust Datacard's CP/CPS, it only issues OV/EV certificates.
> > Is this correct? This is largely to account for self-selection issues,
> > since one might expect 100% of respondents that have already chosen a
> > particular service to, well, respond in similar numbers.
> >
> > 2) Related, looking at the numbers published by Firefox Telemetry, over a
> > two month period of connections made by Firefox users, only a small
> > fraction, approximately 0.3%, encounter certificates from Entrust
> DataCard.
> > This is roughly 120 million connections out of 39.49 billion. Does that
> > match Entrust DataCard's analysis about the size of its customer base?
> >
> > You can check the math at telemetry.mozilla.org,
> > using CERT_VALIDATION_SUCCESS_BY_CA as the metric. Based on
> RootHashes.inc,
> > it appears Entrust DataCard operated CAs are the buckets 10, 18, 109,
> 110,
> > 111, 112, 163, and 164, which matches the 8 CAs Entrust has disclosed in
> > CCADB that are trusted by Mozilla. Three of these CAs have seemingly not
> > been used to verify any connections, while of the remaining 5, it seems
> > that only Entrust Root Certification Authority - G2 sees any real use.
> >
> > 3) Are the numbers Entrust DataCard provided in
> >
> https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf
> > still accurate? That is, do EV certificates account for only 0.48% of the
> > certificate population?
> >
> > If those numbers are correct, this seems like it's a survey that
> represents
> > a small fraction of Entrust DataCard's customers (unless Entrust DataCard
> > only a few thousand customers), which represents a small fraction of
> > connections in Mozilla Firefox (approximately 0.3% over a 2 month
> period),
> > regarding certificates that account for only 0.48% of the certificate
> > population.
> >
> > Is that the correct perspective?
>
> The data I posted is correct, so I'm not really sure what point(s) you are
> making.
>
> Does Google Chrome have any data from its own surveys of website owners'
> opinions it's willing to share?  It's one thing to be a critic of the work
> of others, it's another thing to actually create useful and meaningful data
> yourself and share with the Mozilla community.
>
> What data from Chrome can you share with us?
> ___
> 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: Intent to Ship: Move Extended Validation Information out of the URL bar

[Cynthia Revström via dev-security-policy]

>
> Because no actual proof that DV versus EV makes no difference in the
> current (not ancient or anecdotal) situation has been posted.
>
>
To me that sounds like you are suggesting that we prove that nothing
happened, which is pretty much impossible.
Why don't you or the CAs offering EV prove that it did have a significant
impact?

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

Re: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

I would like to point out that in the recent appeal PDF posted on bugzilla
showed darkmatter.ae in the footer on page 2 and onwards. This further
makes me believe that there is not much separation of the entities.

- Cynthia

On Wed, 17 Jul 2019, 01:29 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> I have to rebut the idea that revoking trust is an adequate -- let alone
> an "essentially absolute" -- recourse for a CA's abuse of its authority.
>
> The fact is that an abusive CA can cause unwanted (and potentially
> harmful) code and data to be injected into -- and personal data to be
> exfiltrated from -- nearly any user's device on the entire global internet.
>
> Once data is exfiltrated, its rightful owner has lost control of it
> forever. Revoking trust in the abusive CA that caused this loss does not
> amend it. Once a device is penetrated, it can be very difficult to
> disinfect, even assuming that the user knows that it has been
> penetrated. Such a device might function as a spy upon and/or an editor
> of its victim's data (and the data of persons with whom the victim
> communicates) indefinitely. An infected device is not in any way "fixed"
> by revoking trust in the abusive CA that caused it to become infected.
> Furthermore, an infected device can infect other devices, both locally
> and globally.
>
> The consequences to victims of breaches caused by an abusive CA can be
> extreme, potentially including prosecution, imprisonment, and worse. And
> revoking trust does nothing to amend these consequences.
>
> This is all but to say that enormous responsibility rests upon CAs, and
> even more so upon trust-store custodians, who effectively are supposed
> to protect every user on the global internet from bad actors. We must
> not lose sight of these facts while we argue about process, profit, and
> whatnot else.
>
> -R
>
> On 7/16/2019 2:23 PM, Matthew Hardeman via dev-security-policy wrote:
> > I also disagree with the contention that Mozilla has "effectively no
> > recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
> > on the borrowed trust through providing services to certificate
> subscribers
> > only in compliance with program and industry guidelines and with proper
> > validations.)  Mozilla's recourse is essentially absolute: you can revoke
> > the trust you've extended, preventing further damage.
>
> ___
> 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: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

Hi Scott,
Below is my personal view on it, I acknowledge that it is highly subjective.

For one, people and companies in the UAE could get certs from non-UAE CAs.
I live in Sweden, yet I have certs from Norwegian, British, and American
CAs.

Another issue I have is that I think there is a difference between a
government such as the US, UK, etc and the UAE due to the UAE not being an
electoral democracy and doesn't really have much transparency from what I
know.

As I have said before, if Mozilla and the community considers it a risk, it
may not be worth it.
It would be different in a more isolated industry, but in the "CA
Industry", one CA's mistake will be felt by the entire world.

Now, my personal view is that we shouldn't really have CAs that are
connected with non-democratic governments (such as China Financial
Certification Authority) at all.

- Cynthia

On Wed, Jul 10, 2019 at 6:43 PM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> G’day Folks,
>
> DigitalTrust first learned of the Mozilla decision via Reuters. We believe
> this is emblematic of Mozilla’s approach to our application which appears
> to have been predetermined from the outset.
>
> We believe yesterday’s decision is unfair and demonstrates an anti-UAE
> bias where a 2016 media report referring to a single claimed event that
> aims to falsely implicate DarkMatter (and repeatedly echoed over a span of
> 4 years) has now outranked Mozilla’s established process of demonstrated
> technical compliance. This very same compliance has been met by
> DigitalTrust for three consecutive years with full transparency.
>
> The emerging principle here seems to be that 508 WebTrust audit controls
> are not sufficient to outweigh a single media allegation referring to work
> we as well as DarkMatter simply don’t do. In fact DarkMatter’s work is
> focused on the exact opposite of the false claim as evidenced by the
> continuous work to protect all internet users, for example through on-going
> disclosure of zero day vulnerabilities to the likes of Cisco, Sony, ABB and
> others.
>
> Mozilla’s new process, based on its own admission, is to ignore technical
> compliance and instead base its decisions on some yet to be disclosed
> subjective criterion which is applied selectively.  We think everybody in
> the Trust community should be alarmed by the fact that the new criterion
> for inclusion of a commercial CA now ignores any qualification of the CA or
> its ability to demonstrate compliant operations. We fear that in doing so
> Mozilla is abandoning its foundational principles of supporting safe and
> secure digital interactions for everyone on the internet.  This new process
> change seems conveniently timed to derail DigitalTrust’s application.
>
> By Mozilla’s own admission, DigitalTrust is being held to a new standard
> which seems to be associated with circular logic – a media bias based on a
> single claimed event that aims to falsely implicate DarkMatter is then used
> to inform Mozilla’s opinion, and the media seizes on this outcome to
> substantiate the very same bias it aimed to introduce in the first place.
> Additionally, in targeting DigitalTrust and in particularly DarkMatter’s
> founder Faisal Al Bannai, on the pretense that two companies can’t operate
> independently if they have the same owner, we fear another dangerous
> precedent has been set.
>
> What’s at stake here is not only denial of the UAE’s Roots but also
> Mozilla’s denial of the UAE’s existing issuing CAs. This means the nation’s
> entire Public Trust customer base is now denied the same digital
> protections that everyone else enjoys.
>
> We fear that Mozilla’s action to apply this subjective process selectively
> to DigitalTrust effectively amounts to incremental tariffs on the internet
> with Mozilla de-facto promoting anti-competitive behavior in what was once
> a vaunted open Trust community.  Mozilla is now effectively forcing the UAE
> to protect its citizens by relying on another nation or commercial CA –
> despite DigitalTrust meeting all of Mozilla’s previously published criteria
> – thus protecting a select number of operators and excluding or forcing
> newcomers to pay a premium without the added benefit of control.
>
> In conclusion we see only two possible paths going forward.
>
> Under the first path, we demand that Mozilla’s new standard be explicitly
> disclosed and symmetrically applied to every other existing member of the
> Mozilla Trust Program, with immediate effect. This would cover, based on
> the precedent of the DigitalTrust case, any CA deemed to be a risk to the
> Trust community, despite lacking substantive evidence. This would suggest
> that any CA that serves a national function, is working closely with
> governments to secure the internet for its citizens, or is associated to
> other practices covering cyber security capabilities (which would include a
> large group of countries and companies) would have to 

Re: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

My view is a bit different, we have lots of CAs already, I think it is more
important to be extra secure rather than to take unnecessary risks.
While I do understand that Dark Matter's focus is on the UAE, I also have
to say, as far as I am aware, there are multiple CAs that will issue certs
to people in the UAE.
That would be my view if I knew nothing else about DarkMatter, but due to
the stuff piling up against them I have to say this, why take the risk?
At some point we have to go and think about other parts than purely
technical capability, and there seems to be evidence that Dark Matter has
done sketchy stuff in the past.
This all makes it hard for me to personally justify why the DM should be
included.
While I don't like making it hard for new competitors to enter, the CA
market is quite special where everyone has to behave properly otherwise the
system doesn't work.

And even if this is just concerns and nothing actually happened, why should
they be included? A CA has to be trusted, if people who work with this
don't trust them, I don't see why they should be included.

- Cynthia

On Sun, Jun 23, 2019 at 6:44 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That article doesn’t seem to say anything new about Dark Matter that
> hasn’t been reported before, doesn’t present evidence and doesn’t cite
> sources. Furthermore the article appears to allege that Dark Matter
> “discussed” potentially targeting The Intercept, not that it “tried to hack
> several of their employees”. To wit, from the article:
>
> "It is not clear if an attack against The Intercept was ever carried out."
>
> I understand the concerns regarding Dark Matter but uncertainty shouldn’t
> lead to this level of low quality arguments. I still hope that stronger
> evidence against Dark Matter will come forward so that this can be settled
> once and for all.
>
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
>
> > On Jun 21, 2019, at 7:43 PM, coop...@gmail.com wrote:
> >
> > This thread hasn't been updated in a while so I'm not sure what the
> status is of dark matter being accepted but I thought this was a relevant
> update. The, US based reporting agency The Intercept recently issued a
> report claiming that Dark Matter has tried to hack several of their
> employees.
> https://theintercept.com/2019/06/12/darkmatter-uae-hack-intercept/
> >
> > I'm sure that Dark Matter will claim this is "fake news" as they have
> previously, but I'm not inclined to believe that The Intercept would
> publish a story of this magnitude without fact checking and unless they
> were 100% sure of it. At this point I feel that there is a preponderance of
> evidence that Dark Matter are bad faith actors and would significantly
> diminish the trustworthiness of the CA system if they were to be included.
>
> ___
> 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: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

Exactly what I was thinking

On 2019-03-07 09:21, Georg Koppen via dev-security-policy wrote:

Benjamin Gabriel via dev-security-policy:

Dear Ryan,

A fair and transparent public discussion requires full disclosure of each 
participant's motivations and ultimate agenda.

It would be neat if you could tone down your rhetoric a bit and refrain
from ad-hominem attacks. That would help the general discussion in this
thread, I think, and you would stop doing you a disservice that way as well.

Georg


___
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: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

On 2019-03-07 06:14, Benjamin Gabriel via dev-security-policy wrote:


Until such time as we have been formally advised by your employer (Google), 
that you no longer represent their views in CABForum, or in this 
Mozilla-dev-security-policy forum, we will proceed on the basis that all of 
your statements are the official viewpoint of your employer (Google).


I have to say this, you are being very hostile currently and I don't 
think it is helping you come across as something that should be included 
in the root store.


- Cynthia

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

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

On 2019-03-04 20:23, Jeremy Rowley via dev-security-policy wrote:


2) Of the 3,000, the only certificate we found where the scope was not set
to be the scope of the WHOIS document was the one reported by Cynthia.


That is good to hear :)

- Cynthia

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

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

On 2019-03-02 01:49, George Macon via dev-security-policy wrote:


One specific question on this point: Why did the software permit setting
the approval scope to a public suffix (as defined by inclusion on the
public suffix list)? Could validation agent action set the approval
scope to some other two-label public suffix like co.uk?


I think this is highly unlikely seeing as this was a human error and 
unlike in-addr.arpa, people might know about .co.uk.


- Cynthia

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

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

Okay that seems like an issue as to me that says that this could have 
happened to any domain and not just in-addr.arpa?


- Cynthia

On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote:

 From our side, a validation agent weirdly scoped the domain, saying that the 
domain was approved using an email to ad...@in-addr.arpa. However, the email 
clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how 
did the validation staff override the domain approval scope and 2) did anyone 
in validation ever do this before. Once we complete that search, we'll be able 
to file a bug report and give you more information on what exactly went wrong.

.arpa is in IANA's root zone per https://www.iana.org/domains/root/db.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman 
Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the email it 
had an option along the lines of "Authorize in-addr.arpa for all orders on account 
#123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com, I could get a cert for google.com if this 
is a systemic issue and not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:

Is it even proper to have a SAN dnsName in in-addr.arpa ever?

While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
rarely has anything other than PTR and NS records defined.

Here this was clearly achieved by creating a CNAME record for
69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>.

I've never seen any software or documentation anywhere attempting to
utilize a reverse-IP formatted in-addr.arpa address as though it were
a normal host name for resolution.  I wonder whether this isn't a case
that should just be treated as an invalid domain for purposes of SAN
dnsName (like .local).

On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>> wrote:

 Thanks Cynthia. We are investigating and will report back shortly.
 
 From: dev-security-policy
 mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
     of Cynthia Revström via dev-security-policy
 mailto:dev-security-policy@lists.mozilla.org>>
 Sent: Tuesday, February 26, 2019 12:02:20 PM
 To: dev-security-policy@lists.mozilla.org
 <mailto:dev-security-policy@lists.mozilla.org>
 Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk>
 Subject: Possible DigiCert in-addr.arpa Mis-issuance

 Hello dev.security.policy


 Apologies if I have made any mistakes in how I post, this is my first
 time posting here. Anyway:


 I have managed to issue a certificate with a FQDN in the SAN that I do
 not have control of via Digicert.


 The precert is here: https://crt.sh/?id=1231411316

 SHA256:
 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


 I have notified Digicert who responded back with a generic response
 followed by the certificate being revoked through OCSP. However I
 believe that this should be wider investigated, since this cert was
 issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
 that I do control though reverse DNS.


 When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
 that the whole of in-addr.arpa became validated on my account, instead
 of just my small section of it (168.110.79.in-addr.arpa at best).


 To test if digicert had just in fact mis-validated a FQDN, I
 tested with
 the reverse DNS address of 192.168.1.1, and it worked and Digicert
 issued me a certificate with 1.1.168.192.in-addr.arpa on it.


 Is there anything else dev.security.policy needs to do with this? This
 seems like a clear case of mis issuance. It's also not clear if
 in-addr.arpa should even be issuable.


 I would like to take a moment to thank Ben Cartwright-Cox and
 igloo5
 in pointing out this violation.


 Regards

 Cynthia Revström

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

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.


It was just that I just tried to get a cert for my domain for a test to 
see if that would be issued.


And upon verifying the domain via email, I saw that on the page linked 
in the email it had an option along the lines of "Authorize in-addr.arpa 
for all orders on account #123456" (not that exact text but the same 
meaning).


Now I am not sure if this would work, but I suspect if for example I got 
DNS control over cynthia.site.google.com, I could get a cert for 
google.com if this is a systemic issue and not just a one off.


- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:

Is it even proper to have a SAN dnsName in in-addr.arpa ever?

While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
rarely has anything other than PTR and NS records defined.


Here this was clearly achieved by creating a CNAME record for 
69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>.


I've never seen any software or documentation anywhere attempting to 
utilize a reverse-IP formatted in-addr.arpa address as though it were 
a normal host name for resolution.  I wonder whether this isn't a case 
that should just be treated as an invalid domain for purposes of SAN 
dnsName (like .local).


On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
<mailto:dev-security-policy@lists.mozilla.org>> wrote:


Thanks Cynthia. We are investigating and will report back shortly.

From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
    of Cynthia Revström via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
Sent: Tuesday, February 26, 2019 12:02:20 PM
To: dev-security-policy@lists.mozilla.org
<mailto:dev-security-policy@lists.mozilla.org>
Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk>
Subject: Possible DigiCert in-addr.arpa Mis-issuance

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first
time posting here. Anyway:


I have managed to issue a certificate with a FQDN in the SAN that I do
not have control of via Digicert.


The precert is here: https://crt.sh/?id=1231411316

SHA256:
651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response
followed by the certificate being revoked through OCSP. However I
believe that this should be wider investigated, since this cert was
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
that I do control though reverse DNS.


When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
that the whole of in-addr.arpa became validated on my account, instead
of just my small section of it (168.110.79.in-addr.arpa at best).


To test if digicert had just in fact mis-validated a FQDN, I
tested with
the reverse DNS address of 192.168.1.1, and it worked and Digicert
issued me a certificate with 1.1.168.192.in-addr.arpa on it.


Is there anything else dev.security.policy needs to do with this? This
seems like a clear case of mis issuance. It's also not clear if
in-addr.arpa should even be issuable.


I would like to take a moment to thank Ben Cartwright-Cox and
igloo5
in pointing out this violation.


Regards

Cynthia Revström

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
<mailto: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
<mailto: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

Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first 
time posting here. Anyway:



I have managed to issue a certificate with a FQDN in the SAN that I do 
not have control of via Digicert.



The precert is here: https://crt.sh/?id=1231411316

SHA256: 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response 
followed by the certificate being revoked through OCSP. However I 
believe that this should be wider investigated, since this cert was 
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area 
that I do control though reverse DNS.



When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed 
that the whole of in-addr.arpa became validated on my account, instead 
of just my small section of it (168.110.79.in-addr.arpa at best).



To test if digicert had just in fact mis-validated a FQDN, I tested with 
the reverse DNS address of 192.168.1.1, and it worked and Digicert 
issued me a certificate with 1.1.168.192.in-addr.arpa on it.



Is there anything else dev.security.policy needs to do with this? This 
seems like a clear case of mis issuance. It's also not clear if 
in-addr.arpa should even be issuable.



I would like to take a moment to thank Ben Cartwright-Cox and igloo5 
in pointing out this violation.



Regards

Cynthia Revström

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