Re: Possible DigiCert in-addr.arpa Mis-issuance
> > I believe the list was merely a crt.sh query of all unexpired certificates > with a dNSName ending in "in-addr.arpa": > https://crt.sh/?dNSName=%25.in-addr.arpa=expired Any list for this general issue should also consider unexpired certificates with a dNSName ending in "ip6.arpa" to cover the IPv6 reverse zone in addition to the IPv4 one. I noticed there are similar interesting wildcards/host nodes under the ip6.arpa zone when I was writing a linter[0] for this. [0] - https://github.com/zmap/zlint/pull/260 On Wed, Feb 27, 2019 at 10:05 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, February 27, 2019 at 10:43:15 AM UTC-5, Tim Hollebeek wrote: > > > On 27/02/2019 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. > > > > > > > > > > While there is no current use, and the test below was obviously > somewhat > > > contrived (and seems to have triggered a different issue), one cannot > rule > > > out > > > the possibility of a need appearing in the future. > > > > At least the last time this came up a few years ago, there were actually > a > > significant number of webservers running under in-addr.arpa, with Comodo > and > > LE certificates (as well as a handful of others). I believe Corey > posted a > > list. > > > > Exactly what they were doing there is an open question, and when I > asked, no > > one responded. I'm still very curious as to why some people seem to > actually > > be running servers there, or if it's just a side-effect of misconfigured > > CNAMEs causing them to appear to be there, or similar. > > > > -Tim > > Hi Tim, > As you said, I vaguely recall this coming up in some discussion (perhaps > in the CAB Forum Validation Subcommittee?) but nothing was concluded. I > believe the list was merely a crt.sh query of all unexpired certificates > with a dNSName ending in "in-addr.arpa": > https://crt.sh/?dNSName=%25.in-addr.arpa=expired > > The query results are definitely worth a look as there are some unexpected > findings, such as wildcards (such as "*.0.195.206.in-addr.arpa") and host > nodes (such as "www.175.232.77.in-addr.arpa", etc.) under in-addr.arpa. > Several of the domain names starting with "www" actually appear to resolve > to an IP address with a web server running. Definitely an interesting > (ab)use of the reverse zones. > > Thanks, > Corey > ___ > 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: Possible DigiCert in-addr.arpa Mis-issuance
On Thu, Feb 28, 2019 at 6:21 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, 28 Feb 2019 05:52:14 +
> Jeremy Rowley via dev-security-policy
> wrote:
>
> Hi Jeremy,
>
> > 4. The validation agent specified the approval scope as id-addr.arpa
>
> I assume this is a typo by you not the agent, for in-addr.arpa ?
>
> Meanwhile, and without prejudice to the report itself once made:
>
> > 2. The system marked the WHOIS as unavailable for automated parsing
> > (generally, this happens if we are being throttled or the WHOIS info
> > is behind a CAPTCHA), which allows a validation agent to manually
> > upload a WHOIS document
>
> This is a potentially large hole in issuance checks based on WHOIS.
>
> Operationally the approach taken ("We can't get it to work, press on")
> makes sense, but if we take a step back there's obvious potential for
> nasty security surprises like this one.
>
> There has to be something we can do here, I will spitball something in
> a next paragraph just to have something to start with, but to me if it
> turns out we can't improve on basically "sometimes it doesn't work so
> we just shrug and move on" we need to start thinking about deprecating
> this approach altogether. Not just for DigiCert, for everybody.
>
> - Spitball: What if the CA/B went to the registries, at least the big
> ones, and said we need this, strictly for this defined purpose, give
> us either reliable WHOIS, or RDAP, or direct database access or
> _something_ we can automate to do these checks ? The nature of CA/B
> may mean that it's not appropriate to negotiate paying for this
> (pressuring suppliers to all agree to offer members the same rates is
> just as much a problem as all agreeing what you'll charge customers)
> but it should be able to co-ordinate making sure members get access,
> and that it isn't opened up to dubious data resellers that the
> registries don't want rifling through their database.
>
Unfortunately, this is not really viable. The CA/Browser Forum maintains
relationships with ICANN, as do individual members. While this, on its
face, seems reasonable, there are practical, business, and legal concerns
that prevent this from being viable. Further, proposals which would require
membership in the CA/Browser Forum should, on their face, be rejected - a
CA should not have to join the Forum in order to be a CA.
I do agree, however, that the use of WHOIS data continues to show
problematic incidents - whether it's with OCR issues or manual entry - and
suspect a more meaningful solution is to move away from this model
entirely. The recently approved methods to the BRs for expressing contact
information via the DNS directly is one such approach. The GDPR issues
surrounding WHOIS and RDAP have already led it to be compelling in its own
right.
Most importantly, you are on the right path of questions, though - which is
we should examine such incidents systemically and look for improvements,
and not convince ourselves that the status quo is the best possible
solution :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
AW: CFCA certificate with invalid domain
I just sent them a certificate problem report. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > -Ursprüngliche Nachricht- > Von: dev-security-policy Im > Auftrag von michel.lebihan2000--- via dev-security-policy > Gesendet: Mittwoch, 27. Februar 2019 08:54 > An: mozilla-dev-security-pol...@lists.mozilla.org > Betreff: CFCA certificate with invalid domain > > 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. > ___ > 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: Possible DigiCert in-addr.arpa Mis-issuance
On Thu, 28 Feb 2019 05:52:14 +
Jeremy Rowley via dev-security-policy
wrote:
Hi Jeremy,
> 4. The validation agent specified the approval scope as id-addr.arpa
I assume this is a typo by you not the agent, for in-addr.arpa ?
Meanwhile, and without prejudice to the report itself once made:
> 2. The system marked the WHOIS as unavailable for automated parsing
> (generally, this happens if we are being throttled or the WHOIS info
> is behind a CAPTCHA), which allows a validation agent to manually
> upload a WHOIS document
This is a potentially large hole in issuance checks based on WHOIS.
Operationally the approach taken ("We can't get it to work, press on")
makes sense, but if we take a step back there's obvious potential for
nasty security surprises like this one.
There has to be something we can do here, I will spitball something in
a next paragraph just to have something to start with, but to me if it
turns out we can't improve on basically "sometimes it doesn't work so
we just shrug and move on" we need to start thinking about deprecating
this approach altogether. Not just for DigiCert, for everybody.
- Spitball: What if the CA/B went to the registries, at least the big
ones, and said we need this, strictly for this defined purpose, give
us either reliable WHOIS, or RDAP, or direct database access or
_something_ we can automate to do these checks ? The nature of CA/B
may mean that it's not appropriate to negotiate paying for this
(pressuring suppliers to all agree to offer members the same rates is
just as much a problem as all agreeing what you'll charge customers)
but it should be able to co-ordinate making sure members get access,
and that it isn't opened up to dubious data resellers that the
registries don't want rifling through their database.
My argument to the registries would be that this is a service for their
customers. Unlike the data resellers, either the registry customer, or
some agent of theirs is asking you to authenticate their registration,
so giving you access makes sense as part of what the registry does for
its customers anyway.
> 7. During the review, no one noticed that the WHOIS document did not
> match the verification email nor did anyone notice that the email
> used for verification was actually a constructed email instead of the
> WHOIS admin email
So, reviews are good, but this review was not very effective. Valuable
to consider in the final report why not and how that can be improved.
Just to be clear though, are you sure "no one noticed" ? It can happen
that in review processes somebody does notice the issue, but they
are persuaded or persuade themselves that it's fine. A British railway
incident occurred when the person transcribing a document effectively
"moved" a railway crossing. Manual reviewers did see it, and so did the
controllers responsible for managing the crossing, but both persuaded
themselves that the movement must be a correction and approved it.
With the crossing now shown in the wrong place, instructions authorising
use of the crossing were no longer protected by the controller's view
of the movement of trains, this resulted in a "near miss" and thanks to
the victim's persistence in demanding it be properly investigated
fortunately accident investigators visited the crossing, found the
mistake and had things corrected before anyone died.
Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
(Writing in a personal capacity) I want to preemptively apologize for the length of this message. Despite multiple rounds of editing, there's still much to be said, and I'd prefer to say it in public, in the spirit of those past discussions, so that they can be both referred to and (hopefully) critiqued. These discussions are no easy matter, as shown from the past conversations regarding both TeliaSonera [1] and CNNIC [2][3][4][5]. There have been related discussions [6][7], some of which even discuss the UAE [8]. If you go through and read those messages, you will find many similar messages, and from many similar organizations, as this thread has provoked. In looking at these older discussions, as well as this thread, common themes begin to emerge. These themes highlight fundamental questions about what the goals of Mozilla are, and how best to achieve those goals. My hope is to explore some of these questions, and their implications, so that we can ensure we're not overlooking any consequences that may result from particular decisions. Whatever the decision is made - to trust or distrust - we should at least make sure we're going in eyes wide open as to what may happen. 1) Objectivity vs Subjectivity Wayne's initial message calls it out rather explicitly, but you can see it similarly in positions from past Mozilla representatives - from Gerv Markham, Sid Stamm, Jonathan Nightingale - and current, such as Kathleen Wilson. The "it" I'm referring to is the tension between Mozilla's Root Program, which provides a number of ideally objective criteria for CAs to meet for inclusion, and the policy itself providing significant leeway for Mozilla to remove CAs - for any reason or no reason - and to take steps to protect its users and its mission, an arguably subjective decision. This approach goes back to the very first versions of the policy, written by Frank Hecker for the then-brand new Mozilla Foundation [9][10]. Frank struggled with the issue then [11], so perhaps it is unsurprising that we still struggle with it now. Thankfully, Frank also documented quite a bit of his thinking in drafting that policy, so we can have some insight. [12] The arguments for the application of a consistent and objective policy have ranged from being a way to keep Mozilla accountable to its principles and mission [13] to being a way to reduce the liability that might be introduced by trusting a given CA [14]. In many ways, the aim of having an objective policy was to provide a transparent insight into how the decisions are made - something notably absent from programs such as Microsoft or Apple. For example, you will not find any public discussion as to why Microsoft continues to add some CAs years ahead of other root programs, even from organizations so rife with operational failures that have disqualified them from recognition by Mozilla, yet took years to add Let's Encrypt, even as they were trusted by other programs and had gone through public review. Mozilla's policy provides that transparency and accountability, by providing a set of principles for which the decisions made can be evaluated against. In theory, by providing this policy and transparency, Mozilla can serve as a model for other root stores and organizations - where, if they share those principles, then the application of the objective policy should lead to the same result, thus leading to a more interoperable web, thus fulfilling some of Mozilla's core principles. In the discussions of CNNIC and TeliaSonera, there was often a rigid application of policy. Unless evidence could be demonstrably provided of not adhering to the stated policies - for example, misissued certificates - the presumption of both innocence and trustworthiness was afforded to these organizations by Mozilla. Factors that were not covered by policy - for example, participation in providing interception capabilities, the distribution of malware, supporting censorship - were discarded from the consideration of whether or not to trust these organizations and include their CAs. During those discussions, and in this, there's a counterargument that highlights these behaviours - or, more commonly, widely reported instances of these behaviours (which lack the benefit of being cryptographically verifiable in the way certificates are) - undermine the trustworthiness of the organization. This argument goes that even of the audit is clean (unqualified, no non-conformities), such an organization could still behave inappropriately towards Mozilla users. Audits can be and are being gamed in such a way as to disguise some known-improper behaviours. CAs themselves can go from trustworthy to untrustworthy overnight, as we saw with StartCom's acquisition by WoSign [15]. The principles involved may be authorizing or engaging in the improper behaviour directly, as we saw with StartCom/WoSign, or may themselves rely on ambiguous wording to provide an escape, should they be caught, as we saw with Symantec.
Public CA:certs with unregistered FQDN mis-issuance
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. Ans: One of our staffs in PKI group was taking samples of the issued certificates from crt.sh database for some reasons and found a mis-issued certificate which has a test (unregistered) FQDN on February 15, 2019 at 1:55 (UTC). He then notified us (Public CA) of the incident. We decide to make an initial investigation and found another mis-issued certificate which also has a test FQDN on February 15, 2019 at 2:30 (UTC). 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. Ans: Timeline (all times are UTC): 15 February 2019 1:55: Find a mis-issued certificate with a FQDN www.raotest.com.tw 15 February 2019 1:59: Revoke the first mis-issued certificate 15 February 2019 2:07: Public CA starts an action plan and initial investigation 15 February 2019 2:17: Further certificate issuing suspended 15 February 2019 2:30: Find another mis-issued certificate with a FQDN publicca.rao.com.tw 15 February 2019 4:10: Initial investigation completed 15 February 2019 4:25: Certificate issuing restarted 15 February 2019 4:40: Hold an investigation meeting 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. Ans: Yes, we had stopped issuing certificates before we investigated and revoked any certificate with an unregistered FQDN. We have asked our CA system vendor to include an automatic FQDN-checking function in the hotfix which will be released not after 30 March 2019 to avoid making the same mistakes. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. Ans: Number of certs: 2 First cert: issued on Nov 12, 2018 at 11:53:02 (UTC) Last cert: issued on Jan 29, 2019 at 06:43:59 (UTC) 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. Ans: https://crt.sh/?id=1153958924 with FQDN www.raotest.com.tw https://crt.sh/?id=940459864 with FQDN publicca.rao.com.tw 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Ans: For the certificate with FQDN www.raotest.com.tw: One of our RAOs intended to take a screenshot of certificate application process for training material in test environment, but she was not aware that she is in the formal environment. After the certificate was issued, the RAO forgot to revoke it. For the certificate with FQDN publicca.rao.com.tw: The same as the former cause, but the mis-issued certificate had been revoked immediately without notifying Public CA. The mistakes have not been detected (even by our internal self-audit) because the amount of mis-issued certificates is minor. The RAO involved in this incident has been verbally warned and needs to undergo a retraining process in accordance with our employment contract. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. Ans: To avoid making the same mistakes, the following steps will newly be introduced: Step 1. Implementation of a two-stage manual verification by different RAOs. Effective 26/02/2019. Step 2. Implementation of an automatic FQDN-checking function prior to issuing certificates. Effective 30/03/2019. Step 3. Implementation of a scheduling program to periodically and automatically check the newly-issued certificates from our repository. Effective 30/05/2019. Sincerely Yours, Li-Chun Chen Chunghwa Telecom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Incident report for DarkMatter CA - change to 128-bit serialNumbers
This incident report relates to the 64-bit serial numbers in all certificates that DarkMatter CAs have issued since their inception. The dialog surrounding CABF Ballot 164 “Certificate Serial Number Entropy” was unknown to DarkMatter until shared with us recently by Ryan Sleevi of Google, and demonstrated to DM that the industry expected at least 64-bits of entropy in resulting serialNumbers despite the actual wording of the BRs Section 7.1. 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. A post by Corey Bonnell to the mozilla.dev.security.policy group on February 23, 2019 at 1:28am UAE time. Corey referenced Section 7.1 of the Baseline Requirements and the specific sentence he believed DM was violating: “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”. Corey also listed 23 certificates (CAs & EE’s) and their serialNumbers as evidence. Corey followed this up 2 days later with a more comprehensive list that included DMs pre-certs and final certs published to various CT Logs. Corey also pointed out a second issue in respect to nameConstrained intermediates issued by Quo Vadis to DM as also a potential violation, but this shall be dealt with in a separate incident report, since DM was not the issuer of these ICAs. Corey’s second post was received on the list at 12:50am UAE time February 25, 2019. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 29-Apr-16: DM having previously engaged with QuoVadis for the establishment of a National PKI utilizing a platform and hardware that would initially be located in QV DCs, held key ceremonies for Private PKIs on EJBCA platform. Platform was configured for random 64-bit serialNumbers which at the time was considered far in excess of the then current BR requirement of 20-bit entropy. 30-Apr-16: QV creates DM intermediates intended for issuance of EV and OV public trust TLS. These intermediates are instantiated in separate partitions to the DM Private Trust PKIs, but issuance from them is still subject to the same platform setting of 64-bit random serialNumbers. 08-Jul-16: CABF Ballot 164 closes and passes. The phrase Corey highlighted above is added in place of the previous 20-bit entropy statement. 28-Mar-17: Transition of DM private PKIs and platform to DM DC’s is complete under supervision of EY as WebTrust Auditors. Public Trust CAs continue to operate out of QV DCs. 08-Jun-17: DM Point In Time Audit is complete. NOTE: DM is now responsible for platform configuration in compliance with BRs. DM considers current serialNumber setting of platform (64-bit SNs) as compliant with BRs Section 7.1 27-Oct-17: DM successfully completes WebTrust Period In Time. 04-Nov-17: QV & DM complete transfer of DM public trust intermediates from QV to DM under EY & KMPG audit observation 18-Dec-17: DM & UAE Roots submitted to Mozilla 02-Oct-18: DM successfully completes 2nd WebTrust Audit 06-Nov-18: DM submits new WebTrust Audits to Mozilla 23-Feb-19: 1:28am: Corey posts to MDSP claiming DM has mis-issuance of certs due to BRs Section 7.1 23-Feb-19: 3:36am: Post is observed by DM, internal investigation requested immediately. 23-Feb-19: 6:14pm: Internal investigation confirms 64-bit setting for all certificates, certlint/cablint/zlint do not complain about certs submitted with this setting. Confirm that settings appear to be compliant with BRs. Further validation sought from platform provider, support ticket opened. 25-Feb-19: 12:50am: Second email from Corey with expanded list of pre-certs and issued certs is posted to MDSP 25-Feb-19: 5:08am: Response posted to Corey on MDSP regarding DM’s investigation and the conclusion that DM is in compliance with BRs Section 7.1. NOTE: over next two days several folks weigh in on the 64-bit entropy vs 64-bit CSPRNG output wording of BRs and what that means. 26-Feb-19: 7:41pm: Wayne Thayer posts to MSDP that 64-bit serialNumber with 63-bit entropy are mis-issued under the BRs. 27-Feb-19:10:55am: DM responds to Wayne reiterating our position of compliance since BRs only say 64-bit output from a CSPRNG and do not say anything about entropy. However, DM commits to make a move to 128-bit serialNumbers from a CSPRNG in next change control to seek to alleviate concerns. More discussion continues on the list. 27-Feb-19: 11:55am: Ryan Sleevi posts historical data/discussions links to MDSP regarding the change resulting from Ballet 164 that
Re: Possible DigiCert in-addr.arpa Mis-issuance
In addition to the GDPR concerns over WHOIS and RDAP data, reliance upon
these data sources has a crucial differentiation from other domain
validation methods.
Specifically, the WHOIS/RDAP data sources are entirely "off-path" with
respect to how a browser will locate and access a given site. To my way of
thinking, this renders these mechanisms functionally inferior to an
"on-path" mechanism, such as reliances upon demonstrated change control
over an authoritative DNS record or even demonstration content change
control over a website.
Since domain validation is, in theory, about validating that the party to
whom a certificate is to be issued has demonstrated control over the
subject of the desired name(s) or the name space of the desired name(s), it
seems clear that "off-path" validation is less valuable as a security
measure.
Although I'm aware that the BRs bless a number of methods, it's also clear
that methods have been excluded by the Mozilla root program before. Is it
time to consider further winnowing down the accepted methods?
On Thu, Feb 28, 2019 at 5:43 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Feb 28, 2019 at 6:21 AM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Thu, 28 Feb 2019 05:52:14 +
> > Jeremy Rowley via dev-security-policy
> > wrote:
> >
> > Hi Jeremy,
> >
> > > 4. The validation agent specified the approval scope as id-addr.arpa
> >
> > I assume this is a typo by you not the agent, for in-addr.arpa ?
> >
> > Meanwhile, and without prejudice to the report itself once made:
> >
> > > 2. The system marked the WHOIS as unavailable for automated parsing
> > > (generally, this happens if we are being throttled or the WHOIS info
> > > is behind a CAPTCHA), which allows a validation agent to manually
> > > upload a WHOIS document
> >
> > This is a potentially large hole in issuance checks based on WHOIS.
> >
> > Operationally the approach taken ("We can't get it to work, press on")
> > makes sense, but if we take a step back there's obvious potential for
> > nasty security surprises like this one.
> >
> > There has to be something we can do here, I will spitball something in
> > a next paragraph just to have something to start with, but to me if it
> > turns out we can't improve on basically "sometimes it doesn't work so
> > we just shrug and move on" we need to start thinking about deprecating
> > this approach altogether. Not just for DigiCert, for everybody.
> >
> > - Spitball: What if the CA/B went to the registries, at least the big
> > ones, and said we need this, strictly for this defined purpose, give
> > us either reliable WHOIS, or RDAP, or direct database access or
> > _something_ we can automate to do these checks ? The nature of CA/B
> > may mean that it's not appropriate to negotiate paying for this
> > (pressuring suppliers to all agree to offer members the same rates is
> > just as much a problem as all agreeing what you'll charge customers)
> > but it should be able to co-ordinate making sure members get access,
> > and that it isn't opened up to dubious data resellers that the
> > registries don't want rifling through their database.
> >
>
> Unfortunately, this is not really viable. The CA/Browser Forum maintains
> relationships with ICANN, as do individual members. While this, on its
> face, seems reasonable, there are practical, business, and legal concerns
> that prevent this from being viable. Further, proposals which would require
> membership in the CA/Browser Forum should, on their face, be rejected - a
> CA should not have to join the Forum in order to be a CA.
>
> I do agree, however, that the use of WHOIS data continues to show
> problematic incidents - whether it's with OCR issues or manual entry - and
> suspect a more meaningful solution is to move away from this model
> entirely. The recently approved methods to the BRs for expressing contact
> information via the DNS directly is one such approach. The GDPR issues
> surrounding WHOIS and RDAP have already led it to be compelling in its own
> right.
>
> Most importantly, you are on the right path of questions, though - which is
> we should examine such incidents systemically and look for improvements,
> and not convince ourselves that the status quo is the best possible
> solution :)
> ___
> 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
I wanted to take a few moments to say that I believe that Ryan Sleevi's extensive write-up is one of the most meticulously supported and researched documents that I've seen discuss this particular aspect of trust delegation decisions as pertains to the various root programs. It is an incredible read that will likely serve as a valuable resource for some time to come. An aspect in which I especially and wholeheartedly agree is the commentary on the special nature of the Mozilla Root CA program and its commitment to transparency of decisions. This is pretty unique among the trust stores and I believe it's an extreme value to the community and would love to see it preserved. Broadly I agree with most of the substance of the positions Ryan Sleevi laid out, but do have some thoughts that diverge in some aspects. Regarding program policy as it now stands, it is not unreasonable to arrive at a position that the root program would be better positioned to supervise and sanction DarkMatter as a member Root CA than as a trusted SubCA. For starters, as a practical matter, membership in the root program does not offer DarkMatter a privilege or capability that they do not already have today. (Save for, presumably, a license fee payable or already paid to QuoVadis/Digicert.) By requiring directly interfacing with Mozilla on any and all disputes or issues, root program membership would mean Mozilla gets to make final decisions such as revocation of trust directly against the CA and can further issue a bulletin putting all other CA program members on note that DarkMatter (if untrusted) is not, under any circumstances, to be issued a SubCA chaining to a trusted root. The obvious recent precedent in that matter is StartCom/StartSSL/WoSign. On the topic of beneficial ownership I am less enthusiastic for several reasons: 1. It should not matter who holds the equity and board level control if the trust is vested in the executive team and the executive team held accountable by the program. At that level, the CA just becomes an investment property of the beneficial owners and the executive and (hopefully) the ownership are aware that their membership in the root CA program is a sensitive and fragile asset subject to easy total loss of value should (increasingly easily detectible) malfeasance occur. I submit that this may be imperfect, but I believe it's far more achievable than meaningful understanding and monitoring of beneficial ownership. 2. Actually getting a full understanding of the down-to-the-person level of the beneficial ownership is complex and in some cases might range from infeasible to impossible. It's possible for even the senior management to have less than full transparency to this. 3. Even if you can achieve a correct and full understanding of beneficial ownership, it is inherently a point-in-time data set. There are ways to transfer off the equity and/or control that may happen in multiple steps or increments so as to avoid triggering change-of-control reporting, etc. There are attorneys and accountants who specialize in this stuff and plenty of legal jurisdictions that actively facilitate. On Thu, Feb 28, 2019 at 7:55 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > (Writing in a personal capacity) > > I want to preemptively apologize for the length of this message. Despite > multiple rounds of editing, there's still much to be said, and I'd prefer > to say it in public, in the spirit of those past discussions, so that they > can be both referred to and (hopefully) critiqued. > > These discussions are no easy matter, as shown from the past conversations > regarding both TeliaSonera [1] and CNNIC [2][3][4][5]. There have been > related discussions [6][7], some of which even discuss the UAE [8]. If you > go through and read those messages, you will find many similar messages, > and from many similar organizations, as this thread has provoked. > > In looking at these older discussions, as well as this thread, common > themes begin to emerge. These themes highlight fundamental questions about > what the goals of Mozilla are, and how best to achieve those goals. My hope > is to explore some of these questions, and their implications, so that we > can ensure we're not overlooking any consequences that may result from > particular decisions. Whatever the decision is made - to trust or distrust > - we should at least make sure we're going in eyes wide open as to what may > happen. > > 1) Objectivity vs Subjectivity > > Wayne's initial message calls it out rather explicitly, but you can see it > similarly in positions from past Mozilla representatives - from Gerv > Markham, Sid Stamm, Jonathan Nightingale - and current, such as Kathleen > Wilson. The "it" I'm referring to is the tension between Mozilla's Root > Program, which provides a number of ideally objective criteria for CAs to > meet for inclusion, and the policy itself providing significant leeway
Re: Possible DigiCert in-addr.arpa Mis-issuance
On Wednesday, February 27, 2019 at 8:54:35 AM UTC-6, Jakob Bohm wrote: > One hypothetical use would be to secure BGP traffic, as certificates > with IpAddress SANs are less commonly supported. The networking / interconnection world has already worked out the trust hierarchy for the RPKI scheme. As there are a number of global RIRs who are the authoritative source of ASN and IP space information, they've elected to themselves be the Root CAs involved. Its an interesting infrastructure. You can learn more about it here: https://www.arin.net/resources/rpki/index.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 答复: Certificate Problem Report (9WG: CFCA certificate with invalid domain)
Hi Jonathan, When something like this occurs the Mozilla community asks for an incident report explaining how the incident occurred, what was done to remediate it, and what procedures and technical controls have been put in place to prevent a future recurrence of the problem. You can see documentation about that here: https://wiki.mozilla.org/CA/Responding_To_An_Incident I am very interested in knowing how your registration authority infrastructure allowed an invalid (and unaudited) SAN to be issued. (Note that I am not a Mozilla representative, merely a member of the community who has seen many incident reports) -Paul On March 1, 2019 at 11:57:05 AM, 孙圣男 via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: Dear Mozilla： This problem had been confirmed. We contacted the customer and confirmed this certificate haven't been deployed to production system, no damage is caused. This certificate had been revoked in March 1, 2019. We had fixed this bug in February 27 update. Best wishes! Jonathan Sun Certificate Product Manager International Coperation Group Tel: +86 010 80864127 -邮件原件- 发件人: Buschart, Rufus 发送时间: 2019年2月28日 19:00 收件人: r...@cfca.com.cn 主题: Certificate Problem Report (9WG: CFCA certificate with invalid domain) Dear PKI team at CFCA! There is a misissued certificate https://crt.sh/?id=1231965201=cablint,x509lint,zlin from your CA which is not revoked yet. I think you should have a look. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > -Ursprüngliche Nachricht- > Von: dev-security-policy > Im Auftrag von > michel.lebihan2000--- via dev-security-policy > Gesendet: Mittwoch, 27. Februar 2019 08:54 > An: mozilla-dev-security-pol...@lists.mozilla.org > Betreff: CFCA certificate with invalid domain > > 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. > ___ > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
