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
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
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
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
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
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
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
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
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
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:
>
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,
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
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
> 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
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
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
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
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 <
>
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
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
>
> 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
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:
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
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
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
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
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
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 <
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
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
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
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
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
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
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
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.
>
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,
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
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 /
systems?
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 <
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
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
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
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
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 <
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
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
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.
>
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
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
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
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
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,
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
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
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?
>
Hi, Wayne,
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
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
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
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
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
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
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
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
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
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 <
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
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
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
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
69.168.110.79.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
to be
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
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:
>
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
> [1] -
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
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
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
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 <
dev-security-policy@lists.mozilla.org> wrote:
>
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
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
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
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
1 - 100 of 268 matches
Mail list logo
