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
Hi Matthias,
We're aware of this. Could you explain what issue or issues this
presents to you?
Understanding that different projects can and do use different
workflows to address their needs, it's not immediately clear to me
what impact, if any, this might have for you, and it's unclear why the
Hi Jeremy,
Thanks for responding,
On Mon, 18 May 2020 at 21:58, Jeremy Rowley via dev-security-policy
wrote:
>
> There are others in this same group of pending Mozilla closure:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1496616
> https://bugzilla.mozilla.org/show_bug.cgi?id=1463975
>
There are others in this same group of pending Mozilla closure:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496616
https://bugzilla.mozilla.org/show_bug.cgi?id=1463975
https://bugzilla.mozilla.org/show_bug.cgi?id=1532559
https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 (Waiting on Wayne)
I think your list of 23 is wrong. For example, bug 1550645 is just waiting for
Mozilla closure. It looks like 1605804 is in the same boat.
-Original Message-
From: dev-security-policy On
Behalf Of Matthias van de Meent via dev-security-policy
Sent: Monday, May 18, 2020 1:04 PM
To: MDSP
All,
I have looked at the list of open bugs in the CA compliance dashboard
[0], and I was unpleasantly suprised. There's a total of 75 open
issues at the moment of writing, of which 31 have not seen an update
in 4 weeks, and of which again 23 [1] are not waiting for a planned
future CA or Mozilla
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
I give you a brief status report on CA software development.
Microsec has already completed the development of CA software and introduced
additional automatic checks for the proper configuration of the SN fields in
case of different certificate types.
A number of internal tests have already
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
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.
18 matches
Mail list logo
