CA Validation quality is failing

I found out that often the OV or EV validation of CA's is lacking and conce=
rning the baseline requirements data submitted for a TLS certificate should=
 be valid and thus validated. So when a country is Amsterdam, that should f=
ail or a city Utrecht is placed in the province Zuid-Holland, that should f=
ail to. And in my believe these checks are not difficult, just implement th=
e Google Maps API and you would probably fix 60% of the bad certificate dat=
a. But The thing I do not understand is when validating a company, which wi=
ll use the certificate for whatever website request a TLS certificate. Most=
ly the company registration office (for example KVK in the Netherlands) wil=
l supply the CA with correct data. If the data submitted by the certificate=
 requester is incorrect, the certificate should never be issued. Period.

Here is a public link of a screenshot from the data found in the certificat=
e:
https://dl.dropboxusercontent.com/u/2676712/digicert.png

Lately I discover those issues with several DigiCert certificates, but they=
 are not the only CA making those mistakes. And to be honest those mistake =
really downgrade the OV and or EV value of the certificates to nothing more=
 than a domain validated, encryption only TLS connection. As part of this b=
ad validation and in my opinion failing to comply to the baseline requireme=
nts. Which could initiative encourage phishing and the de-trust in TLS in g=
eneral.=20

Kind Regards,

Mike
0
Mike
4/19/2017 6:51:02 PM
mozilla.dev.security.policy 1198 articles. 1 followers. Post Follow

33 Replies
121 Views

Similar Articles

[PageSpeed] 25

To add some more concerning this issue:

https://xenapp.alpinvest.com/
https://adoftheyear.com
https://secure.mobihealth.com
https://portal.mobilitymixx.nl
https://mijn.nfu.nl
https://portal.payplaza.com

I also believe that this happens often with the re-use of once (wrong) data for issue-ing new certificates.
I think it is a bad idea that SSL certificates for OV and EV do not get a max 3 months re-issue to be sure all data is correct or the company did not went bankrupt. But that might be something for another topic. 
0
Mike
4/19/2017 7:13:27 PM
On Wednesday, April 19, 2017 at 3:13:36 PM UTC-4, Mike Pasarella wrote:
> To add some more concerning this issue:
>=20
> https://xenapp.alpinvest.com/

https://crt.sh/?id=3D42227446

localityName of Amsterdam
stateOrProvinceName of 19
countryName of NL

Problem has existed since 2013 - https://crt.sh/?id=3D6164627

> https://adoftheyear.com

https://crt.sh/?id=3D55977126

localityName of Rotterdam
stateOrProvinceName of California
countryName of NL

https://crt.sh/?id=3D5178826 goes back to at least 2014

Previous (good) cert from Comodo at https://crt.sh/?id=3D36863825

> https://secure.mobihealth.com

https://crt.sh/?id=3D38952224

localityName of Enschede
stateOrProvinceName of 15
countryName of NL

Strangely, this cert had issues from 2013 - 2014 (see https://crt.sh/?id=3D=
734399 https://crt.sh/?id=3D3495854 https://crt.sh/?id=3D5271322 ), briefly=
 fixed the issue (see https://crt.sh/?id=3D9342945 https://crt.sh/?id=3D109=
83769 https://crt.sh/?id=3D12915701 https://crt.sh/?id=3D36254431 ) then we=
nt back to the issue.

It appears the distinction was DigiCert SHA2 Secure Server CA (which does t=
he right thing) and DigiCert High Assurance CA-3 (which does the wrong thin=
g)

> https://portal.mobilitymixx.nl

I'm not sure I understand enough to know what the issues are here. Could yo=
u explain?

> https://mijn.nfu.nl

https://crt.sh/?id=3D41866884

localityName of Utrecht
stateOrProvinceName of 03
countryName of NL

> https://portal.payplaza.com

https://crt.sh/?id=3D106229165

I'm not sure I understand the issues enough to know what's wrong here?
0
Ryan
4/19/2017 7:28:16 PM
On Wed, Apr 19, 2017 at 12:28:16PM -0700, Ryan Sleevi via dev-security-policy wrote:
> > https://portal.mobilitymixx.nl
> 
> I'm not sure I understand enough to know what the issues are here. Could you explain?

Both the localityName and stateOrProvinceName are Almere, while
the province is Flevoland.

What's also confusing is that the owner seems to have changed
from Mobility Mixx B.V. (NL) to Leaseplan Information Services
Limited (IE) and then back to Mobility Mixx B.V. (NL).


> > https://portal.payplaza.com
> 
> https://crt.sh/?id=106229165
> 
> I'm not sure I understand the issues enough to know what's wrong here?

It says "Noord-Holland" instead of "Noord-Brabant".


Kurt

0
Kurt
4/19/2017 7:38:49 PM
Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) valida=
te such data and issues certificates? I am investigation more of them and a=
fraid even linked company names or registration numbers could be false. Sho=
uldn't those certificates be revoked?=20

On Wednesday, 19 April 2017 21:28:26 UTC+2, Ryan Sleevi  wrote:
> On Wednesday, April 19, 2017 at 3:13:36 PM UTC-4, Mike Pasarella wrote:
> > To add some more concerning this issue:
> >=20
> > https://xenapp.alpinvest.com/
>=20
> https://crt.sh/?id=3D42227446
>=20
> localityName of Amsterdam
> stateOrProvinceName of 19
> countryName of NL
>=20
> Problem has existed since 2013 - https://crt.sh/?id=3D6164627

But not solved? Shouldn't this certificate be revoked?

>=20
> > https://adoftheyear.com
>=20
> https://crt.sh/?id=3D55977126
>=20
> localityName of Rotterdam
> stateOrProvinceName of California
> countryName of NL

California is for sure not a province in The Netherlands.=20

>=20
> https://crt.sh/?id=3D5178826 goes back to at least 2014
>=20
> Previous (good) cert from Comodo at https://crt.sh/?id=3D36863825
>=20
> > https://secure.mobihealth.com
>=20
> https://crt.sh/?id=3D38952224
>=20
> localityName of Enschede
> stateOrProvinceName of 15
> countryName of NL
>=20
> Strangely, this cert had issues from 2013 - 2014 (see https://crt.sh/?id=
=3D734399 https://crt.sh/?id=3D3495854 https://crt.sh/?id=3D5271322 ), brie=
fly fixed the issue (see https://crt.sh/?id=3D9342945 https://crt.sh/?id=3D=
10983769 https://crt.sh/?id=3D12915701 https://crt.sh/?id=3D36254431 ) then=
 went back to the issue.
>=20
> It appears the distinction was DigiCert SHA2 Secure Server CA (which does=
 the right thing) and DigiCert High Assurance CA-3 (which does the wrong th=
ing)
>=20
> > https://portal.mobilitymixx.nl
>=20
> I'm not sure I understand enough to know what the issues are here. Could =
you explain?

Almere is a city (which is correct), but not the province.=20
https://en.wikipedia.org/wiki/Almere

>=20
> > https://mijn.nfu.nl
>=20
> https://crt.sh/?id=3D41866884
>=20
> localityName of Utrecht
> stateOrProvinceName of 03
> countryName of NL
>=20
> > https://portal.payplaza.com
>=20
> https://crt.sh/?id=3D106229165
>=20
> I'm not sure I understand the issues enough to know what's wrong here?

Eindhoven is not in the province Noord-Holland. Noord-Brabant (or Brabant) =
should be correct.
0
Mike
4/19/2017 7:47:45 PM
On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan,
>
> My answers on the particular issues are stated inline.
> But the thing I want to address is how could (in this case Digicert)
> validate such data and issues certificates? I am investigation more of them
> and afraid even linked company names or registration numbers could be
> false. Shouldn't those certificates be revoked?
>

You are correct that it appears these certificates should not have issued.
Hopefully Jeremy and Ben from DigiCert can comment on this thread (
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ
for the archive) with details about the issues and the steps taken.
0
Ryan
4/19/2017 8:25:04 PM
------=_NextPart_000_0061_01D2B919.134D9C20
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I=E2=80=99m looking into it right now. I=E2=80=99ll report back shortly. =


=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent <pasarellaphoto@gmail.com>
Cc: mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>; Jeremy Rowley =
<jeremy.rowley@digicert.com>; Ben Wilson <ben.wilson@digicert.com>
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) =
validate such data and issues certificates? I am investigation more of =
them and afraid even linked company names or registration numbers could =
be false. Shouldn't those certificates be revoked?

=20

You are correct that it appears these certificates should not have =
issued. Hopefully Jeremy and Ben from DigiCert can comment on this =
thread ( =
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/i=
g8UmHT2DwAJ for the archive) with details about the issues and the steps =
taken.


------=_NextPart_000_0061_01D2B919.134D9C20
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE5MjAyNzI5WjAj
BgkqhkiG9w0BCQQxFgQUfT6mUV/UkVVRMNHBdv2gPjsX91IwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAISxODM1iS4vW7tfV5stJL4Rgp0fqv5Hck4D1SCT
PAtzyGE14aP3eb90ZmTFaLaJEo5bQxPh2mrhWY72FUz+y92yJuyb93l99qDVxF76KLDsU/BNUa6X
ij3TCPRkNC//87EZPgETHczYY1luVIIxUbLz99hw+0Rbh8yIpONWVQLjZmk/voECDsupOp2qtJ2i
foJLEZe9rG2nZAjIIr2jIB4wSl7hgPKFxZLfgDjJxeq7hVHHPJ+TTCEDYS+3m83zjMyDbFPl6glj
fu3OI27FJeQdTYui+2iNuhfVs1l+5+b507iDZmv/vddF+Op9m2YrHwoCnbtofE5joMd5+pwE9A4A
AAAAAAA=

------=_NextPart_000_0061_01D2B919.134D9C20--
0
Jeremy
4/19/2017 8:27:29 PM
I hope you could investigate it even further as this might be just the begi=
nning.
I just did a random quick lookup so far. And I guess there are over a thous=
and or more Digicert certificates issued for Dutch websites and companies.=
=20

Does this mean the validation process is lacking proper validation or missi=
ng the tools and assets to know where to check for this information? For lo=
cations:

- Maps services from Google
- Wikipedia (although not favourable)=20
- Company registration agencies (kvk in The Netherlands), which already did=
 the address check




On Wednesday, 19 April 2017 22:28:09 UTC+2, Jeremy Rowley  wrote:
> I=E2=80=99m looking into it right now. I=E2=80=99ll report back shortly.=
=20
>=20
> =20
>=20
> Jeremy
>=20
> =20
>=20
> From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
> Sent: Wednesday, April 19, 2017 2:25 PM
> To: Mike vd Ent <pasarellaphoto@gmail.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-security-policy@lists.mozill=
a.org>; Jeremy Rowley <jeremy.rowley@digicert.com>; Ben Wilson <ben.wilson@=
digicert.com>
> Subject: Re: CA Validation quality is failing
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy <dev=
-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozill=
a.org> > wrote:
>=20
> Ryan,
>=20
> My answers on the particular issues are stated inline.
> But the thing I want to address is how could (in this case Digicert) vali=
date such data and issues certificates? I am investigation more of them and=
 afraid even linked company names or registration numbers could be false. S=
houldn't those certificates be revoked?
>=20
> =20
>=20
> You are correct that it appears these certificates should not have issued=
.. Hopefully Jeremy and Ben from DigiCert can comment on this thread ( https=
://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2=
DwAJ for the archive) with details about the issues and the steps taken.

0
Mike
4/19/2017 8:38:38 PM
Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.org>=
 writes:=0A=
=0A=
>Both the localityName and stateOrProvinceName are Almere, while the provin=
ce =0A=
>is Flevoland.=0A=
=0A=
How much checking is a CA expected to do here?  I know that OV and DV certs=
 =0A=
are just "someone at this site responded to email" or whatever, but for an =
=0A=
EV cert how much further does the CA actually have to go?  When e-Szign=F3 =
=0A=
Hiteles=EDt=E9s-Szolg=E1ltat=F3 in Hungary certifies Autolac Car Services, =
Av Los =0A=
Frutales 487 urb., Lima, Peru, are they expected to verify that it's really=
 =0A=
in Av Los Frutales and not Los Tolladores, or do they just go ahead and=0A=
issue the cert?  Can someone point to the bit of the BR that says that this=
=0A=
is obviously right or wrong?=0A=
=0A=
Peter.=
0
Peter
4/19/2017 10:41:33 PM
On Wed, Apr 19, 2017 at 6:41 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.or=
g>
> writes:
>
> >Both the localityName and stateOrProvinceName are Almere, while the
> province
> >is Flevoland.
>
> How much checking is a CA expected to do here?  I know that OV and DV cer=
ts
> are just "someone at this site responded to email" or whatever,


This is not correct. This can be easily answered by
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf

Section 3 governs validation, Section 7 governs the profile of how to use
that validated information


> but for an
> EV cert how much further does the CA actually have to go?  When e-Szign=
=C3=B3
> Hiteles=C3=ADt=C3=A9s-Szolg=C3=A1ltat=C3=B3 in Hungary certifies Autolac =
Car Services, Av Los
> Frutales 487 urb., Lima, Peru, are they expected to verify that it's real=
ly
> in Av Los Frutales and not Los Tolladores, or do they just go ahead and
> issue the cert?  Can someone point to the bit of the BR that says that th=
is
> is obviously right or wrong?
>

For an EV cert, you look in
https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf
0
Ryan
4/19/2017 10:51:07 PM
Hi Peter,

EV requirements are actually dictated by a separate set of guidelines:
https://cabforum.org/extended-validation/

They do go into detail about how to verify applicant information. It covers
how you verify the company is legally established, where its physically
operating, etc. As you can imagine, its quite detailed. Here is a short
excerpt to give you an idea of the wording.

>From Section 11.4.1:

"... the CA MUST confirm that the Applicant's address, as listed in the EV
Certificate Request, is a valid business address for the Applicant or a
Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY
rely on the Applicant's representation that such address is its Place of
Business:"

(QGIS, QIIS, and QTIS are acronyms for different types of authoritative
sources, which the document also defines and details acceptable criteria
for)

-Vince



On Wed, Apr 19, 2017 at 6:41 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.or=
g>
> writes:
>
> >Both the localityName and stateOrProvinceName are Almere, while the
> province
> >is Flevoland.
>
> How much checking is a CA expected to do here?  I know that OV and DV cer=
ts
> are just "someone at this site responded to email" or whatever, but for a=
n
> EV cert how much further does the CA actually have to go?  When e-Szign=
=C3=B3
> Hiteles=C3=ADt=C3=A9s-Szolg=C3=A1ltat=C3=B3 in Hungary certifies Autolac =
Car Services, Av Los
> Frutales 487 urb., Lima, Peru, are they expected to verify that it's real=
ly
> in Av Los Frutales and not Los Tolladores, or do they just go ahead and
> issue the cert?  Can someone point to the bit of the BR that says that th=
is
> is obviously right or wrong?
>
> Peter.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--=20
Vincent Lynch
0
Vincent
4/19/2017 10:53:45 PM
On Wed, Apr 19, 2017 at 10:41:33PM +0000, Peter Gutmann via dev-security-policy wrote:
> Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.org> writes:
> 
> >Both the localityName and stateOrProvinceName are Almere, while the province 
> >is Flevoland.
> 
> How much checking is a CA expected to do here?  I know that OV and DV certs 
> are just "someone at this site responded to email" or whatever, but for an 
> EV cert how much further does the CA actually have to go?

For the EV cert we got we got a phone call asking if she could
speak to someone else to confirm that he works there.

That also wasn't what I expected. I expected that they would at
least check that he has the authority to do so, like asking the
CEO.

(It was a code sign certificate, but I expect if it's labeled EV
that the same things apply.)


Kurt

0
Kurt
4/19/2017 11:53:56 PM
------=_NextPart_000_014A_01D2B936.8C3016A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

That was changed in ballot 127.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
..org] On Behalf Of Kurt Roeckx via dev-security-policy
Sent: Wednesday, April 19, 2017 5:54 PM
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Ryan Sleevi <ryan@sleevi.com>;
mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 10:41:33PM +0000, Peter Gutmann via
dev-security-policy wrote:
> Kurt Roeckx via dev-security-policy
<dev-security-policy@lists.mozilla.org> writes:
> 
> >Both the localityName and stateOrProvinceName are Almere, while the 
> >province is Flevoland.
> 
> How much checking is a CA expected to do here?  I know that OV and DV 
> certs are just "someone at this site responded to email" or whatever, 
> but for an EV cert how much further does the CA actually have to go?

For the EV cert we got we got a phone call asking if she could speak to
someone else to confirm that he works there.

That also wasn't what I expected. I expected that they would at least check
that he has the authority to do so, like asking the CEO.

(It was a code sign certificate, but I expect if it's labeled EV that the
same things apply.)


Kurt

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

------=_NextPart_000_014A_01D2B936.8C3016A0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE5MjM1ODI3WjAj
BgkqhkiG9w0BCQQxFgQUabXqgn6qwgNaLCJJIeC+B0usIscwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAHBP9qrfVQX1ZGWwhcUCFVlAStq+nhlVwdZwwRja
icferRg2dbwbqlhIFIkzmTRazBsddaK0wPpRHOLGMJD6thVEcrjFd3nHcYun0G8Wt/2aO7HVJ/zS
I7kJcehoR+oM3OFPsVRk/EBldNZlSxkh2A3SIxa8DOor4HMGLlSCTDAk0DkrPXw39y+Uhcm3lwyz
dLPtyc2BKrcWi7Kw7WrQQPrQi7AQ92KT7qP37XyBUUY51ntxyywqidsbXn7p46+iXaboTRps9WCn
NWrNF/BHv2pIoArHo38r3lP1Kyuyv6gi3s2BruRjyXBZIR0MVZMmokfJaFG6y5o44E3rDCxiN0QA
AAAAAAA=

------=_NextPart_000_014A_01D2B936.8C3016A0--
0
Jeremy
4/19/2017 11:58:28 PM
On Wed, Apr 19, 2017 at 7:53 PM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> (It was a code sign certificate, but I expect if it's labeled EV
> that the same things apply.)
>

Not necessarily. A separate set of guidelines cover those -
https://cabforum.org/ev-code-signing-certificate-guidelines/

Neither Mozilla nor Google actively participate in the maintenance of those
documents.
0
Ryan
4/20/2017 1:00:22 AM
On Wed, Apr 19, 2017 at 11:58:28PM +0000, Jeremy Rowley wrote:
> That was changed in ballot 127.

Which is adopted in july 2014. This was somewhere in 2016.

As I understood it, they didn't ask for the HR department, just
someone else. That might of course be a misunderstanding of what
was asked, which I guess is the reason for ballot 127.


Kurt

0
Kurt
4/20/2017 1:30:52 AM
On Wed, Apr 19, 2017 at 09:00:22PM -0400, Ryan Sleevi wrote:
> On Wed, Apr 19, 2017 at 7:53 PM, Kurt Roeckx via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > (It was a code sign certificate, but I expect if it's labeled EV
> > that the same things apply.)
> >
> 
> Not necessarily. A separate set of guidelines cover those -
> https://cabforum.org/ev-code-signing-certificate-guidelines/

It really just points to the EV guidelines for the verification
requirments.


Kurt

0
Kurt
4/20/2017 1:36:40 AM
------=_NextPart_000_025A_01D2B945.EDB0BAB0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

FYI - still looking into this. I should have a report tomorrow.=20

-----Original Message-----
From: dev-security-policy =
[mailto:dev-security-policy-bounces+jeremy.rowley=3Ddigicert.com@lists.mo=
zilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Wednesday, April 19, 2017 2:27 PM
To: ryan@sleevi.com; Mike vd Ent <pasarellaphoto@gmail.com>
Cc: Ben Wilson <ben.wilson@digicert.com>; mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

I=E2=80=99m looking into it right now. I=E2=80=99ll report back shortly. =


=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent <pasarellaphoto@gmail.com>
Cc: mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>; Jeremy Rowley =
<jeremy.rowley@digicert.com>; Ben Wilson <ben.wilson@digicert.com>
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) =
validate such data and issues certificates? I am investigation more of =
them and afraid even linked company names or registration numbers could =
be false. Shouldn't those certificates be revoked?

=20

You are correct that it appears these certificates should not have =
issued. Hopefully Jeremy and Ben from DigiCert can comment on this =
thread ( =
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/i=
g8UmHT2DwAJ for the archive) with details about the issues and the steps =
taken.


------=_NextPart_000_025A_01D2B945.EDB0BAB0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDIwMDE0ODMzWjAj
BgkqhkiG9w0BCQQxFgQUeUAlVSYuFL19tFWeV5Z7tGCgxqwwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBABjHsmKK0/WKEZ+MZO1C31B23xFlmJu2F4opQChQ
6mhzo8p2GE29yZ7V4Yn7xt9er7xJZmaG2XbI2quIE7+LdWJelKr0J/xmJn7r9fxt9vichsj6Lydh
LMV2rTwNqirWaVKdWLNgn6WFQXroIApHRD5iDJoexkRBjLXY3KRmyWuI9t/Xojx4Hkx4NNn+Y9/j
2vN88CCPa/lbw1xWC0+ODIG3ajTuw5PT5vOBRCLxPQJSpoRyIA8WyQflxGS51xdfh+bsLWIVsCuB
ePerHtWoLcV0ZddO8jj4luuGnDSfl+muC4qZmrBO9jDc5XxKL7pXgWbecQ701m6R0ctmhoFx6igA
AAAAAAA=

------=_NextPart_000_025A_01D2B945.EDB0BAB0--
0
Jeremy
4/20/2017 1:48:33 AM
Ryan Sleevi <ryan@sleevi.com> writes:=0A=
=0A=
>For an EV cert, you look in=A0https://cabforum.org/wp-content/uploads/EV-V=
1_6_1.pdf       =0A=
=0A=
It was meant as a rhetorical question, the OP asked whether doing XYZ in an=
=0A=
EV certificate was allowed and I was pointing out that the CAB Forum =0A=
guidelines should provide the answer.  Vincent Lynch's reply was the approp=
riate=0A=
one, pointing out the text that covers this situation.=0A=
=0A=
Peter.=0A=
0
Peter
4/20/2017 6:23:58 AM
One thing:

Could this be a result of the common (among CAs) bug of requiring entry
of a US/Canada State/Province regardless of country, forcing applicants
to fill in random data in that field?

On 20/04/2017 03:48, Jeremy Rowley wrote:
> FYI - still looking into this. I should have a report tomorrow.
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Wednesday, April 19, 2017 2:27 PM
> To: ryan@sleevi.com; Mike vd Ent <pasarellaphoto@gmail.com>
> Cc: Ben Wilson <ben.wilson@digicert.com>; mozilla-dev-security-policy <mozilla-dev-security-policy@lists.mozilla.org>
> Subject: RE: CA Validation quality is failing
>
> I’m looking into it right now. I’ll report back shortly.
>
>
>
> Jeremy
>
>
>
> From: Ryan Sleevi [mailto:ryan@sleevi.com]
> Sent: Wednesday, April 19, 2017 2:25 PM
> To: Mike vd Ent <pasarellaphoto@gmail.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-security-policy@lists.mozilla.org>; Jeremy Rowley <jeremy.rowley@digicert.com>; Ben Wilson <ben.wilson@digicert.com>
> Subject: Re: CA Validation quality is failing
>
>
>
>
>
>
>
> On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote:
>
> Ryan,
>
> My answers on the particular issues are stated inline.
> But the thing I want to address is how could (in this case Digicert) validate such data and issues certificates? I am investigation more of them and afraid even linked company names or registration numbers could be false. Shouldn't those certificates be revoked?
>
>
>
> You are correct that it appears these certificates should not have issued. Hopefully Jeremy and Ben from DigiCert can comment on this thread ( https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ for the archive) with details about the issues and the steps taken.
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0
Jakob
4/20/2017 10:42:22 AM
On Thu, Apr 20, 2017 at 6:42 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> One thing:
>
> Could this be a result of the common (among CAs) bug of requiring entry
> of a US/Canada State/Province regardless of country, forcing applicants
> to fill in random data in that field?


That Is not common among CAs, because it's not how certificate information
is validated. Perhaps it would be best if you just waited for Jeremy to
respond, rather than attempting to speculate about the system. I appreciate
the eagerness to find answers, but those sorts of speculation don't really
help much.
0
Ryan
4/20/2017 12:50:35 PM
------=_NextPart_000_03CA_01D2BA01.65078150
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Thanks Mike for bringing this up. We=E2=80=99ve looked into it and have =
an initial report to share.

After receiving the email on the Mozilla list, we investigated the =
identified certificates and discovered a couple of very related issues =
in our process that led to certificates with bad info:
1. As Jakob pointed out, part of the issue was that our intake form =
required a state if US was selected. As country is the last requested =
field, the state only became optional after the customer completed the =
rest of the form. This led to a lot of customers submitting bad data. =20
2. We have an old tool that generates information based on a =
customer=E2=80=99s location. This tool helps customers create CSRs and =
complete certificate requests. The tool inserts bad data into some =
fields if the field is left blank by the customer. The result was =
customers using this tool outside of the US had numbers included in the =
state field. =20
3.  There was a gap in our validation process. This is the more =
important issue as the validation process should have caught the bad =
data inserted by the other two issues. Although we are obtaining =
validation documents from the appropriate government entity, the data =
submitted via the tool or intake form was not properly being updated =
with retrieved validated information. The end result was that the bad =
CSR data was submitted for signing instead of the data listed on the =
government document. This was a personnel problem, not a failure in our =
system as the validation staff was not appropriately updating the =
required signing fields.

So far, we have identified approximately 600 certificates that have the =
wrong state, zip, or locality. This is just a measurement of the problem =
scope and not the exact number as we are still reviewing are certificate =
database using a mapping API to determine whether the address exists. We =
expect the search to have a lot of false positives initially but provide =
a maximum scope of the problem. In parallel, we are contacting each =
customer with a non-compliant certificate, replacing the certificate, =
and revoking the certificate.  All mis-matched certificates are being =
uploaded to the Google and DigiCert CT logs.=20

To fix our process, we are planning the following:
a.  We are immediately deprecating our geolocation tool and updating our =
intake form to help reduce the amount of bad data.=20
b. We are updating our validation process to flag the differences in =
validation data and customer-provided data.=20
c. We are providing our validation staff with an extra mandatory tool =
that checks address information for accuracy. Part of our process going =
forward will be to use a separate source to verify that the city/state =
are actually in the country specified by the certificate. =20
4.  Finally, we are implementing additional restrictions on our CA that =
prohibit signing of bad locality/state/zip information. We have a tool =
internally named =E2=80=9Ccert shield=E2=80=9D. This tool is similar to =
CAB lint and that checks information submitted to the CA for compliance =
with the BRs and EV Guidelines. The rule set in cert shield is being =
updated to include additional restrictions designed to catch issues like =
numeric states and cities.

I=E2=80=99ll report back more on our progress next week with additional =
ideas. Please let me know if you have any questions.

Jeremy

-----Original Message-----
From: Jeremy Rowley=20
Sent: Wednesday, April 19, 2017 7:49 PM
To: Jeremy Rowley <jeremy.rowley@digicert.com>; ryan@sleevi.com; Mike vd =
Ent <pasarellaphoto@gmail.com>
Cc: Ben Wilson <ben.wilson@digicert.com>; mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

FYI - still looking into this. I should have a report tomorrow.=20

-----Original Message-----
From: dev-security-policy =
[mailto:dev-security-policy-bounces+jeremy.rowley=3Ddigicert.com@lists.mo=
zilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Wednesday, April 19, 2017 2:27 PM
To: ryan@sleevi.com; Mike vd Ent <pasarellaphoto@gmail.com>
Cc: Ben Wilson <ben.wilson@digicert.com>; mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

I=E2=80=99m looking into it right now. I=E2=80=99ll report back shortly. =


=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent <pasarellaphoto@gmail.com>
Cc: mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>; Jeremy Rowley =
<jeremy.rowley@digicert.com>; Ben Wilson <ben.wilson@digicert.com>
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) =
validate such data and issues certificates? I am investigation more of =
them and afraid even linked company names or registration numbers could =
be false. Shouldn't those certificates be revoked?

=20

You are correct that it appears these certificates should not have =
issued. Hopefully Jeremy and Ben from DigiCert can comment on this =
thread ( =
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/i=
g8UmHT2DwAJ for the archive) with details about the issues and the steps =
taken.


------=_NextPart_000_03CA_01D2BA01.65078150
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDIxMDAxMDI5WjAj
BgkqhkiG9w0BCQQxFgQUS8UQrRW+nCz6u1ZIy1JPSWiRakgwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBANChIiOI+PJx2TmtG/MZXQjHxsPS7s8382h2e9at
mEVB790NJOvfOZOt4hpgzM9Y/5/I1DwxEzP3CED2Iq66YCgmE3nkqooQFg8xChOGbCE8jV8Elv+d
kbf6AmoJyQcy60V4djb4oWZtM8sJTlBKmtAKS+0Wb2/H6hkCdS4hgFKvTEqOyFzCZuwdfEhY0ncn
WEaXr+nGA/2QYmSjwzgIr8Cy1Vco0GAARP+ALz5zBCwgXDsIyMJ7KA0cN8AohOhY0St/k3XZsEZ0
53rABiZGUCNLGc+ZwlxkTCTfaAd7ISArwa3ew4ny4ZlLwy0jCsyQNYrmX4JVQ20VxM7JZOzvfLAA
AAAAAAA=

------=_NextPart_000_03CA_01D2BA01.65078150--
0
Jeremy
4/21/2017 12:10:31 AM
------=_NextPart_000_018C_01D2BEB0.CB82BC70
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Status Update:=20

We are still scanning our database to discover all certificates =
containing incorrect data. So far, the count is at 1510.  The issues =
fall into two categories: 1) a failure to properly convey that BRs =
prohibit inclusion of meta data (BR 7.1.4.2.2.j) and 2) auto-population =
of data in the order that validation forgot to clear before issuing the =
certificate.=20

On the training issue, the validation team inserted characters like "-", =
"." or other similar information in approximately 1000 certificates. =
This information asserted that the field was not applicable. The =
remaining 500 included auto-population data. The auto-population took =
three formats (such as a number representing the country code) depending =
on the customer's location and access to our certificate management =
platform. Interestingly, the validation database contains the correct =
documentation. However, we failed to properly update the certificate =
information to match the validated data.

Since Mike reported the issue, we've patched our system to prevent =
meta-data and made substantial improvements to the validation process. =
These improvements help identify mis-matches between validation =
information and certificate data.

We also started the revocation process for the 500 certificates =
containing meta-data. However, we wanted to ask about the 1000 =
certificates containing data indicating the field was not applicable. We =
recognize these were not properly issued, but I am curious whether =
revocation is required by Mozilla in this case. Should we start revoking =
those certificates as well despite the certificate information clearly =
not indicating a state/province? My thought is yes because of BR =
4.9.1.1:

9. The CA is made aware that the Certificate was not issued in =
accordance with these Requirements or the
CA=E2=80=99s Certificate Policy or Certification Practice Statement;

I don't think #10 applies because the information is accurate - the =
field is not applicable:
10. The CA determines that any of the information appearing in the =
Certificate is inaccurate or misleading;

Thoughts?=20

Jeremy


-----Original Message-----
From: dev-security-policy =
[mailto:dev-security-policy-bounces+jeremy.rowley=3Ddigicert.com@lists.mo=
zilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, April 20, 2017 6:11 PM
To: mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

Thanks Mike for bringing this up. We=E2=80=99ve looked into it and have =
an initial report to share.

After receiving the email on the Mozilla list, we investigated the =
identified certificates and discovered a couple of very related issues =
in our process that led to certificates with bad info:
1. As Jakob pointed out, part of the issue was that our intake form =
required a state if US was selected. As country is the last requested =
field, the state only became optional after the customer completed the =
rest of the form. This led to a lot of customers submitting bad data. =20
2. We have an old tool that generates information based on a =
customer=E2=80=99s location. This tool helps customers create CSRs and =
complete certificate requests. The tool inserts bad data into some =
fields if the field is left blank by the customer. The result was =
customers using this tool outside of the US had numbers included in the =
state field. =20
3.  There was a gap in our validation process. This is the more =
important issue as the validation process should have caught the bad =
data inserted by the other two issues. Although we are obtaining =
validation documents from the appropriate government entity, the data =
submitted via the tool or intake form was not properly being updated =
with retrieved validated information. The end result was that the bad =
CSR data was submitted for signing instead of the data listed on the =
government document. This was a personnel problem, not a failure in our =
system as the validation staff was not appropriately updating the =
required signing fields.

So far, we have identified approximately 600 certificates that have the =
wrong state, zip, or locality. This is just a measurement of the problem =
scope and not the exact number as we are still reviewing are certificate =
database using a mapping API to determine whether the address exists. We =
expect the search to have a lot of false positives initially but provide =
a maximum scope of the problem. In parallel, we are contacting each =
customer with a non-compliant certificate, replacing the certificate, =
and revoking the certificate.  All mis-matched certificates are being =
uploaded to the Google and DigiCert CT logs.=20

To fix our process, we are planning the following:
a.  We are immediately deprecating our geolocation tool and updating our =
intake form to help reduce the amount of bad data.=20
b. We are updating our validation process to flag the differences in =
validation data and customer-provided data.=20
c. We are providing our validation staff with an extra mandatory tool =
that checks address information for accuracy. Part of our process going =
forward will be to use a separate source to verify that the city/state =
are actually in the country specified by the certificate. =20
4.  Finally, we are implementing additional restrictions on our CA that =
prohibit signing of bad locality/state/zip information. We have a tool =
internally named =E2=80=9Ccert shield=E2=80=9D. This tool is similar to =
CAB lint and that checks information submitted to the CA for compliance =
with the BRs and EV Guidelines. The rule set in cert shield is being =
updated to include additional restrictions designed to catch issues like =
numeric states and cities.

I=E2=80=99ll report back more on our progress next week with additional =
ideas. Please let me know if you have any questions.

Jeremy

-----Original Message-----
From: Jeremy Rowley=20
Sent: Wednesday, April 19, 2017 7:49 PM
To: Jeremy Rowley <jeremy.rowley@digicert.com>; ryan@sleevi.com; Mike vd =
Ent <pasarellaphoto@gmail.com>
Cc: Ben Wilson <ben.wilson@digicert.com>; mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

FYI - still looking into this. I should have a report tomorrow.=20

-----Original Message-----
From: dev-security-policy =
[mailto:dev-security-policy-bounces+jeremy.rowley=3Ddigicert.com@lists.mo=
zilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Wednesday, April 19, 2017 2:27 PM
To: ryan@sleevi.com; Mike vd Ent <pasarellaphoto@gmail.com>
Cc: Ben Wilson <ben.wilson@digicert.com>; mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

I=E2=80=99m looking into it right now. I=E2=80=99ll report back shortly. =


=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent <pasarellaphoto@gmail.com>
Cc: mozilla-dev-security-policy =
<mozilla-dev-security-policy@lists.mozilla.org>; Jeremy Rowley =
<jeremy.rowley@digicert.com>; Ben Wilson <ben.wilson@digicert.com>
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) =
validate such data and issues certificates? I am investigation more of =
them and afraid even linked company names or registration numbers could =
be false. Shouldn't those certificates be revoked?

=20

You are correct that it appears these certificates should not have =
issued. Hopefully Jeremy and Ben from DigiCert can comment on this =
thread ( =
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/i=
g8UmHT2DwAJ for the archive) with details about the issues and the steps =
taken.


------=_NextPart_000_018C_01D2BEB0.CB82BC70
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDI2MjMxNjA4WjAj
BgkqhkiG9w0BCQQxFgQUZP/mXHULTxr0lYOTctfV7AveevMwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGpwUYngxgwlGJdIWg7xO7eEOi7wzHTylRcWsCTJ
v4JL0mBqdzG2wKBNsLwBJiyr0GIP3h0VCKo3RRXNVl4W9ysh5pK1/+uNxWpO5aZHhjkOMBVQiYn+
OHX34PJD0708GksNbjxfAY+6oC3Vd3Fr1aKUKRnXStu5WiVZZWSr+Qcqr0cl9DgAesmyiuHAEzzF
VpFYVAM/uq57iZuaZJYEAi3G5Plgddhtm9S8jRERDnC2CU+dLj0xdHWJ/Lo0uQDVmd6VM58xVEk1
gA0Jc536YefsrxO1uac0E6hI7SJpajrh5A/ZivaKumotfUgzI3Dxv+uWktk8kdqZkk6CuAA8a20A
AAAAAAA=

------=_NextPart_000_018C_01D2BEB0.CB82BC70--
0
Jeremy
4/26/2017 11:16:09 PM
On 27/04/17 00:16, Jeremy Rowley wrote:
> We also started the revocation process for the 500 certificates
> containing meta-data. However, we wanted to ask about the 1000
> certificates containing data indicating the field was not applicable.
> We recognize these were not properly issued, but I am curious whether
> revocation is required by Mozilla in this case. Should we start
> revoking those certificates as well despite the certificate
> information clearly not indicating a state/province? My thought is
> yes because of BR 4.9.1.1:
> 
> 9. The CA is made aware that the Certificate was not issued in
> accordance with these Requirements or the CA’s Certificate Policy or
> Certification Practice Statement;

What line in your CP or CPS is violated by these certs?

> I don't think #10 applies because the information is accurate - the
> field is not applicable: 10. The CA determines that any of the
> information appearing in the Certificate is inaccurate or
> misleading;

I agree that a "." or "-" instead of a field being empty is not
inaccurate or misleading. However, #10 also says "the CA determines", so
it's your view, not mine, which is most relevant :-)

Gerv
0
Gervase
4/27/2017 8:41:03 AM
------=_NextPart_000_004D_01D2C280.97036430
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

There isn't anything in our CPS directly. However, we state that we =
follow the baseline requirements in the CPS. The baseline requirements =
give a profile for the state field. We weren't sure this was strictly =
followed.=20

We finished our validation review over the weekend.   There are about =
3000 older certs with information indicating a field was not applicable =
(such as a "-", "N/A", etc). On top of this, we issued about 1000 =
certificates with mismatched validation information. The mismatched =
information can be divided into about 850 certificates with numbers in =
the state field. These numbers indicate a location code that was =
provided by the auto-populator.  The remaining 150 are certificates with =
"Select", a state, or a postal code improperly included in the =
certificate.  The root issue was a combination of the auto-populator =
inserting incorrect data into the cert request and our validation staff =
not properly updating the certificate information after completing the =
validation process.=20

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate =
order generators.=20
2. We already blocked this information on the CA side from included in =
signed SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.=20
4. We plan to let the remaining 3850 expire normally but will correct =
the certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 =
certificates because the information isn't misleading, the information =
is accurate, and there isn't a risk posed to Mozilla's users by =
inclusion of the numeric location code or not applicable indicator. Any =
thoughts?

Jeremy



-----Original Message-----
From: Gervase Markham [mailto:gerv@mozilla.org]=20
Sent: Thursday, April 27, 2017 2:41 AM
To: Jeremy Rowley <jeremy.rowley@digicert.com>; =
mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On 27/04/17 00:16, Jeremy Rowley wrote:
> We also started the revocation process for the 500 certificates=20
> containing meta-data. However, we wanted to ask about the 1000=20
> certificates containing data indicating the field was not applicable.
> We recognize these were not properly issued, but I am curious whether=20
> revocation is required by Mozilla in this case. Should we start=20
> revoking those certificates as well despite the certificate=20
> information clearly not indicating a state/province? My thought is yes =

> because of BR 4.9.1.1:
>=20
> 9. The CA is made aware that the Certificate was not issued in=20
> accordance with these Requirements or the CA=E2=80=99s Certificate =
Policy or=20
> Certification Practice Statement;

What line in your CP or CPS is violated by these certs?

> I don't think #10 applies because the information is accurate - the=20
> field is not applicable: 10. The CA determines that any of the=20
> information appearing in the Certificate is inaccurate or misleading;

I agree that a "." or "-" instead of a field being empty is not =
inaccurate or misleading. However, #10 also says "the CA determines", so =
it's your view, not mine, which is most relevant :-)

Gerv

------=_NextPart_000_004D_01D2C280.97036430
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTAxMTk0MTA5WjAj
BgkqhkiG9w0BCQQxFgQU1+yJzutprUj1uR5TnD5YG0HXi4AwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAFzY4KdQciz9iZF+9bq9zcFyG6lJjUy9rvmbbeiB
YFVtTDlnW/lE6Cyzg0Sy4IgKTsltQCyyG3u4Oeq4c/Sr93EOZcec2PUJ4mFmh/35UpsUxIizoYmJ
8xj7e0h1T2+x5X1UqzWPuaIttgez0aLC76BR1WULLCpNzqJml+n3R/RYsNMc8XJw2LSq0JJnJDOp
KszYV6y9PbwHxrqreOY0DhhivTcNKG4SvyRpGm/OpkdUxggs32uCbt88Y8M5EipeCxv/srpiG+Fj
TPbMIr8tArUmGatwJbGAstdYz2uTfD6yQHvgihW44PGM0l6pRoG32GC3HQiVejqBovzqTUelsYMA
AAAAAAA=

------=_NextPart_000_004D_01D2C280.97036430--
0
Jeremy
5/1/2017 7:41:09 PM
On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> There isn't anything in our CPS directly. However, we state that we follow
> the baseline requirements in the CPS. The baseline requirements give a
> profile for the state field. We weren't sure this was strictly followed.
>
> We finished our validation review over the weekend.   There are about 3000
> older certs with information indicating a field was not applicable (such as
> a "-", "N/A", etc). On top of this, we issued about 1000 certificates with
> mismatched validation information. The mismatched information can be
> divided into about 850 certificates with numbers in the state field. These
> numbers indicate a location code that was provided by the auto-populator.
> The remaining 150 are certificates with "Select", a state, or a postal code
> improperly included in the certificate.  The root issue was a combination
> of the auto-populator inserting incorrect data into the cert request and
> our validation staff not properly updating the certificate information
> after completing the validation process.
>
> Based on these results, we propose the following remediation plan:
> 1. We already removed the auto-populator from our CSR and certificate
> order generators.
> 2. We already blocked this information on the CA side from included in
> signed SSL/TLS objects.
> 3. We will revoke the 150 certificates with mismatched information.
> 4. We plan to let the remaining 3850 expire normally but will correct the
> certificate for all future orders (including rekeys).
>
> Is this an acceptable plan? We are proposing not revoking the 3850
> certificates because the information isn't misleading, the information is
> accurate, and there isn't a risk posed to Mozilla's users by inclusion of
> the numeric location code or not applicable indicator. Any thoughts?
>

(With a Google hat on)

Jeremy,

I think with the information you've shared so far, that sounds like a
reasonable plan from Google's perspective for the 3000 certificates. I
think there's at least a little concern about the EV nature for the 850
side, but just trying to understand more here what the implications would
be. Is this exclusively the state, or does it also extend to the
jurisdiction* fields? Or is this only for EV?

Would you be able to share a spreadsheet or details for those, in the
spirit of transparency? I think if you can share those details, it's
reasonable to avoid revoking, and anything specific that might represent a
security/compat risk to an Application Software Supplier (i.e. 4.9.1.1(15)
), we can look into separately.

Thank you for
1) Disclosing the details to a sufficient level of detail immediately
2) Providing regular updates and continued investigation
3) Confirming the acceptability of the plan before implementing it, and
with sufficient detail to understand the implications

These are several of the factors we weighed when considering the
implications/risk of not revoking.
0
Ryan
5/1/2017 11:01:27 PM
------=_NextPart_000_00FA_01D2C2C5.6C3DA1D0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Certainly happy to share more info. The search was for all EV and OV =
certs. Of the 4000 certificates detected, 101 certificates are EV. Of =
these EV certificates, 17 would be included in the proposed revocation. =
The rest have the =E2=80=9CN/A=E2=80=9D issue. This is just the =
locality/state/zip. The jurisdiction of incorporation processes =
separately and doesn=E2=80=99t have the same auto-populate tool.

=20

More info:

78 certs had non-US states populated with US states (thanks to the =
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

=20

What else would you like to know?

=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.rowley@digicert.com>
Cc: Gervase Markham <gerv@mozilla.org>; =
mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we =
follow the baseline requirements in the CPS. The baseline requirements =
give a profile for the state field. We weren't sure this was strictly =
followed.

We finished our validation review over the weekend.   There are about =
3000 older certs with information indicating a field was not applicable =
(such as a "-", "N/A", etc). On top of this, we issued about 1000 =
certificates with mismatched validation information. The mismatched =
information can be divided into about 850 certificates with numbers in =
the state field. These numbers indicate a location code that was =
provided by the auto-populator.  The remaining 150 are certificates with =
"Select", a state, or a postal code improperly included in the =
certificate.  The root issue was a combination of the auto-populator =
inserting incorrect data into the cert request and our validation staff =
not properly updating the certificate information after completing the =
validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate =
order generators.
2. We already blocked this information on the CA side from included in =
signed SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct =
the certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 =
certificates because the information isn't misleading, the information =
is accurate, and there isn't a risk posed to Mozilla's users by =
inclusion of the numeric location code or not applicable indicator. Any =
thoughts?

=20

(With a Google hat on)

=20

Jeremy,

=20

I think with the information you've shared so far, that sounds like a =
reasonable plan from Google's perspective for the 3000 certificates. I =
think there's at least a little concern about the EV nature for the 850 =
side, but just trying to understand more here what the implications =
would be. Is this exclusively the state, or does it also extend to the =
jurisdiction* fields? Or is this only for EV?

=20

Would you be able to share a spreadsheet or details for those, in the =
spirit of transparency? I think if you can share those details, it's =
reasonable to avoid revoking, and anything specific that might represent =
a security/compat risk to an Application Software Supplier (i.e. =
4.9.1.1(15) ), we can look into separately.

=20

Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and =
with sufficient detail to understand the implications

=20

These are several of the factors we weighed when considering the =
implications/risk of not revoking.

=20


------=_NextPart_000_00FA_01D2C2C5.6C3DA1D0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTAyMDM1MzUyWjAj
BgkqhkiG9w0BCQQxFgQUESaZB672AuM369nF++4kiUbZnXAwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAF7+f3NWL+LPetJN+YzbmGYBvQ//kj8GeJeUurLG
H4KJZfyiipjVFLG3rWnnVagvXUXB0StYlmrd8tE0yt3vol0cZHhHw+BvJcfXTWceF8guu8vANRFb
7vmGcIJ/hm74MpTBUGly710DBIj9086e2ejJ6FZssasOAadGR/HFntu4KOq6lrf+WRVzO4vl6LXb
dEifCXFf+N1bsvnGKwO8xOwgHUxExF8ZIUmeAmtFZ2yl13ZJAiA1It/FpEqb2BrP3PzDJ4TQnj/z
+i21r8jVfRffPq82jFmFkFff7E4ZYfZJ5J876cgkAc0lD3OSzhjk7WDJBYO8CqUcZ8uwwvJL4SEA
AAAAAAA=

------=_NextPart_000_00FA_01D2C2C5.6C3DA1D0--
0
Jeremy
5/2/2017 3:53:54 AM
On 02/05/17 00:01, Ryan Sleevi wrote:
> Thank you for
> 1) Disclosing the details to a sufficient level of detail immediately
> 2) Providing regular updates and continued investigation
> 3) Confirming the acceptability of the plan before implementing it, and
> with sufficient detail to understand the implications

I echo Ryan's comments here. I'm happy with your remediation plan, and
think there's enough wiggle room in the BRs and Mozilla policy that
revocation of the certs with "N/A" etc. is avoidable.

I still think we need to address that 24-hour revocation requirement to
be a bit more nuanced, but that's a separate discussion :-)

Gerv

0
Gervase
5/2/2017 10:54:31 AM
(Still wearing Google Hat in this context)

I think sharing a list (in CT) of the certs is good and can help verify the
assertions made here :)

But overall, I think this sounds right and the risk is minimal to our
users, so not revoking still sounds good :)

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley <jeremy.rowley@digicert.com>
wrote:

> Certainly happy to share more info. The search was for all EV and OV
> certs. Of the 4000 certificates detected, 101 certificates are EV. Of the=
se
> EV certificates, 17 would be included in the proposed revocation. The res=
t
> have the =E2=80=9CN/A=E2=80=9D issue. This is just the locality/state/zip=
.. The jurisdiction
> of incorporation processes separately and doesn=E2=80=99t have the same
> auto-populate tool.
>
>
>
> More info:
>
> 78 certs had non-US states populated with US states (thanks to the
> auto-populator)
>
> 791 entities are affected by the entire range of certificates
>
> 257 entities are affected if we revoke the 1033 certs
>
> 82 entities are affected if we revoke just the 150 certs
>
>
>
> What else would you like to know?
>
>
>
> Jeremy
>
>
>
> *From:* Ryan Sleevi [mailto:ryan@sleevi.com]
> *Sent:* Monday, May 1, 2017 5:01 PM
> *To:* Jeremy Rowley <jeremy.rowley@digicert.com>
> *Cc:* Gervase Markham <gerv@mozilla.org>; mozilla-dev-security-policy@
> lists.mozilla.org
> *Subject:* Re: CA Validation quality is failing
>
>
>
>
>
>
>
> On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> There isn't anything in our CPS directly. However, we state that we follo=
w
> the baseline requirements in the CPS. The baseline requirements give a
> profile for the state field. We weren't sure this was strictly followed.
>
> We finished our validation review over the weekend.   There are about 300=
0
> older certs with information indicating a field was not applicable (such =
as
> a "-", "N/A", etc). On top of this, we issued about 1000 certificates wit=
h
> mismatched validation information. The mismatched information can be
> divided into about 850 certificates with numbers in the state field. Thes=
e
> numbers indicate a location code that was provided by the auto-populator.
> The remaining 150 are certificates with "Select", a state, or a postal co=
de
> improperly included in the certificate.  The root issue was a combination
> of the auto-populator inserting incorrect data into the cert request and
> our validation staff not properly updating the certificate information
> after completing the validation process.
>
> Based on these results, we propose the following remediation plan:
> 1. We already removed the auto-populator from our CSR and certificate
> order generators.
> 2. We already blocked this information on the CA side from included in
> signed SSL/TLS objects.
> 3. We will revoke the 150 certificates with mismatched information.
> 4. We plan to let the remaining 3850 expire normally but will correct the
> certificate for all future orders (including rekeys).
>
> Is this an acceptable plan? We are proposing not revoking the 3850
> certificates because the information isn't misleading, the information is
> accurate, and there isn't a risk posed to Mozilla's users by inclusion of
> the numeric location code or not applicable indicator. Any thoughts?
>
>
>
> (With a Google hat on)
>
>
>
> Jeremy,
>
>
>
> I think with the information you've shared so far, that sounds like a
> reasonable plan from Google's perspective for the 3000 certificates. I
> think there's at least a little concern about the EV nature for the 850
> side, but just trying to understand more here what the implications would
> be. Is this exclusively the state, or does it also extend to the
> jurisdiction* fields? Or is this only for EV?
>
>
>
> Would you be able to share a spreadsheet or details for those, in the
> spirit of transparency? I think if you can share those details, it's
> reasonable to avoid revoking, and anything specific that might represent =
a
> security/compat risk to an Application Software Supplier (i.e. 4.9.1.1(15=
)
> ), we can look into separately.
>
>
>
> Thank you for
>
> 1) Disclosing the details to a sufficient level of detail immediately
>
> 2) Providing regular updates and continued investigation
>
> 3) Confirming the acceptability of the plan before implementing it, and
> with sufficient detail to understand the implications
>
>
>
> These are several of the factors we weighed when considering the
> implications/risk of not revoking.
>
>
>
0
Ryan
5/2/2017 3:07:41 PM
I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of these cases, it'd be great to add them as a technical means for
ensuring that this doesn't regress -- things like N/A should be an easy
enough check to add I'd think.

Cheers,
Alex

On Tue, May 2, 2017 at 11:07 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> (Still wearing Google Hat in this context)
>
> I think sharing a list (in CT) of the certs is good and can help verify t=
he
> assertions made here :)
>
> But overall, I think this sounds right and the risk is minimal to our
> users, so not revoking still sounds good :)
>
> On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley <jeremy.rowley@digicert.co=
m
> >
> wrote:
>
> > Certainly happy to share more info. The search was for all EV and OV
> > certs. Of the 4000 certificates detected, 101 certificates are EV. Of
> these
> > EV certificates, 17 would be included in the proposed revocation. The
> rest
> > have the =E2=80=9CN/A=E2=80=9D issue. This is just the locality/state/z=
ip. The
> jurisdiction
> > of incorporation processes separately and doesn=E2=80=99t have the same
> > auto-populate tool.
> >
> >
> >
> > More info:
> >
> > 78 certs had non-US states populated with US states (thanks to the
> > auto-populator)
> >
> > 791 entities are affected by the entire range of certificates
> >
> > 257 entities are affected if we revoke the 1033 certs
> >
> > 82 entities are affected if we revoke just the 150 certs
> >
> >
> >
> > What else would you like to know?
> >
> >
> >
> > Jeremy
> >
> >
> >
> > *From:* Ryan Sleevi [mailto:ryan@sleevi.com]
> > *Sent:* Monday, May 1, 2017 5:01 PM
> > *To:* Jeremy Rowley <jeremy.rowley@digicert.com>
> > *Cc:* Gervase Markham <gerv@mozilla.org>; mozilla-dev-security-policy@
> > lists.mozilla.org
> > *Subject:* Re: CA Validation quality is failing
> >
> >
> >
> >
> >
> >
> >
> > On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > There isn't anything in our CPS directly. However, we state that we
> follow
> > the baseline requirements in the CPS. The baseline requirements give a
> > profile for the state field. We weren't sure this was strictly followed=
..
> >
> > We finished our validation review over the weekend.   There are about
> 3000
> > older certs with information indicating a field was not applicable (suc=
h
> as
> > a "-", "N/A", etc). On top of this, we issued about 1000 certificates
> with
> > mismatched validation information. The mismatched information can be
> > divided into about 850 certificates with numbers in the state field.
> These
> > numbers indicate a location code that was provided by the auto-populato=
r.
> > The remaining 150 are certificates with "Select", a state, or a postal
> code
> > improperly included in the certificate.  The root issue was a combinati=
on
> > of the auto-populator inserting incorrect data into the cert request an=
d
> > our validation staff not properly updating the certificate information
> > after completing the validation process.
> >
> > Based on these results, we propose the following remediation plan:
> > 1. We already removed the auto-populator from our CSR and certificate
> > order generators.
> > 2. We already blocked this information on the CA side from included in
> > signed SSL/TLS objects.
> > 3. We will revoke the 150 certificates with mismatched information.
> > 4. We plan to let the remaining 3850 expire normally but will correct t=
he
> > certificate for all future orders (including rekeys).
> >
> > Is this an acceptable plan? We are proposing not revoking the 3850
> > certificates because the information isn't misleading, the information =
is
> > accurate, and there isn't a risk posed to Mozilla's users by inclusion =
of
> > the numeric location code or not applicable indicator. Any thoughts?
> >
> >
> >
> > (With a Google hat on)
> >
> >
> >
> > Jeremy,
> >
> >
> >
> > I think with the information you've shared so far, that sounds like a
> > reasonable plan from Google's perspective for the 3000 certificates. I
> > think there's at least a little concern about the EV nature for the 850
> > side, but just trying to understand more here what the implications wou=
ld
> > be. Is this exclusively the state, or does it also extend to the
> > jurisdiction* fields? Or is this only for EV?
> >
> >
> >
> > Would you be able to share a spreadsheet or details for those, in the
> > spirit of transparency? I think if you can share those details, it's
> > reasonable to avoid revoking, and anything specific that might represen=
t
> a
> > security/compat risk to an Application Software Supplier (i.e.
> 4.9.1.1(15)
> > ), we can look into separately.
> >
> >
> >
> > Thank you for
> >
> > 1) Disclosing the details to a sufficient level of detail immediately
> >
> > 2) Providing regular updates and continued investigation
> >
> > 3) Confirming the acceptability of the plan before implementing it, and
> > with sufficient detail to understand the implications
> >
> >
> >
> > These are several of the factors we weighed when considering the
> > implications/risk of not revoking.
> >
> >
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
0
Alex
5/2/2017 3:11:05 PM
On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:
> I know several CAs are using certlint (https://github.com/awslabs/certlint)
> as a pre-issuance check that the cert they're about to issue doesn't have
> any programmatically detectable deficiencies; if it doesn't already cover
> some of these cases, it'd be great to add them as a technical means for
> ensuring that this doesn't regress -- things like N/A should be an easy
> enough check to add I'd think.

Simple project idea (perhaps for https://github.com/cabforum):

A CSV file that contains 2 items per line:
1. An optional comma-separated list of Subject attribute shortnames.
2. A string that a CA should probably not encode as a complete Subject 
attribute.

e.g.,
"OU,ST,L","N/A"
,"."
"O","Internet Widgits Pty Ltd"

Anyone (CA representatives, industry researchers, etc, etc) would be 
able to submit PRs, CAs would be invited to consult this list when 
evaluating certificate requests, and certlint would be able to report on 
"violations".

> Cheers,
> Alex
>
> On Tue, May 2, 2017 at 11:07 AM, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> (Still wearing Google Hat in this context)
>>
>> I think sharing a list (in CT) of the certs is good and can help verify the
>> assertions made here :)
>>
>> But overall, I think this sounds right and the risk is minimal to our
>> users, so not revoking still sounds good :)
>>
>> On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley <jeremy.rowley@digicert.com
>>>
>> wrote:
>>
>>> Certainly happy to share more info. The search was for all EV and OV
>>> certs. Of the 4000 certificates detected, 101 certificates are EV. Of
>> these
>>> EV certificates, 17 would be included in the proposed revocation. The
>> rest
>>> have the “N/A” issue. This is just the locality/state/zip. The
>> jurisdiction
>>> of incorporation processes separately and doesn’t have the same
>>> auto-populate tool.
>>>
>>>
>>>
>>> More info:
>>>
>>> 78 certs had non-US states populated with US states (thanks to the
>>> auto-populator)
>>>
>>> 791 entities are affected by the entire range of certificates
>>>
>>> 257 entities are affected if we revoke the 1033 certs
>>>
>>> 82 entities are affected if we revoke just the 150 certs
>>>
>>>
>>>
>>> What else would you like to know?
>>>
>>>
>>>
>>> Jeremy
>>>
>>>
>>>
>>> *From:* Ryan Sleevi [mailto:ryan@sleevi.com]
>>> *Sent:* Monday, May 1, 2017 5:01 PM
>>> *To:* Jeremy Rowley <jeremy.rowley@digicert.com>
>>> *Cc:* Gervase Markham <gerv@mozilla.org>; mozilla-dev-security-policy@
>>> lists.mozilla.org
>>> *Subject:* Re: CA Validation quality is failing
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> There isn't anything in our CPS directly. However, we state that we
>> follow
>>> the baseline requirements in the CPS. The baseline requirements give a
>>> profile for the state field. We weren't sure this was strictly followed.
>>>
>>> We finished our validation review over the weekend.   There are about
>> 3000
>>> older certs with information indicating a field was not applicable (such
>> as
>>> a "-", "N/A", etc). On top of this, we issued about 1000 certificates
>> with
>>> mismatched validation information. The mismatched information can be
>>> divided into about 850 certificates with numbers in the state field.
>> These
>>> numbers indicate a location code that was provided by the auto-populator.
>>> The remaining 150 are certificates with "Select", a state, or a postal
>> code
>>> improperly included in the certificate.  The root issue was a combination
>>> of the auto-populator inserting incorrect data into the cert request and
>>> our validation staff not properly updating the certificate information
>>> after completing the validation process.
>>>
>>> Based on these results, we propose the following remediation plan:
>>> 1. We already removed the auto-populator from our CSR and certificate
>>> order generators.
>>> 2. We already blocked this information on the CA side from included in
>>> signed SSL/TLS objects.
>>> 3. We will revoke the 150 certificates with mismatched information.
>>> 4. We plan to let the remaining 3850 expire normally but will correct the
>>> certificate for all future orders (including rekeys).
>>>
>>> Is this an acceptable plan? We are proposing not revoking the 3850
>>> certificates because the information isn't misleading, the information is
>>> accurate, and there isn't a risk posed to Mozilla's users by inclusion of
>>> the numeric location code or not applicable indicator. Any thoughts?
>>>
>>>
>>>
>>> (With a Google hat on)
>>>
>>>
>>>
>>> Jeremy,
>>>
>>>
>>>
>>> I think with the information you've shared so far, that sounds like a
>>> reasonable plan from Google's perspective for the 3000 certificates. I
>>> think there's at least a little concern about the EV nature for the 850
>>> side, but just trying to understand more here what the implications would
>>> be. Is this exclusively the state, or does it also extend to the
>>> jurisdiction* fields? Or is this only for EV?
>>>
>>>
>>>
>>> Would you be able to share a spreadsheet or details for those, in the
>>> spirit of transparency? I think if you can share those details, it's
>>> reasonable to avoid revoking, and anything specific that might represent
>> a
>>> security/compat risk to an Application Software Supplier (i.e.
>> 4.9.1.1(15)
>>> ), we can look into separately.
>>>
>>>
>>>
>>> Thank you for
>>>
>>> 1) Disclosing the details to a sufficient level of detail immediately
>>>
>>> 2) Providing regular updates and continued investigation
>>>
>>> 3) Confirming the acceptability of the plan before implementing it, and
>>> with sufficient detail to understand the implications
>>>
>>>
>>>
>>> These are several of the factors we weighed when considering the
>>> implications/risk of not revoking.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

0
Rob
5/2/2017 3:30:44 PM
------=_NextPart_000_016F_01D2C33C.D24E3300
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit

Thanks!

The revocation timeline changes are coming today/tomorrow morning.

-----Original Message-----
From: Gervase Markham [mailto:gerv@mozilla.org]
Sent: Tuesday, May 2, 2017 4:55 AM
To: ryan@sleevi.com; Jeremy Rowley <jeremy.rowley@digicert.com>; 
mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On 02/05/17 00:01, Ryan Sleevi wrote:
> Thank you for
> 1) Disclosing the details to a sufficient level of detail immediately
> 2) Providing regular updates and continued investigation
> 3) Confirming the acceptability of the plan before implementing it,
> and with sufficient detail to understand the implications

I echo Ryan's comments here. I'm happy with your remediation plan, and think 
there's enough wiggle room in the BRs and Mozilla policy that revocation of 
the certs with "N/A" etc. is avoidable.

I still think we need to address that 24-hour revocation requirement to be a 
bit more nuanced, but that's a separate discussion :-)

Gerv


------=_NextPart_000_016F_01D2C33C.D24E3300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTAyMTgwODM0WjAj
BgkqhkiG9w0BCQQxFgQUUUz6GK7oq7BUUfY0sV24AXyKBdAwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAK7KO474rQSdtyxz002hkUQAxxVCWw9Y4a8svAqZ
oscbMhazar8hSLHBv8hUY8vVXAH7bEPsxesyTTbIOx1xbrcMxaL/DnCaxiBoURfjcFVgXE6fX0QV
LhaYA50d2+ZWOH6n//Jw389f6mX0kx+L+VDozsbwGKtXIFc892YfuXtWadVhu9dg1XwiyJdNKxm4
zgKJp8VvMTStYpDecnXSQClYXzhZSTB21Lqr8BdeqiS/34btXP03iydNz8+5B+KYD6y/yKL9A+qL
L0/LtvgRNzFlsupU2CWRb7fUI0HW7YSQLjZ/SQCdc7QiTtUoZudLJarRUDWgjj9THVGPLjSvtM8A
AAAAAAA=

------=_NextPart_000_016F_01D2C33C.D24E3300--
0
Jeremy
5/2/2017 6:08:34 PM
------=_NextPart_000_0173_01D2C33C.E0341750
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Okay =E2=80=93 we=E2=80=99ll add them all to CT over the next couple of =
days.

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Tuesday, May 2, 2017 9:08 AM
To: Jeremy Rowley <jeremy.rowley@digicert.com>
Cc: ryan@sleevi.com; Gervase Markham <gerv@mozilla.org>; =
mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: CA Validation quality is failing

=20

(Still wearing Google Hat in this context)=20

=20

I think sharing a list (in CT) of the certs is good and can help verify =
the assertions made here :)

=20

But overall, I think this sounds right and the risk is minimal to our =
users, so not revoking still sounds good :)

=20

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley =
<jeremy.rowley@digicert.com <mailto:jeremy.rowley@digicert.com> > wrote:

Certainly happy to share more info. The search was for all EV and OV =
certs. Of the 4000 certificates detected, 101 certificates are EV. Of =
these EV certificates, 17 would be included in the proposed revocation. =
The rest have the =E2=80=9CN/A=E2=80=9D issue. This is just the =
locality/state/zip. The jurisdiction of incorporation processes =
separately and doesn=E2=80=99t have the same auto-populate tool.

=20

More info:

78 certs had non-US states populated with US states (thanks to the =
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

=20

What else would you like to know?

=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com <mailto:ryan@sleevi.com> ]=20
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.rowley@digicert.com =
<mailto:jeremy.rowley@digicert.com> >
Cc: Gervase Markham <gerv@mozilla.org <mailto:gerv@mozilla.org> >; =
mozilla-dev-security-policy@lists.mozilla.org =
<mailto:mozilla-dev-security-policy@lists.mozilla.org>=20
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we =
follow the baseline requirements in the CPS. The baseline requirements =
give a profile for the state field. We weren't sure this was strictly =
followed.

We finished our validation review over the weekend.   There are about =
3000 older certs with information indicating a field was not applicable =
(such as a "-", "N/A", etc). On top of this, we issued about 1000 =
certificates with mismatched validation information. The mismatched =
information can be divided into about 850 certificates with numbers in =
the state field. These numbers indicate a location code that was =
provided by the auto-populator.  The remaining 150 are certificates with =
"Select", a state, or a postal code improperly included in the =
certificate.  The root issue was a combination of the auto-populator =
inserting incorrect data into the cert request and our validation staff =
not properly updating the certificate information after completing the =
validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate =
order generators.
2. We already blocked this information on the CA side from included in =
signed SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct =
the certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 =
certificates because the information isn't misleading, the information =
is accurate, and there isn't a risk posed to Mozilla's users by =
inclusion of the numeric location code or not applicable indicator. Any =
thoughts?

=20

(With a Google hat on)

=20

Jeremy,

=20

I think with the information you've shared so far, that sounds like a =
reasonable plan from Google's perspective for the 3000 certificates. I =
think there's at least a little concern about the EV nature for the 850 =
side, but just trying to understand more here what the implications =
would be. Is this exclusively the state, or does it also extend to the =
jurisdiction* fields? Or is this only for EV?

=20

Would you be able to share a spreadsheet or details for those, in the =
spirit of transparency? I think if you can share those details, it's =
reasonable to avoid revoking, and anything specific that might represent =
a security/compat risk to an Application Software Supplier (i.e. =
4.9.1.1(15) ), we can look into separately.

=20

Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and =
with sufficient detail to understand the implications

=20

These are several of the factors we weighed when considering the =
implications/risk of not revoking.

=20

=20


------=_NextPart_000_0173_01D2C33C.E0341750
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTAyMTgwODU3WjAj
BgkqhkiG9w0BCQQxFgQUIGTmbeMWZNK2N0xfcNgCCr5QdpAwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAO5BGlad/EFWrbzguhDlWriYCw3ylvvzxnESwATq
C5748Fb64++lYEdEZuF34jDdBBRzXwvCUPSBzzX/wzQfoEoKwFa/xGWObgi+o2hps8wM1dTKdsQ/
34JlwyftwtAu6sFEYWfhCgUFmpiR+sBqgABIPxySxTeDyZuyn6xRk2omoyCT13aFWMCVl4j+oeEL
8kUzRCBC53HIMCgEUiYBPN0rXeRTozrvA4ybh2OpKTqFYqQrJQ4GpHbxrU2mEJPEEQ9bh45gI7+t
znP5P3+9G3gdzawp5goA6hix+kLxlh1V1RQ+tW3UtorsbQzaB9kF0q/8jItqZw/6x/GwNusyCeUA
AAAAAAA=

------=_NextPart_000_0173_01D2C33C.E0341750--
0
Jeremy
5/2/2017 6:08:58 PM
On 02/05/2017 17:30, Rob Stradling wrote:
> On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:
>> I know several CAs are using certlint
>> (https://github.com/awslabs/certlint)
>> as a pre-issuance check that the cert they're about to issue doesn't have
>> any programmatically detectable deficiencies; if it doesn't already cover
>> some of these cases, it'd be great to add them as a technical means for
>> ensuring that this doesn't regress -- things like N/A should be an easy
>> enough check to add I'd think.
>
> Simple project idea (perhaps for https://github.com/cabforum):
>
> A CSV file that contains 2 items per line:
> 1. An optional comma-separated list of Subject attribute shortnames.
> 2. A string that a CA should probably not encode as a complete Subject
> attribute.
>
> e.g.,
> "OU,ST,L","N/A"
> ,"."
> "O","Internet Widgits Pty Ltd"
>
> Anyone (CA representatives, industry researchers, etc, etc) would be
> able to submit PRs, CAs would be invited to consult this list when
> evaluating certificate requests, and certlint would be able to report on
> "violations".
>

For simplicity and consistency with usual best development practices
("3rd normal form"), perhaps at most one attribute shortname in column
1.


e.g. Your example would be written as:

"OU","N/A"
"ST","N/A"
"L","N/A"
,"."
"O","Internet Widgits Pty Ltd"



>> ...



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0
Jakob
5/3/2017 2:09:41 AM
------=_NextPart_000_0209_01D2C897.315E5B90
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Okay - all certs were added to the CT log.  We're now working through =
revocation.

-----Original Message-----
From: dev-security-policy =
[mailto:dev-security-policy-bounces+jeremy.rowley=3Ddigicert.com@lists.mo=
zilla.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, May 2, 2017 12:09 PM
To: ryan@sleevi.com
Cc: mozilla-dev-security-policy@lists.mozilla.org; Gervase Markham =
<gerv@mozilla.org>
Subject: RE: CA Validation quality is failing

Okay =E2=80=93 we=E2=80=99ll add them all to CT over the next couple of =
days.

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com]=20
Sent: Tuesday, May 2, 2017 9:08 AM
To: Jeremy Rowley <jeremy.rowley@digicert.com>
Cc: ryan@sleevi.com; Gervase Markham <gerv@mozilla.org>; =
mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: CA Validation quality is failing

=20

(Still wearing Google Hat in this context)=20

=20

I think sharing a list (in CT) of the certs is good and can help verify =
the assertions made here :)

=20

But overall, I think this sounds right and the risk is minimal to our =
users, so not revoking still sounds good :)

=20

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley =
<jeremy.rowley@digicert.com <mailto:jeremy.rowley@digicert.com> > wrote:

Certainly happy to share more info. The search was for all EV and OV =
certs. Of the 4000 certificates detected, 101 certificates are EV. Of =
these EV certificates, 17 would be included in the proposed revocation. =
The rest have the =E2=80=9CN/A=E2=80=9D issue. This is just the =
locality/state/zip. The jurisdiction of incorporation processes =
separately and doesn=E2=80=99t have the same auto-populate tool.

=20

More info:

78 certs had non-US states populated with US states (thanks to the =
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

=20

What else would you like to know?

=20

Jeremy

=20

From: Ryan Sleevi [mailto:ryan@sleevi.com <mailto:ryan@sleevi.com> ]=20
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.rowley@digicert.com =
<mailto:jeremy.rowley@digicert.com> >
Cc: Gervase Markham <gerv@mozilla.org <mailto:gerv@mozilla.org> >; =
mozilla-dev-security-policy@lists.mozilla.org =
<mailto:mozilla-dev-security-policy@lists.mozilla.org>=20
Subject: Re: CA Validation quality is failing

=20

=20

=20

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy =
<dev-security-policy@lists.mozilla.org =
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we =
follow the baseline requirements in the CPS. The baseline requirements =
give a profile for the state field. We weren't sure this was strictly =
followed.

We finished our validation review over the weekend.   There are about =
3000 older certs with information indicating a field was not applicable =
(such as a "-", "N/A", etc). On top of this, we issued about 1000 =
certificates with mismatched validation information. The mismatched =
information can be divided into about 850 certificates with numbers in =
the state field. These numbers indicate a location code that was =
provided by the auto-populator.  The remaining 150 are certificates with =
"Select", a state, or a postal code improperly included in the =
certificate.  The root issue was a combination of the auto-populator =
inserting incorrect data into the cert request and our validation staff =
not properly updating the certificate information after completing the =
validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate =
order generators.
2. We already blocked this information on the CA side from included in =
signed SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct =
the certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 =
certificates because the information isn't misleading, the information =
is accurate, and there isn't a risk posed to Mozilla's users by =
inclusion of the numeric location code or not applicable indicator. Any =
thoughts?

=20

(With a Google hat on)

=20

Jeremy,

=20

I think with the information you've shared so far, that sounds like a =
reasonable plan from Google's perspective for the 3000 certificates. I =
think there's at least a little concern about the EV nature for the 850 =
side, but just trying to understand more here what the implications =
would be. Is this exclusively the state, or does it also extend to the =
jurisdiction* fields? Or is this only for EV?

=20

Would you be able to share a spreadsheet or details for those, in the =
spirit of transparency? I think if you can share those details, it's =
reasonable to avoid revoking, and anything specific that might represent =
a security/compat risk to an Application Software Supplier (i.e. =
4.9.1.1(15) ), we can look into separately.

=20

Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and =
with sufficient detail to understand the implications

=20

These are several of the factors we weighed when considering the =
implications/risk of not revoking.

=20

=20


------=_NextPart_000_0209_01D2C897.315E5B90
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw
ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx
FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE
AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY
YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g
1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2
bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ
1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID
AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS
y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT
PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy
CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3
bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt
bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH
Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp
Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI
QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx
FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln
aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM
jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH
M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq
sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV
D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd
l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8
inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w
HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG
N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww
eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI
KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk
SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf
/K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB
zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A
f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF
5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw
ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx
MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093
pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX
PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1
vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S
p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC
n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG
AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E
ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290
Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm
MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz
ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA
ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ
AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA
ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh
AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA
eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G
A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d
h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE
V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd
GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo
GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX
BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE
ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp
Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTA5MTMzODA0WjAj
BgkqhkiG9w0BCQQxFgQUkE1TziuoBqSeK/bn7wBhaWZblHIwgYgGCSsGAQQBgjcQBDF7MHkwZTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0
LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK
2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0
IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB
c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ
YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAHM8Z5ZwJA4fUoN/pvThowcd67kRkAVhhxa8pe/D
n8ftp1rhgjoMID4dOkd4y3dj5MZQePbtPd78CxmIweCGFF3lW3ibXciDasSIk5tiTBblZC7ljOCt
LpD6mpNhmYZ08DIkcklDYlVanff7vQ9T1veuLjnBQag9ztTKd+tOPNeyJZFrXI8tbw7YJWRYTQ3H
gzF5HNmj9yu1iYDxkHe8TO9CazXKqWBslQl+VSq3/yJkpttm/myO7EqGRvqoKlIMqx5OlPqkySr5
P5Tiltu9vdBjV2M4jcCuYPFO/oYlb/0KImIDGB2i/KRm+BE0neBvlyBsrEzhUEyH0eNd/AMqitcA
AAAAAAA=

------=_NextPart_000_0209_01D2C897.315E5B90--
0
Jeremy
5/9/2017 1:38:05 PM
Reply: