On 2017-12-09 at 08:59 -0700, Wayne Thayer wrote:
> It can be confusing even for people following these things. That's where I
> think collecting problem reporting info from audited sub-CAs in CCADB would
> help.
>
> For everyone else, finding the correct problem reporting information is
> mostly
On 12/09/2017 01:50 AM, Kurt Roeckx via dev-security-policy wrote:
> But it's not obvious to me who to contact to revoke a given
> certifiate, and it would be really useful that given a certificate
> it would be obvious what to do, who to contact, to get it revoked.
Could it be useful to establish
It can be confusing even for people following these things. That's where I
think collecting problem reporting info from audited sub-CAs in CCADB would
help.
For everyone else, finding the correct problem reporting information is
mostly a matter of luck. Perhaps we should require an email address
On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sat, 9 Dec 2017 09:51:59 +0100
> Hanno Böck via dev-security-policy
> wrote:
>
> > On Fri, 8 Dec 2017 16:43:48 -0700
> > Wayne Thayer via dev-security-policy
> > wrote:
> >
> >
On Sat, 9 Dec 2017 09:51:59 +0100
Hanno Böck via dev-security-policy
wrote:
> On Fri, 8 Dec 2017 16:43:48 -0700
> Wayne Thayer via dev-security-policy
> wrote:
>
> > The root CA is ultimately responsible for subordinate CAs it has
> > signed.
>
> I see a problem with that, as this is far f
On Fri, 8 Dec 2017 16:43:48 -0700
Wayne Thayer via dev-security-policy
wrote:
> The root CA is ultimately responsible for subordinate CAs it has
> signed.
I see a problem with that, as this is far from obvious.
If a random person discovers a problem with a certificate it seems
quite natural t
On Fri, Dec 08, 2017 at 11:55:46PM +0100, Hanno Böck via dev-security-policy
wrote:
> So I wonder: If a CA signs an intermediate - are they responsible
> making sure that reports brought to the subca are properly handled?
My first reaction would be if you sign it, you take
responsibility. That wo
On Fri, Dec 8, 2017 at 3:55 PM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> So I wonder: If a CA signs an intermediate - are they responsible
> making sure that reports brought to the subca are properly handled?
>
> The root CA is ultimately responsible f
Hi,
I guess this is of interest to the members of this list:
https://www.golem.de/news/microsoft-dynamics-365-wildcard-certificate-with-a-private-key-for-everyone-1712-131544.html
https://medium.com/matthias-gliwka/microsoft-leaks-tls-private-key-for-cloud-erp-product-10b56f7d648
tl;dr Microsoft
These 8 pre-certificates are not test certificates and were produced after
proper authentication and verification. Our customer first presented the 8
requests to their managed service, which produced SHA256 certificates subject
to human verification and automated compliance checks that leverage
Our online systems are blocked from issuing SHA-1 TLS certificates. These eight
certificates were signed in a multi-person key ceremony on an offline system
that uses externally unpredictable inputs for serial number generation. The
keys were generated by a service partner of the customer. Those
On 14/07/16 04:02, sanjay_m...@symantec.com wrote:
On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1
certificates in support of one customer’s application to submit SHA-1 TBS
Certificates to the CA/B Forum for a SHA-1 exception. Symantec has revoked the
certificates.
Sanj
On Thu, Jul 14, 2016 at 02:52:41AM -0700, Nick Lamb wrote:
> On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:
> > Revocation does not address the risk that this mis-issuance has caused
> > to the ecosystem, since collided certificates (the ones we cannot see,
> > and need to be worried
On Thu, 14 Jul 2016 02:52:41 -0700 (PDT)
Nick Lamb wrote:
> On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:
> > Revocation does not address the risk that this mis-issuance has
> > caused to the ecosystem, since collided certificates (the ones we
> > cannot see, and need to be worrie
On 7/13/16 8:02 PM, sanjay_m...@symantec.com wrote:
On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1
certificates in support of one customer’s application to submit SHA-1 TBS
Certificates to the CA/B Forum for a SHA-1 exception. Symantec has revoked the
certificates. An in
On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:
> Revocation does not address the risk that this mis-issuance has caused
> to the ecosystem, since collided certificates (the ones we cannot see,
> and need to be worried about) have different serial numbers and
> therefore do not appear
On 14/07/16 05:17, Andrew Ayer wrote:
Have the key pairs been used previously?
Hi Andrew.
All 8 of these SHA-1 precertificates are known to CT and crt.sh. The
same 8 public keys appear in a further 8 SHA-256 precertificates that
were issued 5 days earlier by a different Symantec issuing CA.
On Wed, 13 Jul 2016 20:02:58 -0700 (PDT)
sanjay_m...@symantec.com wrote:
> On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1
> certificates in support of one customer’s application to submit SHA-1
> TBS Certificates to the CA/B Forum for a SHA-1 exception. Symantec
> has revoke
On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1
certificates in support of one customer’s application to submit SHA-1 TBS
Certificates to the CA/B Forum for a SHA-1 exception. Symantec has revoked the
certificates. An internal process review is underway.
All signed by Ver
19 matches
Mail list logo
