> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Devon O'Brien via dev-security-policy
> Sent: Wednesday, August 09, 2017 12:24 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject:
On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote:
> IdenTrust is fully aware of the situation and has consulted with internal and
> external parties to ensure that our course of action is appropriate and
> commensurate with our business practices and accommodates our custom
I see both sides on this matter.
On the one hand, certlint/cablint catches lots of obvious problems, mostly with
ridiculous certificate profiles or manual special purpose issuances.
Certainly, there's a lot of bad issuance that having it in the blocking path
might help with...
but...
If one
Andrew.
Thank you for the review, comments and questions on TrustCor's policy documents.
We are in the process of reviewing your comments and formulating a response to
each. We will provide our response and updates before EOB Tuesday, August
15th, published to this discussion list.
Have a gre
On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote:
> On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > We acknowledge seeing this issue and are looking into it.
> > Details will be supplied as soon we ca
On 11/08/2017 15:39, Policy Authority PKIoverheid wrote:
2. Why did DDY not implement the serial number entropy as required by the
Baseline Requirements?
3. Was this detected by the auditor? If not, why not?
ANSWER ON QUESTION 2:
DDY concluded wrongly that ballot 164 was not applicable for
On Fri, Aug 11, 2017 at 1:22 PM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote:
> > Could you expand on this? It's not obvious what you mean.
>
> I guess I was unclear. My concern was that one obviou
On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote:
> Could you expand on this? It's not obvious what you mean.
I guess I was unclear. My concern was that one obvious way to approach this is
to set things up so that after the certificate is signed, Boulder runs cablint,
and if it finds
On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via dev-security-policy
wrote:
> On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
> > > Given that these w
On top of what Ryan has written, I want to specifically praise the approach of
actually checking a sample of certificates as PKIoverheid describes.
I think done well this can be a very affordable yet timely and effective way to
detect problems in a particular issuance pipeline or with a particul
On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
> > Given that these were all caught by cablint, has Let's Encrypt considered
> > integrating it into your issuance pi
On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
> Given that these were all caught by cablint, has Let's Encrypt considered
> integrating it into your issuance pipeline, or automatically monitoring
> crt.sh (which runs cablint) for these issues so they don't need to be
> caught manual
On 8/11/2017 7:26 AM, Ben Wilson wrote:
>
> With regard to Siemens, given the large number of certificates and
> the disruption that massive revocations will have on their
> infrastructure, what does this community expect them to do?
>
Each violation of published requirements for the operation o
Mark,
Thanks for providing a detailed report about this, including the steps
being taken to prevent future events like this. Your proposed remediation
plans sound like excellent steps to ensure future conformance, and
demonstrate an understanding as to the root causes and how to prevent them
in th
QuoVadis Enterprise Trust CA 2 G3 signed the Siemens Issuing CA Internet Server
2016.
From: Jeremy Rowley
Sent: Friday, August 11, 2017 8:36 AM
To: Ben Wilson
Cc: Alex Gaynor ; Jonathan Rudenberg
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits
Dear Mozilla Security Policy Community,
My apologies for the delayed follow up response.
As stated in my email from 07/25/2017, Digidentity (DDY), one of our TSP’s,
issued 777 certificates from September 30th 2016 which were not compliant with
BR ballot 164.
DDY has fixed the problem with the
They are no longer issuing from the digicert cross. The issue is within their
PKI but there should be no additional certificates chained to DigiCert roots
On Aug 11, 2017, at 8:33 AM, Ben Wilson
mailto:ben.wil...@digicert.com>> wrote:
Apparently they haven’t yet, but we’ll assume that they wil
Apparently they haven’t yet, but we’ll assume that they will.
Does the community expect a remediation plan for their code and then a
revocation-and-replacement plan?
Ben Wilson, JD, CISA, CISSP
VP Compliance
+1 801 701 9678
From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Frida
Have they fixed whatever issue there is with their PKI infrastructure that
leads to this issue? From skimming, I see this pool contains certs issued
as recently as one month ago.
Alex
On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wro
With regard to Siemens, given the large number of certificates and the
disruption that massive revocations will have on their infrastructure, what
does this community expect them to do?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lis
Given the rarity of such events, it will be hard for subscribers to
ensure they properly handle automated "renew prematurely" messages,
so other contact methods designed to reach human operators would often
be preferable.
But for fully automated "fire-and-forget" servers, I think the most
efficie
On Thu, Aug 10, 2017 at 1:22 PM, Jonathan Rudenberg via
dev-security-policy wrote:
> RFC 5280 section 7.2 and the associated IDNA RFC requires that
> Internationalized Domain Names are normalized before encoding to punycode.
>
> Let’s Encrypt appears to have issued at least three certificates tha
Hi Josh,
Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint) for these issues so they don't need to be
caught manually by researchers?
Alex
On Thu, Aug 10, 2017 at 11:00 PM,
This is a great point, re:automated issuance systems like ACME. I've
suggested to the Let's Encrypt folks the idea of a "should I re-issue"
endpoint that clients can poll. This would give CAs a programatic ability
to broadcast to subscribers that they should reissue now because the cert
is about to
24 matches
Mail list logo