El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham escribió:
> On 08/08/17 14:33, Alex Gaynor wrote:
> > Following up on this thread, 8 days ago I emailed Camerfirma, I have not
> > heard back from them, nor have they taken any action. What is the
> > appropriate next step here?
>
On 16/08/17 22:57, alex.gaynor--- via dev-security-policy wrote:
On Wednesday, August 16, 2017 at 11:22:01 AM UTC-4, Rob Stradling wrote:
BTW, I've just asked Alex to look at adding the "CA Owner" field to the
misissued.com reports. :-)
It does this now :-)
Excellent. Thanks Alex. :-)
El jueves, 17 de agosto de 2017, 12:26:05 (UTC+2), ramiro...@gmail.com
escribió:
> El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham escribió:
> > On 08/08/17 14:33, Alex Gaynor wrote:
> > > Following up on this thread, 8 days ago I emailed Camerfirma, I have not
> > > heard
Am Montag, 14. August 2017 18:44:59 UTC+2 schrieb Jonathan Rudenberg:
> Hi Arno and Martin,
>
> > On Aug 14, 2017, at 11:44, Arno Fiedler wrote:
> >
> > Dear Forum,
> >
> > since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at least
> > 64 bits of
Just from the posted serial numbers, it looks almost like the high order bits
may represent 32 bits of random, which is still far short of the requirement.
Perhaps they intended a 48 bit sequential counter after a 32 bit random, or
intended a 64 bit random followed by a 16 bit sequential
> On Aug 16, 2017, at 19:18, Kathleen Wilson via dev-security-policy
> wrote:
>
> Bugs filed...
Hi Kathleen,
It looks like a bug was not created for GoDaddy about these certificates with
invalid dnsNames, containing a space at the beginning of the
Filed bug for GoDaddy:
https://bugzilla.mozilla.org/show_bug.cgi?id=1391429
Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Thank you to everyone who has reviewed and commented on this request from
TrustCor to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and
“TrustCor ECA-1” root certificates and enable the Websites and Email trust bits.
I believe that all of the questions and concerns have been
Since QuoVadis has not yet responded, let me point to a few (partial)
answers already known from previous messages from QuoVadis or others:
On 15/08/2017 14:53, Ryan Sleevi wrote:
On Tue, Aug 15, 2017 at 4:53 AM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org>
Hi Arno,
Tools like https://github.com/alex/ct-tools or
https://github.com/grahamedgecombe/ct-submit can be used to manually submit
specific certificates to CT logs.
Alex
On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Am
CA Disig revoked listed non-conforming certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On Wednesday, August 16, 2017 at 2:06:21 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy
> > wrote:
> >
> > After looking into this more, I’ve found that the majority of certificates
> > issued
On 15/08/17 21:24, Kathleen Wilson wrote:
> Mozilla's Root Store policy says: "CAs MUST follow and be aware of
> discussions in the mozilla.dev.security.policy forum, where Mozilla's
> root program is coordinated."
>
> There is no indication about how frequently a representative of the
> CA must
Thanks Neil,
I've looked over the updated CP and CPS documents and have no further
comments or questions.
Cheers,
Andrew
On Tue, Aug 15, 2017 at 12:18 PM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Andrew,
>
> SHA-1 has been removed from the TrustCor
> On Aug 16, 2017, at 23:35, Aaron Wu via dev-security-policy
> wrote:
>
> Hi Jonathan,
>
> Thanks for reminding! I've sent mail to POC of AC Camerfirma and these two
> intermediate certs has been disclosed in CCADB now.
One of these intermediates is
> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy
> wrote:
>
> https://crt.sh/?id=112929021=cablint
> is a precertificate. You can see the CT Precertificate Poison critical
> extention.
The serial number of this certificate should
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy
> > wrote:
> >
> > I looked through the CT logs and found 15 more unexpired unrevoked
> > certificates
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy
> > wrote:
> >
> > I looked through the CT logs and found 15 more unexpired unrevoked
> > certificates
On Wednesday, August 9, 2017 at 9:53:14 PM UTC-4, Alex Gaynor wrote:
> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> was to IdenTrust)
>
> Hi,
>
> The following certificates appear to be misissued:
>
> https://crt.sh/?id=77893170=cablint
>
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy
> > wrote:
> >
> > I looked through the CT logs and found 15 more unexpired unrevoked
> > certificates
> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy
> wrote:
>
> Hello, In reference to 3)"Certificates that appear to be intended as client
> certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for
> the Mozilla Root
Without an FQDN, I doubt they are in scope for the baseline requirements. They
are in scope for the Mozilla policy. The BRs require the cert to be intended
for web tls. These are not. The Mozilla policy covers client certs as well as
tls.
> On Aug 17, 2017, at 12:27 PM, identrust--- via
22 matches
Mail list logo