On May 18, 2020, at 23:58, Peter Gutmann via dev-security-policy
wrote:
>
>
>
> This isn't snark, it's a genuine question: If the CA isn't checking that the
> entity they're certifying controls the key they're certifying, aren't they
> then not acting as CAs any more?
They are really only
On Mon, 12 Aug 2019, Nuno Ponte via dev-security-policy wrote:
Recently, we (Multicert) had to rollout a general certificate replacement due
to the serial number entropy issue. Some of the most troubled cases to replace
the certificates were customers doing certificate pinning on mobile apps.
> On Aug 12, 2019, at 14:30, Wayne Thayer via dev-security-policy
> wrote:
>
> Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
> which is expected to be released on 22-October. Details below.
Relocate seems a wrong word here. You are basically removing it. A few geeks
On Tue, 26 Feb 2019, Rob Stradling via dev-security-policy wrote:
Hi Scott. It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.
Direct link:
On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote:
Paul Wouters via dev-security-policy
writes:
Usually X509 is validated using standard libraries that only think of the TLS
usage. So most certificates for VPN usage still add EKUs like serverAuth or
clientAuth
> On Dec 5, 2018, at 16:49, Jakob Bohm via dev-security-policy
> wrote:
>
>
>
> Another question of relevance:
>
> Does the applicable VPN hardware and software (Cisco VPN servers and
> compatible VPN clients) work with certificates that omit all the TLS-
> related EKUs, thus allowing
On Oct 14, 2018, at 21:09, jsha--- via dev-security-policy
wrote:
>
> There’s a paper from 2013 outlining a fragmentation attack on DNS that allows
> an off-path attacker to poison certain DNS results using IP fragmentation[1].
> I’ve been thinking about mitigation techniques and I’m
On Thu, 16 Aug 2018, Matthew Hardeman via dev-security-policy wrote:
1. Run one or more root CAs
Why would people not in the business of being a CA do a better job than
those currently in the CA business?
I recognize it's a radical departure from what is. I'm interested in
understanding
On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote:
However, what does this buy us? Considering that the ZSKs are intentionally
designed to be frequently rotated (24 - 72 hours), thus permitting weaker
key sizes (RSA-512),
I don't know anyone who believes or uses these timings or
On Mon, 30 Apr 2018, Tim Hollebeek wrote:
What about the cases we discussed where there is DNSSEC, but only for a
subtree?
I don't know what that means? You mean a trust island not chained to the
root? If so, then yes, that is a zone without DNSSEC since it is missing
a DS in its parent (or
On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:
I don't think this opinion is in conflict with the suggestion that we
required
DNSSEC validation on CAA records when (however rarely) it is deployed. I
added this as https://github.com/mozilla/pkipolicy/issues/133
One of the
On Wed, 25 Apr 2018, Ryan Hurst via dev-security-policy wrote:
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
On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote:
The issues with EV are much larger than UI. It needs to be revisited and a
honest and achievable set of goals need to be established and the processes and
procedures used pre-issuance and post-issuance need to be defined in
On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote:
EV is on borrowed time
You don't explain why?
I mean domain names can be confusing or malicious too. Are domain names
on borrowed time?
If you remove EV, how will the users react when paypal or their bank is
suddenly no longer
On Thu, 30 Nov 2017, Tim Hollebeek via dev-security-policy wrote:
[somewhat off topic, you can safely hit delete now]
So it turns out DNSSEC solves CAA problems for almost nobody, because almost
nobody uses DNSSEC.
The only people who need to use CAA are the CA's. They can surely manage
to
On Thu, 30 Nov 2017, Wayne Thayer wrote:
[cut CC: list, assuming we're all on the list]
- Subscribers already (or soon will) have CT logs and monitors available to
detect mis-issued certs. They don't need CAA Transparency.
It's not for subscribers, but for CA's.
Transparency is nice, but
> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy
> wrote:
>
> This whole conversation makes me wonder if CAA Transparency should be a
> thing.
That is a very hard problem, especially for non-DNSSEC signed ones.
Paul
17 matches
Mail list logo