Thanks, Corey.
I've added this as a matter to consider in a future version of the Root
Store Policy. https://github.com/mozilla/pkipolicy/issues/215
On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> While I realize the current
While I realize the current topic is concerning TLS, I find it rather
surprising that Mozilla Policy does not mandate PoP for S/MIME certificate
issuance. Lack of checking for S/MIME would present more concrete security
concerns, so perhaps this should be addressed in a future update to the Poli
Matthew Hardeman via dev-security-policy
writes:
>The standard use of the most common way of communicating the public key and
>the purported proof-of-possession of the private key to the CA, the CSR, does
>not provide replay protection and yet is frequently NOT treated as a security
>impacting e
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 co
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote:
> With proof of possession, these situations can be detected and raised as
> being not-just-theoretical, and the CAs (or whoever wants to search the CT
> logs) can notify the entities involved that they probably want to change
> their keys. In
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote:
> A potential attack without Proof of Possession which PKIX glosses over
> could involve someone believing that a signature on a document combined
> with the non-possession-proved certificate constitutes proof of possession,
> and combined with
On Tue, May 19, 2020 at 12:35 AM Kyle Hamilton wrote:
>
>
> On Mon, May 18, 2020, 19:46 Ryan Sleevi wrote:
>
>> On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
>> wrote:
>>
>> > Regardless of that potential con, though, there is one very important
>> thing
>> > which Proof
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 cer
On Mon, May 18, 2020, 19:46 Ryan Sleevi wrote:
> On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
> wrote:
>
> > Regardless of that potential con, though, there is one very important
> thing
> > which Proof of Possession is good for, regardless of whether any credible
> > at
That is my reading of the situation, that they're not doing an actual
certification of an enrollment without verifying the actual key-identity
binding.
In addition, I'm wondering if the concept of "third-party attestation" (of
identity) is even a thing anymore, given that most CAs issue certificat
A bit of philosophical question here: Certificates are pretty much universally
described in PKI texts and the like as a cryptographic binding between an
identity and a key, in other words an assertion by the CA that the key in the
cert is associated with the identity in the cert.
If there's no req
On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
wrote:
> A potential attack without Proof of Possession which PKIX glosses over
> could involve someone believing that a signature on a document combined
> with the non-possession-proved certificate constitutes proof of possessi
CABForum's current Basic Requirements, section 3.2.1, is titled "Method to
prove possession of private key".
It is currently blank.
A potential attack without Proof of Possession which PKIX glosses over
could involve someone believing that a signature on a document combined
with the non-possessio
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,
I did not state the point well. "Scary example" as I used it above was
merely because it was a reference to StartCom at all (given the history,
etc.) -- not particularly in the context of this practice.
I concur that I see no risk in leaf certificates issued with signatures
over public keys for w
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 emphasized _only_ the public key
> data) from the CSR. Everything else was populated out-of-band
.mozilla.org>; Jeremy Rowley <
> jeremy.row...@digicert.com>
> Subject: Re: Digicert issued certificate with let's encrypts public key
>
> Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >For those interested, the s
It was just the one system and situation-specific.
-Original Message-
From: dev-security-policy On
Behalf Of Peter Gutmann via dev-security-policy
Sent: Monday, May 18, 2020 6:31 AM
To: Matt Palmer ; Mozilla
; Jeremy Rowley
Subject: Re: Digicert issued certificate with let
Jeremy Rowley via dev-security-policy
writes:
>For those interested, the short of what happened is that we had an old
>service where you could replace existing certificates by having DigiCert
>connect to a site and replace the certificate with a key taken from the site
>after a TLS connection. N
cy
Sent: Sunday, May 17, 2020 10:37 PM
To: Mozilla
Subject: Re: Digicert issued certificate with let's encrypts public key
On Mon, May 18, 2020 at 03:46:46AM +, Peter Gutmann via dev-security-policy
wrote:
> I assume this is ACME that allows a key to be certified without any
> proof
On Mon, May 18, 2020 at 03:46:46AM +, Peter Gutmann via dev-security-policy
wrote:
> I assume this is ACME that allows a key to be certified without any proof that
> the entity requesting the certificate controls it?
ACME requires a CSR to be submitted in order to get the certificate issued.
On Sun, May 17, 2020 at 10:47 PM Peter Gutmann via dev-security-policy
wrote:
> I assume this is ACME that allows a key to be certified without any proof that
> the entity requesting the certificate controls it? I don't know that any of
> the PKIX protocols allow it.
I do not see anywhere in AC
Matthew Hardeman writes:
>What gap, exactly? There’s not a risk here.
There are attacks possible, but this stuff was covered more than twenty years
ago by PKIX and I can't remember the specifics. It was around various ways of
fooling a victim that you'd signed something that you hadn't based o
> 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 a
Corey Bonnell writes:
>Certificate renewal that uses the existing certificate as input, rather than
>a CSR. The (presumably expiring) certificate supplies the domains,
>organization info, and the public key for the renewal certificate request. In
>this case there is no proof of key possession abs
Peter Bowen writes:
>There is no requirement to submit a PKCS#10 CSR.
Hmm, so what sort of issue process allows you to obtain a certificate for a key
you don't control?
Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mo
On Sat, May 16, 2020 at 8:18 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Kurt Roeckx via dev-security-policy
> writes:
>
> >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627
> >
> >It's a certificate for api.pillowz.kz with the public key
Kurt Roeckx via dev-security-policy
writes:
>Browsing crt.sh, I found this: https://crt.sh/?id=1902422627
>
>It's a certificate for api.pillowz.kz with the public key of Let's Encrypt
>Authority X1 and X3 CAs.
How could that have been issued? Since a (PKCS #10) request has to be self-
signed,
On Sat, May 16, 2020 at 10:11 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via
> dev-security-policy wrote:
> > On Sat, 16 May 2020 14:02:42 +0200
> > Kurt Roeckx via dev-security-policy
> > wrote:
>
On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy
wrote:
> On Sat, 16 May 2020 14:02:42 +0200
> Kurt Roeckx via dev-security-policy
> wrote:
>
> > https://crt.sh/?id=1902422627
> >
> > It's a certificate for api.pillowz.kz with the public key of Let's
> > Encrypt Aut
On Sat, 16 May 2020 14:02:42 +0200
Kurt Roeckx via dev-security-policy
wrote:
> https://crt.sh/?id=1902422627
>
> It's a certificate for api.pillowz.kz with the public key of Let's
> Encrypt Authority X1 and X3 CAs.
>
> It's revoked since 2020-01-31, but I couldn't find any incident
> report re
31 matches
Mail list logo