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
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
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
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
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
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, 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
> >
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
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
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
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
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
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
rg>; 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 short of what ha
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's
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.
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 that the entity requ
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
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
> 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
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
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
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
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
Hi,
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.
It's revoked since 2020-01-31, but I couldn't find any incident
report related to it.
Kurt
32 matches
Mail list logo
