On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy <
> 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
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
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
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 /
2. If these certificates don't have a purpose known to or respected by the
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
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
On Mon, Mar 11, 2019 at 12:18 PM Buschart, Rufus via dev-security-policy <
> 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
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.
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
On Fri, Mar 8, 2019 at 8:57 PM Peter Gutmann
> Matthew Hardeman via dev-security-policy <
> email@example.com> writes:
> >shall be 0x75
> Not 0x71?
:-) In truth, I think any particular chosen single value for the first
byte which h
I know this isn't the place to bring a BR ballot, but I'm not presently a
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
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
On Fri, Mar 8, 2019 at 3:10 AM Matt Palmer via dev-security-policy <
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
On Thu, Mar 7, 2019 at 9:28 PM Matt Palmer via dev-security-policy <
> 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
On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> 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.
On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy <
> 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
On Thu, Mar 7, 2019 at 8:20 PM Peter Gutmann
> 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
On Thu, Mar 7, 2019 at 8:14 PM Peter Gutmann
> 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
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
On Thu, Mar 7, 2019 at 7:47 PM Peter Gutmann via dev-security-policy <
> 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,
On Thu, Mar 7, 2019 at 5:35 PM Matt Palmer via dev-security-policy <
> 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
On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy <
> Whilst those are all good points, I don't see how any of them require the
> to control an unconstrained intermediate CA certificate (or a root
> certificate). All of those
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
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?
I think the matter of whether or not I could or should
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
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
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 "
On Thu, Mar 7, 2019 at 10:20 AM Matthew Hardeman
> 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.
On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy <
> 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
On Thu, Mar 7, 2019 at 10:10 AM Ken Myers (personal capacity) via
> 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
On Thu, Mar 7, 2019 at 9:18 AM nadim--- via dev-security-policy <
> 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
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
On Tue, Mar 5, 2019 at 11:10 AM Matthew Hardeman
> 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
On Tue, Mar 5, 2019 at 8:16 AM Alex Gaynor via dev-security-policy <
> 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
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
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
On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy <
> 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
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.
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
In addition to the GDPR concerns over WHOIS and RDAP data, reliance upon
these data sources has a crucial differentiation from other domain
Specifically, the WHOIS/RDAP data sources are entirely "off-path" with
respect to how a browser will locate and access a given site. To
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
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
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
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
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
220.127.116.11.in-addr.arpa pointed to
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
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
On Mon, Jan 14, 2019 at 5:45 PM Wayne Thayer via dev-security-policy <
> > 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
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
On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll 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
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
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
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
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
>  -
Of late, there seems to be an ever increasing number of misissuances of various
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
Simultaneously, there seems to be
Noted by the Oracle/Dyn team at:
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
On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
> > 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
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
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 <
On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy <
> 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
On Thu, May 31, 2018 at 8:38 PM, Peter Gutmann
> >Banks, trade vendors, etc, tend to reject accounts with names like this.
> Do they?
I would hope that we could agree that there is generally a different risk
management burden in
On Fri, Jun 1, 2018 at 10:28 AM, Ryan Hurst via dev-security-policy <
> 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
On Thu, May 31, 2018 at 5:03 PM, Kristian Fiskerstrand
> 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
On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via dev-security-policy <
> 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
On Thu, May 31, 2018 at 3:38 PM, James Burton via dev-security-policy <
> 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
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
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
To: Ryan Sleevi
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
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
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
> <firstname.lastname@example.org> wrote:
>> It is di
allowing the following CAs to issue for any email address over the same
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
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
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.
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,
On Wed, Apr 25, 2018 at 1:44 PM, Santhan Raj via dev-security-policy <
> 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
Also, during the period of the attack, they were using a self-signed
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
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
On Wed, Apr 25, 2018 at 11:42 AM, Santhan Raj
On Wed, Apr 25, 2018 at 11:01 AM, Quirin Scheitle via dev-security-policy <
> 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.
> 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
On Wed, Apr 25, 2018 at 8:47 AM, Paul Wouters via dev-security-policy <
> 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 :)
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,
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 18.104.22.168/24 22.214.171.124/24
2. It appears that AS10297 via peering
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
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
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
Can you repeat that test with, say,
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
Perhaps it should be the broader question of both issuance policy and
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
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
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.
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
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
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
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?
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
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
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
makes the payment processing company somehow more deserving of one than
>>>> Ian's company? Why was GoDaddy allowed to effectively take Ian's site
>>>> without his consent?
>>>> If this is how EV is goi
splay of EV information from Mozilla products.
>> -- Eric
>> On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via
>> <email@example.com> wrote:
>> > On Wed, Apr 11, 2018, at 15:27, Matthew Hardem
> On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via
> dev-security-policy <firstname.lastname@example.org> wrote:
>> On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy
>> > It was injudicious of a CA to issue anot
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 - 100 of 242 matches
Mail list logo