Apple OCSP Responder Issues Yesterday (2020-11-12)

2020-11-13 Thread Matthew Hardeman via dev-security-policy
In as far as that part of Apple's CA hierarchy is publicly trusted and participates in the Mozilla Root CA program and that there were apparent performance issues with ocsp.apple.com yesterday, I'm writing to suggest that I believe there may be cause to expect some transparency regarding recent

Re: TLS certificates for ECIES keys

2020-10-30 Thread Matthew Hardeman via dev-security-policy
On Fri, Oct 30, 2020 at 10:49 AM Bailey Basile via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > We specifically chose not to issue Apple certificates for these keys > because we did not want users to have to trust only Apple's assertion that > this key is for a third

Re: TLS certificates for ECIES keys

2020-10-29 Thread Matthew Hardeman via dev-security-policy
On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The way I read Jacob's description of the process, the subscriber is > "misusing" the certificate because they're not going to present it to TLS > clients to validate the identity

Re: TLS certificates for ECIES keys

2020-10-29 Thread Matthew Hardeman via dev-security-policy
IFF the publicly trusted certificate for the special domain name is acquired in the normal fashion and is issued from the normal leaf certificate profile at LE, I don't see how the certificate could be claimed to be "misused" _by the subscriber_. To the extent that there is misuse in the

Re: PEM of root certs in Mozilla's root store

2020-10-07 Thread Matthew Hardeman via dev-security-policy
Would it be unreasonable to also consider publishing, as an "easy to use" list, that set of only those anchors which are currently trusted in the program and for which no exceptional in-product policy enforcement is imposed? (TLD constraints, provisional distrusts, etc.) The lazier implementers

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

2020-08-13 Thread Matthew Hardeman via dev-security-policy
It’s actually really simple. You end up in a position of editorializing. If you will not provide service for abuse, everyone with a gripe constantly tries to redefine abuse. Additionally, this is why positive security indicators are clearly on the way out. In the not too distant future all

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-04 Thread Matthew Hardeman via dev-security-policy
Just chiming in as another subscriber and relying party, with a view to speaking to the other subscribers on this topic. To the extent that your use case is not specifically the WebPKI as pertains to modern browsers, it was clear to me quite several years ago and gets clearer every day: the

Re: Digicert issued certificate with let's encrypts public key

2020-05-19 Thread Matthew Hardeman via dev-security-policy
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > So, I request and encourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > I don't mean to beat a dead horse, and without addressing the merits of trying to

Re: Digicert issued certificate with let's encrypts public key

2020-05-19 Thread Matthew Hardeman via dev-security-policy
th. > > So, I request and encourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > > -Kyle H > > On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.m

Re: Digicert issued certificate with let's encrypts public key

2020-05-19 Thread Matthew Hardeman via dev-security-policy
ourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > > -Kyle H > > On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >

Re: Digicert issued certificate with let's encrypts public key

2020-05-18 Thread Matthew Hardeman via dev-security-policy
On Mon, May 18, 2020 at 12:44 PM Ryan Sleevi wrote: > The scenario you ascribe to > StartCom is exactly what is recommended, of CAs, in numerous CA > incident bugs where the failure to apply that restrictive model has > lead to misissuance. > Separate to the matter in discussion in this thread,

Re: Digicert issued certificate with let's encrypts public key

2020-05-18 Thread Matthew Hardeman via dev-security-policy
een proven. On Mon, May 18, 2020 at 12:44 PM Ryan Sleevi wrote: > On Mon, May 18, 2020 at 11:40 AM Matthew Hardeman via > dev-security-policy wrote: > > A scary example, I know, but StartCom's original system was once > described > > as taking the public key data (and they e

Re: Digicert issued certificate with let's encrypts public key

2020-05-18 Thread Matthew Hardeman via dev-security-policy
I certainly recall descriptions of other issuing systems in history in which it was (at least based on the description) possible to get a certificate issued without proof of control of the private key. A scary example, I know, but StartCom's original system was once described as taking the public

Re: Digicert issued certificate with let's encrypts public key

2020-05-17 Thread Matthew Hardeman via dev-security-policy
> In particular, there must have been some authorisation carried out at some > point, or perhaps that wasn't carried out, that indicates who requested the > cert. What I'm trying to discover is where the gap was, and what's > required > to fix it in the future. > What gap, exactly? There’s not

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

2020-03-10 Thread Matthew Hardeman via dev-security-policy
Isn't the evident answer, if reasonable compromise is not forthcoming, just to publish the compromised private key. There's no proof of a compromised private key quite as good as providing a copy of it. I understand the downsides, but I think that capricious burdens encourage stripping the issue

Re: How Certificates are Verified by Firefox

2019-12-04 Thread Matthew Hardeman via dev-security-policy
use OCSP? > > On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Not that anyone is presently doing or would do such a thing, but... >> >> Imagine a CA that wanted to o

Re: [FORGED] Re: How Certificates are Verified by Firefox

2019-12-04 Thread Matthew Hardeman via dev-security-policy
Not that anyone is presently doing or would do such a thing, but... Imagine a CA that wanted to offer up a user/browser tracking service to their subscriber customer. Is there any rule that prevents an issuing CA from having a "custom" (hiding an identifier for the end-entity certificate) AIA

Re: Mozilla Policy Requirements CA Incidents

2019-10-08 Thread Matthew Hardeman via dev-security-policy
My apologies. I messed up when trimming that down. I was quoting Ryan Sleevi there. On Tue, Oct 8, 2019 at 2:55 PM Paul Walsh wrote: > > On Oct 8, 2019, at 12:51 PM, Matthew Hardeman wrote: > > > On Tue, Oct 8, 2019 at 2:10 PM Ryan Sleevi via dev-security-policy < >

Re: Mozilla Policy Requirements CA Incidents

2019-10-08 Thread Matthew Hardeman via dev-security-policy
On Tue, Oct 8, 2019 at 2:10 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Oct 8, 2019 at 2:44 PM Paul Walsh wrote: > > so we need better solutions. It's also being willing to acknowledge that if > we can't find systemic fixes, it may be that we

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

2019-08-30 Thread Matthew Hardeman via dev-security-policy
On Fri, Aug 30, 2019 at 11:56 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > For readers unfamiliar, let me briefly explain what Safe Browsing gives > browsers: > > For every URL you're considering displaying you calculate a whole bunch > of cryptographic

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

2019-08-30 Thread Matthew Hardeman via dev-security-policy
> > I’m not saying that this is the case, but merely to say that the > Yes/No/IDK does not represent the full set of feasible responses. > So let's add "I decline to make inquiries, official or otherwise" and "Policy prevents me from discussing that" to the list. It would be interesting to get

Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

2019-08-28 Thread Matthew Hardeman via dev-security-policy
I'd particularly like to see the memes directly within the certificate, maybe an extension to RFC 6170. On Wed, Aug 28, 2019 at 6:13 AM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, August 22, 2019 at 11:08:03 PM UTC-4, Jeremy Rowley wrote:

Re: CA handling of contact information when reporting problems

2019-08-22 Thread Matthew Hardeman via dev-security-policy
I'm merely a relying party and subscriber, but it seems quite unreasonable to believe that there is or should be any restriction upon a party to a business communication (which is what a report / complaint from a third party regarding key compromise, etc, is) from further dissemination of said

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

2019-08-16 Thread Matthew Hardeman via dev-security-policy
Honestly the issues, as I see them, are twofold: 1. When I visit a site for the first time, how do I know I should expect an EV certificate? I am conscientious about subsequent visits, especially financial industry sites. 2. The browsers seem to have a bias toward the average user, that user

Re: Use of Certificate/Public Key Pinning

2019-08-13 Thread Matthew Hardeman via dev-security-policy
I feel that there's a great deal of consultancy and assistance that CAs and PKI professionals could bring to their more sophisticated customers with scenarios such as these where public key pinning an a field-deployed application may present problems for certificates being revoked. A best

Re: DarkMatter CAs in Google Chrome and Android

2019-07-25 Thread Matthew Hardeman via dev-security-policy
On Thu, Jul 25, 2019 at 4:33 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Surely the answer is "Yes" ? I mean, it makes strategic sense to react > to a CA which tries to appeal a trust store decision over the heads of > the people making it in exactly

Re: Nation State MITM CA's ?

2019-07-24 Thread Matthew Hardeman via dev-security-policy
This is not at all a safe assumption. If they care to know and have active MITM infrastructure in place, the last time I looked at the issue, identifying which browser was in use (and generally speaking which operating system or set of operating systems) was fairly trivial by fingerprinting the

Re: Nation State MITM CA's ?

2019-07-22 Thread Matthew Hardeman via dev-security-policy
On Mon, Jul 22, 2019 at 9:20 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think the optimal solution in terms of user security is to create a > blacklist of known MITM CA public keys and simply prevent the installation > of certificates containing

Re: Nation State MITM CA's ?

2019-07-19 Thread Matthew Hardeman via dev-security-policy
While possible, that seems unlikely. Corporates are, in general, not trying to hide when this is being done. In fact, there are lots of good legal liability reasons why they should want their users to be constantly reminded. On Fri, Jul 19, 2019 at 10:27 AM Troy Cauble via dev-security-policy <

Re: Nation State MITM CA's ?

2019-07-18 Thread Matthew Hardeman via dev-security-policy
Regarding indicators, I agree that it should be more apparent. Perhaps a dedicated bar that occupies an entire edge-to-edge horizontal area. I would propose that it might have two distinct messages, as well: 1. A message that an explicitly known MiTM certificate exists in the certificate chain

Re: Nation State MITM CA's ?

2019-07-18 Thread Matthew Hardeman via dev-security-policy
If the government of Kazakhstan requires interception of TLS as a condition of access, the real question being asked is whether or not Mozilla products will tolerate being used in these circumstances. Your options are to block the certificate, in which case Mozilla products simply become unusable

Re: DarkMatter Concerns

2019-07-16 Thread Matthew Hardeman via dev-security-policy
In fairness, I think Mozilla essentially stipulated that this reason was given little or no weight in the decision. Specifically Wayne Thayer noted at [1]: Some of this discussion has revolved around compliance issues, the most prominent one being the serial number entropy violations discovered

Re: DarkMatter Concerns

2019-07-16 Thread Matthew Hardeman via dev-security-policy
Hi Kathleen and community, I understand that you've made a decision w/r/t the DarkMatter CA matters and am not writing to challenge or attempt influence on those. I'm responding here only in so far as that you were "intrigued" by my comments analogizing Mozilla Root Trust store decisioning to

Re: DarkMatter Concerns

2019-07-10 Thread Matthew Hardeman via dev-security-policy
On Wed, Jul 10, 2019 at 11:43 AM Scott Rea via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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

Re: DarkMatter Concerns

2019-07-10 Thread Matthew Hardeman via dev-security-policy
Even if we stipulated that all those accounts were fully accurate, all those reports are about a separate business that happens to be owned by the same owner. Furthermore, in as far as none of those directly speak to their ability to own or manage a publicly trusted CA, I would regard those

Re: DarkMatter Concerns

2019-07-09 Thread Matthew Hardeman via dev-security-policy
On Sun, Jun 23, 2019 at 11:52 AM Cynthia Revström via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > A position like this is

Re: DarkMatter Concerns

2019-07-09 Thread Matthew Hardeman via dev-security-policy
On Tue, Jul 9, 2019 at 4:34 PM mono.riot--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think it's less about a single person than about an alleged firewalling > of entities that end up being not firewalled at all, but all owned by the > same person in the end. >

Re: DarkMatter Concerns

2019-07-09 Thread Matthew Hardeman via dev-security-policy
On Tuesday, July 9, 2019 at 10:31:27 AM UTC-5, Wayne Thayer wrote: > DarkMatter has argued [3] that their CA business has always been operated > independently and as a separate legal entity from their security business. > Furthermore, DarkMatter states that once a rebranding effort is completed,

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

  1   2   3   >