Re: Final Decision by Google on Symantec

2017-07-29 Thread Peter Bowen via dev-security-policy 
On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via
dev-security-policy  wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
[...]
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.

Gerv,

I think there three more things that Mozilla needs to decide.

First, when the server authentication trust will bits be removed from
the existing roots.  This is of notable importance for non-Firefox
users of NSS.  Based on the Chrome email, it looks like they will
remove trust bits in their git repo around August 23, 2018.  When will
NSS remove the trust bits?

Second, how the dates apply to email protection certificates, if at
all.  Chrome only deals with server authentication certificates, so
their decision does not cover other types of certificates.  Will the
email protection trust bits be turned off at some point?

Third, what the requirements are for Symantec to submit new roots,
including any limit to how many may be submitted.
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
shows that there are currently 20 Symantec roots included.  Would it
be reasonable for them to submit replacements on a 1:1 basis -- that
is 20 new roots?

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

Re: TunRootCA2 root inclusion request

2017-07-29 Thread Jonathan Rudenberg via dev-security-policy 
For reference, I’ve added crt.sh links for the replacement certificates below.

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy 
>  wrote:
> 
> https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; 
> notAfter March 2017) issued by this CA which has a wildcard name in the 
> common name while the SAN contains specific domain names that would be 
> covered by the wildcard only. 
> 
> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
> 2016-03-21 when the CA discover the mistake in the SAN extension. A new 
> certificate is issued on the same day (2016-03-21) with the right SAN 
> (*.sonede.com.tn). See the certificate below:
> 

https://crt.sh/?id=15597407

> https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 
> 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 
> 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name 
> certs with validity past November 2015.) 
> 
> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
> IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
> (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
> certificate below:

https://crt.sh/?id=180718609

> https://crt.sh/?id=79470561=cablint is a certificate for the internal 
> name 'adv-ail.calladvance.local' issued by this CA with a not Before of 2017. 
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=79470561=cablint. The certificate is revoked on 
> 28/07/2017 and replaced by a new certificate which does not contain  in SAN 
> extension the internal name "adv-mail.calladvance.local". See ertificate 
> below:

https://crt.sh/?id=180718608
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

2017-07-29 Thread Jonathan Rudenberg via dev-security-policy 

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy 
>  wrote:
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new 
> certificate is issued by TunServerCA2.to this end entity.
> 
> ==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 
> 2017-03-03 and issue a new one for the end entity 
> https://crt.sh/?id=99462700. The new certificate contains both names in SAN 
> (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at 
> the time of issuance, has  verified that the Applicant had the right to use 
> and had the control of the both Domain Names.
> 
> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
> 2016-03-21 when the CA discover the mistake in the SAN extension. A new 
> certificate is issued on the same day (2016-03-21) with the right SAN 
> (*.sonede.com.tn). See the certificate below:
> 
> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
> IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
> (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
> certificate below:
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=79470561=cablint. The certificate is revoked on 
> 28/07/2017 and replaced by a new certificate which does not contain  in SAN 
> extension the internal name "adv-mail.calladvance.local". See ertificate 
> below:
> 
> Olfa Kaddachi

These incidents appear to demonstrate a lack of sufficient technical controls 
to prevent certificates from being issued with unvalidated and invalid data. 
Would you please describe:

1) the technical controls currently implemented in the issuance process;
2) the deficiencies identified in those controls after the misissuance of each 
of these certificates;
3) the implemented and planned improvements to the technical controls to 
prevent these errors from happening again.

Thanks,

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

Re: TunRootCA2 root inclusion request

2017-07-29 Thread kaddachi olfa via dev-security-policy 
https://crt.sh/?id=21813439 is a certificate issued by this CA which has a 
domain name in the common name but only an email address in the SAN. (The 
certificate has TLS server/client usage EKUs.) 

==> The CA proceeded to notify the end entity of the certificate 
https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new 
certificate is issued by TunServerCA2.to this end entity.


https://crt.sh/?id=99182607 is a revoked certificate issued by this CA which 
has a domain name in the common name which does not match the domain name in 
the SAN, which is for a different TLD. (A new certificate with both names in 
SANs, https://crt.sh/?id=99462700 , has a notBefore which appears to have 
around the same timestamp as the revocation.) 


==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 
2017-03-03 and issue a new one for the end entity https://crt.sh/?id=99462700. 
The new certificate contains both names in SAN (DNS=vpn.tunisieclearing.com and 
Nom DNS=vpn.tunisieclearing.tn). The CA, at the time of issuance, has  verified 
that the Applicant had the right to use and had the control of the both Domain 
Names.

*

https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; 
notAfter March 2017) issued by this CA which has a wildcard name in the common 
name while the SAN contains specific domain names that would be covered by the 
wildcard only. 

==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
2016-03-21 when the CA discover the mistake in the SAN extension. A new 
certificate is issued on the same day (2016-03-21) with the right SAN 
(*.sonede.com.tn). See the certificate below:

-BEGIN CERTIFICATE-
MIIGuTCCBKGgAwIBAgIQQVkWAyEXAyAwgwPw3/OEojANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjAzMjEwMDAwMDBaFw0x
NzAzMjAyMzU5NTlaMIHMMQswCQYDVQQGEwJUTjFBMD8GA1UECgw4U1RFIE5BVElP
TkFMRSBEIEVYUExPSVRBVElPTiBFVCBERSBESVNUUklCVVRJT04gREVTIEVBVVgx
KDAmBgNVBAsMH0RJUkVDVElPTiBDRU5UUkFMRSBJTkZPUk1BVElRVUUxGDAWBgNV
BAMMDyouc29uZWRlLmNvbS50bjEmMCQGCSqGSIb3DQEJARYXd2VibWFzdGVyQHNv
bmVkZS5jb20udG4xDjAMBgNVBAcMBVRVTklTMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAtUqxkjJGrnLQ+fx4vif+PV9FlwTByGoQ5F/2Kc67u9iM0zBt
ttkcUHzdwoSkPLaYKezT3FQhuE7c1BKRBfne95zmDJ6kKbvoehUG6niJP6qOQ5p2
aT3oHPI87e20SQPFvvZMSbDftDq9/cH/69d+NkSlfAvihks7hp/zZv9QDdxaZh/O
SfA12SRUy0/Q2n7VKnJrUPBK3Ydyl0KOS5p6LNxOUG4faJ9Fil3OO2b54etyMMcc
QTiDqwDUXMohR3KzCQpUD9RGba41Stqwj7PO25YtNJbSSfCq5Sn9nZn8K9iapIDQ
1uwLO+VJf2SwEZl4iZulAhmXLieq/lv+oZreWQIDAQABo4IB5DCCAeAwDAYDVR0T
AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMBoGA1UdEQQTMBGCDyouc29uZWRlLmNvbS50bjAfBgNVHSMEGDAWgBSH
q/dpS1D2YVf/P1uOHXDGomyqxjA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vY3Js
LmNlcnRpZmljYXRpb24udG4vVHVuU2VydmVyQ0EyLmNybDB7BggrBgEFBQcBAQRv
MG0wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmNlcnRpZmljYXRpb24udG46ODA4
MDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL3B1Yi9U
dW5TZXJ2ZXJDQTIuY3J0MIGnBgNVHSAEgZ8wgZwwgZkGCGCGFAECBgEIMIGMMCwG
CCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL2NwczBcBggr
BgEFBQcCAjBQMCwWJU5hdGlvbmFsIERpZ2l0YWwgQ2VydGlmaWNhdGlvbiBBZ2Vu
Y3kwAwIBARogaHR0cHM6Ly93d3cuY2VydGlmaWNhdGlvbi50bi9ycGEwDQYJKoZI
hvcNAQELBQADggIBABUXwoV4YIrF4SVRUsb/dPhCO0uxcyVylVGz2y+OIDIsuy+d
7yJl4gCeLsMIIexWVqupnx1qzX8LR6ZMpVWbTeie0EFOppBU6S1OcFvf+6kQ9FNa
RwCUn+fcYr5+NQRZD2OmfIeiqJ/vo0yNKQ2j5KENG1JZ8AgyeJ1RBK8IxAHNe9oE
sdqjxXL54fh6t4zxfgavaRv9dZo+Ph4udEq1Ea/dKXg0pfsM1/bVpO+V1yaiL+lk
fH/diGWUVV5HTlmtPCXU3idUKZytOWsP+NljHxQAmVzv38aAvvC9r2Dgc/MScCHP
b7iBDDfwZRVj78MIAjHlf5cOAUCAJUmEC0lXnBNSRKAmYThCr+SVuKrqcwGcq5+X
yNo46/ba6y/M/Q3TPCgDlFzgpxJ2Ox3jntSuA6qhLgJagC1HJce0wqAfCy4rAYuD
WpsGr0rm65DSYgr+MZlcp4UNE1M+plKl7rXClYg5lRVX1c4glYr9+Do05z49ZRHq
1C8LpHbBYkDVbz/EsuDLZ+Y1wpo4Nec+PEfKm/Tc6Cyfr8JmHOhJ/YmaRg2UBh2q
1PE3gKyb5SZmmLmFBgwO5G91EvQOCSyuI/s7bzP5ra392q7Z9iFzadETjGjflWEq
pMMUmphu3cCez871AUvDhMKKDlEdGob8Xw3RTwz485FuUdL8qb2vw36Jhhki
-END CERTIFICATE-


**

https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 
2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 
127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name 
certs with validity past November 2015.) 

==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
(mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
certificate below:

-BEGIN CERTIFICATE-
MIIGqTCCBJGgAwIBAgIQQVkWEhQXEhOUxb2pudH/dDANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjEyMTQwMDAwMDBaFw0x
NzEyMTMyMzU5NTlaMIGkMQswCQYDVQQGEwJUTjEOMAwGA1UEChMFQ0VQRVgxHzAd

Re: Final Decision by Google on Symantec

2017-07-29 Thread Nick Lamb via dev-security-policy 
Other contributors have, I think, summed up the pros and cons of the two ways 
forward on the specific date very effectively.

So I will expend my effort instead on pressing for Mozilla to handle final 
distrust of the old Symantec CA roots in its usual fashion and explicitly _not_ 
do as Symantec asked in leaving it enabled in the NSS trust set we know is 
relied upon (whether wisely or not) by lots of things other than web browsers.

Once we have firm dates, I also recommend that we look for opportunities to 
advertise this issue and key deadline(s) to outfits like Qualys who are 
scanning web sites etc and reporting what they find. Regardless of any contact 
from Symantec, there still is no substitute for independent voices saying "This 
is a real problem, you need to take action by Specific Date or bad things will 
happen". Larger corporations will already have a process in place to assess the 
output of such scans, organise them by urgency and priority and get stuff done, 
which is what we need here, but they buy scans perhaps only once per year, so 
we need this to show up sooner rather than later to maximise the chance of 
resolution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy