Re: GRCA Incident: BR Compliance and Document Signing Certificates

2019-03-25 Thread Matthew Hardeman via dev-security-policy
On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While it may be true that the certificates in question do not contain > SANs, unfortunately, the certificates may still be trusted for SSL since > they do not have EKUs. > > For an

Re: DarkMatter Concerns

2019-03-22 Thread Matthew Hardeman via dev-security-policy
I'm not sure on the weighting of the two sides that you point out, but I do broadly agree that it is about striking some balance between those two ends. That said, if all outcomes are equally bad, I think I favor the bad outcome that doesn't open the door to accusations of a discriminatory

Re: GRCA Incident: BR Compliance and Document Signing Certificates

2019-03-16 Thread Matthew Hardeman via dev-security-policy
While sending a message that non-compliance could result in policy change is generally a bad idea, I did notice something about the profile of the non-compliant certificate which gave me pause: None of the example certificates which were provided include a SAN extension at all. Today, no valid

Re: GRCA Incident: BR Compliance and Document Signing Certificates

2019-03-16 Thread Matthew Hardeman via dev-security-policy
I think answers to the following questions might be helpful: 1. What software / types of software are being utilized which would give compatibility issues? What is the validation logic of those applications / systems? 2. If these certificates don't have a purpose known to or respected by the

Re: Open Source CA Software

2019-03-15 Thread Matthew Hardeman via dev-security-policy
I think open source is great, but it's not a panacea. While there are many CAs and several root programs, this community is a relatively small one in the grand scheme. Prior events suggest that there are not enough people with the necessary skill overlap to parse both the rules and the code to

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

2019-03-12 Thread Matthew Hardeman via dev-security-policy
Overall I think it's a neat scheme. It does impose some trade-offs beyond the mechanism that I proposed: 1. It leaves the implementing CA with no space within the serial number field to include a CA significant sequence number, timestamp, or other value. That may not be a bad thing, but it's

Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

2019-03-11 Thread Matthew Hardeman via dev-security-policy
On Mon, Mar 11, 2019 at 12:18 PM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I really like reading this discussion about 64 vs. 63 bits and how to read > the BRGs as it shows a lot of passion by all of us in the PKI community. > Never the less, in

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-08 Thread Matthew Hardeman via dev-security-policy
On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote: > I consider that only a single CA has represented any ambiguity as being > their explanation as to why the non-compliance existed, and even then, > clarifications to resolve that ambiguity already existed, had they simply > been sought. >

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-08 Thread Matthew Hardeman via dev-security-policy
On Fri, Mar 8, 2019 at 8:52 PM Ryan Sleevi wrote: I appreciate the attention to detail, but I find it difficult to feel that > it is a good faith effort that is designed to produce results consistent > with the goals that many of this community have and share, and thus don't > think it would be

Re: A modest proposal for a better BR 7.1

2019-03-08 Thread Matthew Hardeman via dev-security-policy
On Fri, Mar 8, 2019 at 8:57 PM Peter Gutmann wrote: > Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > >shall be 0x75 > > Not 0x71? > :-) In truth, I think any particular chosen single value for the first byte which h

A modest proposal for a better BR 7.1

2019-03-08 Thread Matthew Hardeman via dev-security-policy
I know this isn't the place to bring a BR ballot, but I'm not presently a participant there. I present alternative language along with notes and rationale which, I put forth, would have resulted in a far better outcome for the ecosystem than the issues which have arisen from the present BR 7.1

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-08 Thread Matthew Hardeman via dev-security-policy
On Friday, March 8, 2019 at 6:05:05 PM UTC-6, Ryan Sleevi wrote: > You're absolutely correct that two certificates, placed next to eachother, > could appear sequential. Someone might then make a claim that the CA has > violated the requirements. The CA can then respond by discussing how they >

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-08 Thread Matthew Hardeman via dev-security-policy
On Fri, Mar 8, 2019 at 3:10 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Having sequential serial numbers is not problematic. Having *predictable* > serial numbers is problematic. My problem with this is that, if we parse the english language

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 9:28 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is > defined in the BRs. > Yes. There are various levels of qualification and quality for algorithms

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > But BRs are not to be interpreted, just to be applied to the letter, > whether it makes sense or not. When it no longer makes sense, the wording > can be improved for the future. >

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Past analysis and discussion have shown the interpretation is hardly > specific to a single CA. It was a problem quite literally publicly > discussed during the drafting and

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 8:20 PM Peter Gutmann wrote: > I swear I didn't plan that in advance :-). I believe you. When the comedy is this good, it's because it wrote itself. :-) ___ dev-security-policy mailing list

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 8:14 PM Peter Gutmann wrote: > > As I said above, you can get arbitrarily silly with this. I'm sure if we > looked at other CA's code at the insane level of nitpickyness that > DarkMatter's use of EJBCA has been examined, we'd find reasons why their > implementations are

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

2019-03-07 Thread Matthew Hardeman via dev-security-policy
Practical question: How does the update to CABLint/Zlint work? If a CA is choosing to issue certs with serial numbers with exactly 64 bits of entropy, approximately 50% of the time there will be a certificate with an 8 byte encoding of the serial number, as the high-order bit of the first byte

Re: EJBCA defaulting to 63 bit serial numbers

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 7:47 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 0. Given that the value of 64 bits was pulled out of thin air (or possibly >less well-lit regions), does it really matter whether it's 63 bits, 64 >bits, 65 3/8th bits,

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 5:35 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > In the face of exterior political force, the people of the UAE couldn't get > *globally trusted* certificates full-stop. Off the top of my head, all of > the widely-adopted web

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Whilst those are all good points, I don't see how any of them require the > CA > to control an unconstrained intermediate CA certificate (or a root > certificate). All of those

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 11:55 AM Wayne Thayer wrote: This line of thinking seems to conflate a few different issues. > That is true. I apologize for that, but also feel that some of these different issues and how they'd play out in relation with this current matter and ultimately with the

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 11:33 AM Wayne Thayer wrote: > Nadim and Matthew, > > Can you explain and provide examples for how this "set of empirical > requirements" differs from the objective requirements that currently exist? > Hi, Wayne, I think the matter of whether or not I could or should

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 11:29 AM James Burton wrote: > I'm talking about someone from a restricted country using a undocumented > domain name to obtain a Let's Encrypt certificate and there is nothing that > can be done about it. We can't predict the future. > So your assertion, then, is that

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 11:11 AM James Burton wrote: > Let's be realistic, anyone can obtain a domain validated certificate from > Let's Encrypt and there is nothing really we can do to prevent this from > happening. Methods exist. > I am continuing to engage in this tangent only in as far as it

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 10:54 AM James Burton wrote: > Let's Encrypt issues domain validation certificates and anyone with a > suitable domain name (e.g. .com, .net, .org ) can get one of these > certificates just by proving control over the domain by using the DNS or " >

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 10:20 AM Matthew Hardeman wrote: > > Let's Encrypt does not quite provide certificates to everyone around the > world. They do prevent issuance to and revoke prior certificates for those > on the United States various SDN (specially designated nationals) lists. > For

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There isn't any monopoly that prevents citizens and organizations in the > United Arab Emirates to get certificates from CAs and they are not > expensive. Let's Encrypt provides

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 10:10 AM Ken Myers (personal capacity) via dev-security-policy wrote: > Is the issue that a Dark Matter business unit may influence the Dark > Matter Trust Services (a separate unit, but part of the same company) to > issue certificates for malicious purposes? > > or is it

Re: DarkMatter Concerns

2019-03-07 Thread Matthew Hardeman via dev-security-policy
On Thu, Mar 7, 2019 at 9:18 AM nadim--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I would like to repeat my call for establishing a set of empirical > requirements that take into account the context of DarkMatter's current > position in the industry as well as

Re: DarkMatter Concerns

2019-03-05 Thread Matthew Hardeman via dev-security-policy
On Tue, Mar 5, 2019 at 12:18 PM Ryan Sleevi wrote: > > I believe you may have misunderstood the details of these incidents and > their relationship to what's currently under discussion. > > In the Sectigo + NSO Group, these were entities that shared common > investment ownership, but otherwise

Re: DarkMatter Concerns

2019-03-05 Thread Matthew Hardeman via dev-security-policy
On Tue, Mar 5, 2019 at 11:10 AM Matthew Hardeman wrote: > > This means there are two recent precedents for which this category of > issues has not resulted in delegation of trust and one proposal that the > same category of behaviors should. I am not suggesting that a position > against

Re: DarkMatter Concerns

2019-03-05 Thread Matthew Hardeman via dev-security-policy
On Tue, Mar 5, 2019 at 8:16 AM Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > You're right, there is no test. That's why some of us believe we should > look at proxies: such as honesty, considering root membership is ultimately > about trust. DM has made

Re: DarkMatter Concerns

2019-03-04 Thread Matthew Hardeman via dev-security-policy
My perspective is that of an end user and also that of a software developer involved in a non-web-browser space in which various devices and manufacturers generally defer to the Mozilla root program's trust store. As such, I'm quite certain that my opinions don't -- and should not -- have the

Re: DarkMatter Concerns

2019-03-04 Thread Matthew Hardeman via dev-security-policy
On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote: > > It is not clear how this follows. As my previous messages tried to > capture, the program is, and has always been, inherently subjective and > precisely designed to support discretionary decisions. These do not seem to > inherently conflict

Re: DarkMatter Concerns

2019-03-03 Thread Matthew Hardeman via dev-security-policy
On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Insane that this is even being debated. If the floodgates are opened here > you will NOT be able to get things back under control. > While I can appreciate the passion of

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

2019-02-28 Thread Matthew Hardeman via dev-security-policy
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.

Re: DarkMatter Concerns

2019-02-28 Thread Matthew Hardeman via dev-security-policy
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

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

2019-02-28 Thread Matthew Hardeman via dev-security-policy
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

Re: DarkMatter Concerns

2019-02-27 Thread Matthew Hardeman via dev-security-policy
While I was going to respond to the below, Nick Lamb has beaten me to it. I concur in full with the remarks in that reply. We should not be picking national favorites as a root program. There's a whole world out there which must be supported. What we should be doing is ensuring that we know the

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

2019-02-27 Thread Matthew Hardeman via dev-security-policy
On Wed, Feb 27, 2019 at 9:04 AM Nick Lamb wrote: > > It does feel as though ARPA should consider adding a CAA record to > in-addr.arpa and similar hierarchies that don't want certificates, > denying all CAs, as a defence in depth measure. > Unless I significantly misunderstand CAA, this

Re: DarkMatter Concerns

2019-02-26 Thread Matthew Hardeman via dev-security-policy
The issue I see with that interpretation is that the very same matter has previously been discussed on this list and resolved quite vocally in the favor of the other position: that making careful choices about the CSPRNG output to conform it to mask out the high order bit makes the output of at

Re: DarkMatter Concerns

2019-02-26 Thread Matthew Hardeman via dev-security-policy
I'd like to take a moment to point out that determination of the beneficial ownership of business of various sorts (including CAs) can, in quite a number of jurisdictions, be difficult to impossible (short of initiating adverse legal proceedings) to determine. What does this mean for Mozilla's

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

2019-02-26 Thread Matthew Hardeman via dev-security-policy
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

Re: DarkMatter Concerns

2019-02-25 Thread Matthew Hardeman via dev-security-policy
On Mon, Feb 25, 2019 at 12:15 PM Richard Salz wrote: > You miss the point of my question. > > What types of certs would they issue that would NOT expect to be trusted > by the public? > >> >>> I get the question in principle. If it is a certificate not intended for public trust, I suppose I

Re: DarkMatter Concerns

2019-02-25 Thread Matthew Hardeman via dev-security-policy
The answer to the question of what certificates they intend to CT log or not may be interesting as a point of curiosity, but the in-product CT logging requirements of certain internet browsers (Chrome, Safari) would seem to ultimately force them to CT log the certificates that are intended to be

Re: usareally.com and OFAC lists

2019-01-15 Thread Matthew Hardeman via dev-security-policy
On Mon, Jan 14, 2019 at 5:45 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Am I wrong to expect US CAs to be monitoring OFAC sanctions lists? > Otherwise they would risk violating the typical "comply with applicable > law" stipulation in section 9 of

Re: Concerns with Dun & Bradstreet as a QIIS

2018-09-27 Thread Matthew Hardeman via dev-security-policy
A whitelist of QGIS sounds fairly difficult. And how long would it take to adopt a new one? In some states you're going to have an authority per county. It'd be a big list. On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Re: Google Trust Services Root Inclusion Request

2018-09-18 Thread Matthew Hardeman via dev-security-policy
A few thoughts, inlined below... On Monday, September 17, 2018 at 6:42:29 PM UTC-5, Jake Weisz wrote: > I guess under this logic, I withdraw my protest. As you say, Google > could simply start using these certificates, and Mozilla executives > would force you to accept them regardless of any

Re: A vision of an entirely different WebPKI of the future...

2018-08-17 Thread Matthew Hardeman via dev-security-policy
On Friday, August 17, 2018 at 2:01:55 AM UTC-5, Peter Gutmann wrote: > That was actually debated by one country, that whenever anyone bought a domain > they'd automatically get a certificate for it included. Makes perfect sense, > owning the domain is a pretty good proof of ownership of the

Re: A vision of an entirely different WebPKI of the future...

2018-08-17 Thread Matthew Hardeman via dev-security-policy
On Thursday, August 16, 2018 at 6:18:47 PM UTC-5, Jakob Bohm wrote: > The main cause of this seems to be that CT has allowed much more > vigorous prosecution of even the smallest mistake. Your argument > is a sensationalist attack on an thoroughly honest industry. I certainly didn't mean it as

Re: A vision of an entirely different WebPKI of the future...

2018-08-16 Thread Matthew Hardeman via dev-security-policy
On Thursday, August 16, 2018 at 3:34:01 PM UTC-5, Paul Wouters wrote: > Why would people not in the business of being a CA do a better job than > those currently in the CA business? I certainly do not assert that there would be no learning curve. However, these same registries for the generic

Re: A vision of an entirely different WebPKI of the future...

2018-08-16 Thread Matthew Hardeman via dev-security-policy
On Thursday, August 16, 2018 at 3:18:38 PM UTC-5, Wayne Thayer wrote: > What problem(s) are you trying to solve with this concept? If it's > misissuance as broadly defined, then I'm highly skeptical that Registry > Operators - the number of which is on the same order of magnitude as CAs > [1] -

A vision of an entirely different WebPKI of the future...

2018-08-16 Thread Matthew Hardeman via dev-security-policy
Of late, there seems to be an ever increasing number of misissuances of various forms arising. Despite certificate transparency, increased use of linters, etc, it's virtually impossible to find any CA issuing in volume that hasn't committed some issuance sin. Simultaneously, there seems to be

Further BGP hijacks of high value authoritative DNS servers' IP space.

2018-08-03 Thread Matthew Hardeman via dev-security-policy
Noted by the Oracle/Dyn team at: https://blogs.oracle.com/internetintelligence/bgp-dns-hijacks-target-payment-systems July 2018 saw multiple attacks on authoritative DNS infrastructure of both dedicated DNS service providers and of certain high value internally administered DNS services which

Re: Possible violation of CAA by nazwa.pl

2018-07-26 Thread Matthew Hardeman via dev-security-policy
On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > The party actually running the authoritative DNS servers is in control > of the domain. > > I'm not sure I agree. They can control the domain, but they are supposed > to be

Re: Possible violation of CAA by nazwa.pl

2018-07-26 Thread Matthew Hardeman via dev-security-policy
I think the whole point of domain validation certificates is taking the human part out of it and verifying technical control of the domain as the standard upon which to base issuance. Since the CA is also the DNS server, it's more or less a given that they certainly can or would successfully

Re: Possible violation of CAA by nazwa.pl

2018-07-25 Thread Matthew Hardeman via dev-security-policy
Yes, I thought there was an exemption for that also. The A-DNS operator could always just momentarily change the records to authorize anyway, so why bother with the check? On Wed, Jul 25, 2018 at 4:21 PM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Re: Namecheap refused to revoke certificate despite domain owner changed

2018-06-01 Thread Matthew Hardeman via dev-security-policy
On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This is one of the reasons I think we should require an OID specifying the > validation method be included in the cert. Then you can require the CA > support revocation using

Re: Disallowed company name

2018-06-01 Thread Matthew Hardeman via dev-security-policy
On Thu, May 31, 2018 at 8:38 PM, Peter Gutmann wrote: > > >Banks, trade vendors, etc, tend to reject accounts with names like this. > > Do they? > > https://www.flickr.com/photos/nzphoto/6038112443/ I would hope that we could agree that there is generally a different risk management burden in

Re: Disallowed company name

2018-06-01 Thread Matthew Hardeman via dev-security-policy
On Fri, Jun 1, 2018 at 10:28 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > re: Most of the government offices responsible for approving entity > creation are concerned first and foremost with ensuring that a unique name > within their jurisdiction is

Re: Disallowed company name

2018-05-31 Thread Matthew Hardeman via dev-security-policy
On Thu, May 31, 2018 at 5:03 PM, Kristian Fiskerstrand wrote: > > New business enterprise name: ';UPDATE TAXRATE SET RATE = 0 WHERE NAME = > 'EDVIN SYSE' > > they have a write-up on it on > https://blogg.syse.no/syse-data-og-bronnoysundregistrene/ in Norwegian, > although you'll find

Re: Disallowed company name

2018-05-31 Thread Matthew Hardeman via dev-security-policy
On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > We can also think of many business types (e.g., scammers) that would > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to issue > certificates with such

Re: Disallowed company name

2018-05-31 Thread Matthew Hardeman via dev-security-policy
On Thu, May 31, 2018 at 3:38 PM, James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I recently incorporated the company named ";", see: > https://beta.companieshouse.gov.uk/company/11363219. This company > compiles with > the both the "Companies Act 2006" and

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

2018-05-23 Thread Matthew Hardeman via dev-security-policy
I believe that Paul Wouters has made a compelling case regarding the current state of keying practices in DNSSEC deployment today. There is sufficient cryptographic rigor to merit logging this data for review of correct assessment as of the point in time at which certificate issuance decisioning

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

2018-05-22 Thread Matthew Hardeman via dev-security-policy
Copying message accidentally sent directly to a list participant. -- Forwarded message -- From: Matthew Hardeman Date: Tue, May 22, 2018 at 3:47 PM Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident To: Ryan Sleevi

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

2018-05-21 Thread Matthew Hardeman via dev-security-policy
I concur with Mr. Lamb's position. I agree not only with respect to DNSSEC signatures but to the entire query and RR set upon which the CAs decisions relied. I do acknowledge the challenge that Mr. Hoffman-Andrews surfaced: that it may involve significant effort to correlate the various queries

Re: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Matthew Hardeman via dev-security-policy
I concur with Wayne's position that the discussion up to this point isn't leading to a solution. I represent nothing further than that I'm a systems and DNS administrator and domain holder (and thus, I submit, an interested and not entirely uninformed ecosystem participant) who has had an

Re: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Matthew Hardeman via dev-security-policy
table definition that we > all know and love. You can't just pretend that's not part of the scoping or > authority here. > > > On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> It is di

Re: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Matthew Hardeman via dev-security-policy
...@mydomain.com while allowing the following CAs to issue for any email address over the same domain. On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi <r...@sleevi.com> wrote: > Both types share a common namespace. The domain name space. > > On Tue, May 15, 2018 at 12:10 PM, Matthew H

Re: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Matthew Hardeman via dev-security-policy
Agreed. My point was to query the position of the administration of a large generic email service as to their understanding of the implications of CAA on their domains. Certificates have different types of SANs for good cause: the nuances of the name space differ. For example, SAN rfc822Names

Re: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Matthew Hardeman via dev-security-policy
It is disingenuous to apply CAA to S/MIME and other certificate purposes after the fact. As a domain holder myself, having implemented CAA in certain domains, I did intent to restrict issuance of server certificates. I have never intended this to be a restriction of S/MIME certificate issuance.

Re: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Matthew Hardeman via dev-security-policy
For that matter, can whoever is in charge of gmail.com speak to their intent as to CAA for S/MIME? I've certainly held certificates which include my personal gmail address before. At no point did I need or seek Google's blessing to do so. I can not imagine that was an uncommon case. (At least,

Re: Regional BGP hijack of Amazon DNS infrastructure

2018-04-25 Thread Matthew Hardeman via dev-security-policy
On Wed, Apr 25, 2018 at 1:44 PM, Santhan Raj via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I did see the (ridiculously silly) self-signed certificate that was used, > but the skeptic in me keeps questioning the timeline of this attack and > recent multiple cert

Re: Regional BGP hijack of Amazon DNS infrastructure

2018-04-25 Thread Matthew Hardeman via dev-security-policy
Also, during the period of the attack, they were using a self-signed certificate. As yet there's no public evidence that they achieved issuance of any certificate. There is some question as to whether they could have. On Wed, Apr 25, 2018 at 12:32 PM, Matthew Hardeman

Re: Regional BGP hijack of Amazon DNS infrastructure

2018-04-25 Thread Matthew Hardeman via dev-security-policy
I seriously doubt that. MyEtherWallet.com is/was hosted on Amazon CloudFront, and I believe the private keys for those certs stay locked at Amazon. That was likely the starter cert that MyEtherWallet.com first went with before securing an EV cert. On Wed, Apr 25, 2018 at 11:42 AM, Santhan Raj

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

2018-04-25 Thread Matthew Hardeman via dev-security-policy
On Wed, Apr 25, 2018 at 11:01 AM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > This is not about whether or not domains should deploy DNSSEC. > Domains are are their own right to decide whether or not they see DNSSEC > fit for their environment. >

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

2018-04-25 Thread Matthew Hardeman via dev-security-policy
> > Multiple perspectives is useful when relying on any insecure third-party > resource; for example DNS or Whois. > > This is different than requiring multiple validations of different types; > an attacker that is able to manipulate the DNS validation at the IP layer > is also likely going to be

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

2018-04-25 Thread Matthew Hardeman via dev-security-policy
On Wed, Apr 25, 2018 at 8:47 AM, Paul Wouters via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > BGP hijack at once. In the end, that's a numbers game with a bunch of > race conditions. But hey, it might lead to actual BGP security getting > deployed :) > I'm an

Re: Regional BGP hijack of Amazon DNS infrastructure

2018-04-24 Thread Matthew Hardeman via dev-security-policy
On Tue, Apr 24, 2018 at 7:11 PM, Wayne Thayer wrote: > Thanks Matthew, I appreciate you bringing this to everyone's attention. > > Unless I'm misunderstanding the scope of the attack, it would have been > trivial for them to get a trusted cert from most any CA. However,

Regional BGP hijack of Amazon DNS infrastructure

2018-04-24 Thread Matthew Hardeman via dev-security-policy
This story is still breaking, but early indications are that: 1. An attacker at AS10297 (or a customer thereof) announced several more specific subsets of some Amazon DNS infrastructure prefixes: 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24 2. It appears that AS10297 via peering

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

2018-04-13 Thread Matthew Hardeman via dev-security-policy
My purpose in bringing up the High Risk Certificate Request and the BR that requires that a CA maintain a list of matching criteria to scrub certificate requests with was merely to illustrate yet another criteria upon which GoDaddy and other CAs may legitimately decline to issue a certificate such

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

2018-04-13 Thread Matthew Hardeman via dev-security-policy
Reposting as I accidentally sent to Mr. Mill only. On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill wrote: > > > But he did not deceive users. Demonstrating that this is possible is not > itself an act of deception. > > Except that if he can't maintain a working EV certificate in a

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
Wow. I’m impressed. Let’s Encrypt by their own declaration and by observed interactions in their community help forums maintains a high value blacklist of domains. It’s difficult to imagine how that list doesn’t include PayPal but did include mail.ru. Can you repeat that test with, say,

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
Independent of EV, the BRs require that a CA maintain a High Risk Certificate Request policy such that certificate requests are scrubbed against an internal database or other resources of the CAs discretion. The examples particularly call out names that may be more likely to be used in phishing,

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
Perhaps it should be the broader question of both issuance policy and revocation? For example, guidelines denote what issuance is permissible but nowhere in the BR policies (or in any of the root programs as far as I'm aware) is an affirmative obligation to issue to those meeting the

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 2:28 PM, Alex Gaynor wrote: > All that proves is the entire EV model cannot possibly accomplish what CAs > claims (with respect to phishing and other similar concerns). To whit: > > - Two companies can validly possess trademarks for the same name in

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 2:20 PM, James Burton wrote: > Both mine and Ian's demonstrations never harmed or deceived anyone as > they were proof of concept. The EV certs were properly validated to the > EV guidelines. Both companies are legitimate. So what's the issue? None. > > >

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill wrote: > Ian's intent may have been to demonstrate EV's weaknesses, but that > doesn't mean Ian was intending to deceive users. If Ian had used this to > try to get people to enter their Stripe credentials or something, then > that'd

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 12:52 PM, Ryan Sleevi wrote: > > > For that matter, why isn't "O=Stripe, Inc., ST=California, > jurisdictionStateOrProvinceName=Delaware" confusing - does the "average > Internet user" understand the distinction between those two states being > presented?

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 12:27 PM, Ryan Sleevi wrote: This is a patently distateful argument based on broad generalizations that > do not hold any merit. I realize you've acknowledged your argument is > fundamentally a popularity contest, but it seems to really base its core on >

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi wrote: > > So Apple Computer is misleading to customers of Apple Records, and Apple > Records is misleading to customers of Apple Computer, is that the argument? > In which case, no one named "Apple" should a certificate, right? > >

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 12:03 PM, Wayne Thayer wrote: > > > I agree with this, but the current approach taken by CAs is defined in the > BRs, so pointing fingers at individual CAs is not the solution. Based on > this argument, the requirement to revoke when a certificate

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 11:45 AM, Ryan Sleevi wrote: > > In what way is it misleading though? It fully identified the organization > that exists, which is a legitimate organization. Thus, the information that > appears within the certificate itself is not misleading - and I

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
On Thu, Apr 12, 2018 at 11:40 AM, Eric Mill wrote: > > That's not accurate -- the EV information presented to users was not > misleading. It correctly described Ian's registered company. The > certificate was incorrectly revoked. We should probably be discussing > whether

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
makes the payment processing company somehow more deserving of one than >>>> Ian's company? Why was GoDaddy allowed to effectively take Ian's site >>>> down >>>> without his consent? >>>> >>>> If this is how EV is goi

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
splay of EV information from Mozilla products. >> >> -- Eric >> >> On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via >> dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> > On Wed, Apr 11, 2018, at 15:27, Matthew Hardem

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

2018-04-12 Thread Matthew Hardeman via dev-security-policy
> > On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > >> On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy >> wrote: >> > It was injudicious of a CA to issue anot

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

2018-04-11 Thread Matthew Hardeman via dev-security-policy
Isn't that question a little disingenuous? There was massive controversy in the mainstream tech press and throughout the InfoSec press and elsewhere when a certificate with this EV indication for this entity name for this website and purpose previously issued. It invites trouble in the sense

  1   2   3   >