Apple's response to the WoSign incidents

2016-10-01 Thread certificate-authority-prog...@group.apple.com


Blocking Trust for WoSign CA Free SSL Certificate G2

Certificate Authority WoSign experienced multiple control failures in their 
certificate issuance processes for the WoSign CA Free SSL Certificate G2 
intermediate CA. Although no WoSign root is in the list of Apple trusted roots, 
this intermediate CA used cross-signed certificate relationships with StartCom 
and Comodo to establish trust on Apple products.

In light of these findings, we are taking action to protect users in an 
upcoming security update.  Apple products will no longer trust the WoSign CA 
Free SSL Certificate G2 intermediate CA.

To avoid disruption to existing WoSign certificate holders and to allow their 
transition to trusted roots, Apple products will trust individual existing 
certificates issued from this intermediate CA and published to public 
Certificate Transparency log servers by 2016-09-19. They will continue to be 
trusted until they expire, are revoked, or are untrusted at Apple’s discretion.

As the investigation progresses, we will take further action on WoSign/StartCom 
trust anchors in Apple products as needed to protect users.

Regards,

Apple Root Certificate Program

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Apple's response to the WoSign incidents

2016-10-01 Thread ramriot
Do you have a link to that process and is it automated. Reason is I have a few 
hundred startSSL certs that my clients rely on.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Apple's response to the WoSign incidents

2016-10-01 Thread Peter Bowen
On Sat, Oct 1, 2016 at 6:40 AM,   wrote:
> Do you have a link to that process and is it automated. Reason is I have a 
> few hundred startSSL certs that my clients rely on.

I can't speak for the specific process Apple is using, but in general
you can use https://crt.sh/ or
https://www.google.com/transparencyreport/https/ct/ (among many
others) to check and see if the certificates are logged in Certificate
Transparency logs.

As far as I know, StartCom has not actively logged certificates issued
in 2015 or earlier nor have they logged certificates issued in early
2016.  So it is very probable that some certificates are not logged.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Apple's response to the WoSign incidents

2016-10-01 Thread Kurt Roeckx
On Sat, Oct 01, 2016 at 11:35:06AM -0700, Percy wrote:
> "Apple products will trust individual existing certificates issued from this 
> intermediate CA and published to public Certificate Transparency log servers 
> by 2016-09-19"
> 
> It seems that Apple has taken the explicit white-listed approach despite the 
> size drawback mentioned in the other thread.

>From what I get, they check that it's been logged in CT. And I'm
not sure what that means, like doing an online check against at CT
log, require that the SCT has been stappled or have a whitelist.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Apple's response to the WoSign incidents

2016-10-01 Thread Eric Mill
On Sat, Oct 1, 2016 at 6:40 AM,  wrote:

> Do you have a link to that process and is it automated. Reason is I have a
> few hundred startSSL certs that my clients rely on.
>

Apple's statement was limited specifically to WoSign. StartSSL certificates
won't be affected, though they implied that action against StartCom could
depend on further results of the investigation. But even the WoSign action
is it's a whitelist that's limited to future certificates, so existing
certificates of any kind shouldn't be affected.

-- Eric


> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: WoSign and StartCom

2016-10-01 Thread Erwann Abalea
Bonjour,

Le samedi 1 octobre 2016 11:02:21 UTC+2, Stefan Paletta a écrit :
[...]
> I have one question about the proposal: what is the rationale and 
> justification for the one-year minimum distrust? While this seems quite 
> reasonable at first glance, my thinking is this: clearly, the proposed 
> extensive audit must be deemed sufficient to allow for re-qualification a 
> year from now (because otherwise you would not be proposing it). Then why 
> would such an extensive audit not be sufficient when executed right now? In 
> other words: what does the addition of simply waiting for a year change about 
> admissibility to the Mozilla roots?

The auditor doesn't predict the future. The auditor can only audit what was 
made in the past.
I consider the Mozilla investigation to be an audit, and the findings are 
really bad. Another extensive audit performed right now can't possibly give a 
different result.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Apple's response to the WoSign incidents

2016-10-01 Thread Percy
"Apple products will trust individual existing certificates issued from this 
intermediate CA and published to public Certificate Transparency log servers by 
2016-09-19"

It seems that Apple has taken the explicit white-listed approach despite the 
size drawback mentioned in the other thread. I know Apple is a OS vendor which 
probably makes such a deployment easier to implement. But the size of the 
whitelist is not really a concern over the desktop environment. So I hope 
Mozilla and Google can have a explicit whitelist approach on desktop while use 
the notBefore data on mobile to have the stronger safe guard when possible. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy