On Thu, Jun 30, 2016 at 11:10:45AM -0500, Peter Kurrasch wrote:
> Very interesting. This is exactly the sort of thing I'm concerned about
> with respect to Let's Encrypt and ACME.
Why? StartCom isn't the first CA to have had quite glaring holes in its
automated DCV interface and code, and I'm sur
On Wednesday, June 8, 2016 at 7:56:44 AM UTC-5, Peter Kurrasch wrote:
> I have comments as well. I made it to only Section 3.2.1 before I decided I
> have too many concerns about Let's Encrypt to include in a review of the CPS.
> I'll raise them in a separate thread, so here are my comments on ju
On Thursday, 30 June 2016 09:29:15 UTC+1, Rob Stradling wrote:
> The cross-certificate issued by Symantec to "Federal Bridge CA 2013"
> (https://crt.sh/?id=12638543) expires in 1 month. I'm wondering if
> there's any point in revoking this intermediate or the two other
> intermediates that Pet
On Thursday, 30 June 2016 18:13:53 UTC+1, Peter Kurrasch wrote:
> Let's be even more pointed: How do we know that *any* of the certs issued
> through this interface were issued to the right person for the right domain?
> How can StartCom make that determination?
Assuming that
* This was the o
On Thu, 30 Jun 2016 22:36:19 +0200
Christiaan Ottow wrote:
> We acquired certificates for a private domain (and some subdomains)
> of the tester in question, and one for our domain pine.nl. Details of
> the latter are attached, with the modulus and signature left out. The
> SHA256 fingerprint of
On 30 Jun 2016, at 22:00, Andrew Ayer wrote:
>
> On Thu, 30 Jun 2016 15:54:02 -0400
> Jonathan Rudenberg mailto:jonat...@titanous.com>>
> wrote:
>
>>
>>> On Jun 30, 2016, at 15:44, Christiaan Ottow
>>> wrote:
>>>
>>> The certificates we had issuedto us as proof of concept (only for
>>> our
On Thu, 30 Jun 2016 15:54:02 -0400
Jonathan Rudenberg wrote:
>
> > On Jun 30, 2016, at 15:44, Christiaan Ottow
> > wrote:
> >
> > The certificates we had issuedto us as proof of concept (only for
> > our own domains), were not revoked and we don't see them in the CT
> > logs. However, we info
On Thu, 30 Jun 2016 21:44:02 +0200
Christiaan Ottow wrote:
> > On 6/30/16 8:30 AM, Rob Stradling wrote:
> > > https://www.computest.nl/blog/startencrypt-considered-harmful-today/
> > >
> > > Eddy, is this report correct? Are you planning to post a public
> > > incident report?
> >
> > Does
> On Jun 30, 2016, at 15:44, Christiaan Ottow wrote:
>
> The certificates we had issuedto us as proof of concept (only for our own
> domains), were not revoked and we don't see them in the CT logs. However, we
> informed StartCom that we had only issued certificates for domains under our
> c
> On 6/30/16 8:30 AM, Rob Stradling wrote:
> > https://www.computest.nl/blog/startencrypt-considered-harmful-today/
> >
> > Eddy, is this report correct? Are you planning to post a public
> > incident report?
>
> Does StartCom honor CAA?
>
> Does StartCom publish to CT logs?
>
> How many
On Thu, Jun 30, 2016 at 12:46 PM, Juergen Christoffel <
juergen.christof...@zv.fraunhofer.de> wrote:
> On 30.06.16 18:24, Phillip Hallam-Baker wrote:
>
>> What makes something easy to hack in Perl does not make for good security
>> architecture.
>>
>
> Bad design, engineering or implementation is
TBH, the OWASP Top Ten is not really a metric, it's a set of general bins
of threats. There's no such thing as "passing the OWASP Top Ten".
I think you're going to struggle to establish any sort of objective,
general criteria. These protocol bugs are challenging to find and specific
to different
All good points. I wonder if we need to start with something more basic:
setting expectations.
Maybe we need to communicate to all participating CA's that we expect them to
perform a security scan of all Internet-facing interfaces. That we expect each
interface to be able to pass the OWASP Top
Let's be even more pointed: How do we know that *any* of the certs issued
through this interface were issued to the right person for the right domain?
How can StartCom make that determination?
Original Message
From: Daniel Veditz
Sent: Thursday, June 30, 2016 12:04 PM
...
How many mis-is
On 6/30/16 8:30 AM, Rob Stradling wrote:
> https://www.computest.nl/blog/startencrypt-considered-harmful-today/
>
> Eddy, is this report correct? Are you planning to post a public
> incident report?
Does StartCom honor CAA?
Does StartCom publish to CT logs?
How many mis-issued certs were obtai
On 30 June 2016 at 11:10, Peter Kurrasch wrote:
> Very interesting. This is exactly the sort of thing I'm concerned about with
> respect to Let's Encrypt and ACME.
>
> I would think that all CA's should issue some sort of statement regarding the
> security testing of any similar, Internet-facing
On 30.06.16 18:24, Phillip Hallam-Baker wrote:
What makes something easy to hack in Perl does not make for good security
architecture.
Bad design, engineering or implementation is not primarily a problem of the
language used. Or we would never have seen buffer overflows in C. Please
castigate
Argh
As with Etherium, the whole engineering approach gives me a cold sweat.
Security and scripting languages are not a good mix.
What makes something easy to hack in Perl does not make for good security
architecture.
:(
On Thu, Jun 30, 2016 at 11:30 AM, Rob Stradling
wrote:
> https://
Very interesting. This is exactly the sort of thing I'm concerned about with
respect to Let's Encrypt and ACME.
I would think that all CA's should issue some sort of statement regarding the
security testing of any similar, Internet-facing API interface they might be
using. I would actually like
https://www.computest.nl/blog/startencrypt-considered-harmful-today/
Eddy, is this report correct? Are you planning to post a public
incident report?
Thanks.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_
On 30/06/16 06:34, Peter Bowen wrote:
I think there is confusion over the generic term “Symantec”. There is no issue
for Symantec (the company) to be an affiliate of the USG FPKI and to operate
CAs mutually cross-certified with the USG FPKI. Additionally there is no issue
with Symantec (or a
21 matches
Mail list logo