Le vendredi 1 novembre 2013 23:58:59 UTC+1, Kathleen Wilson a écrit : > WoSign has applied to include the “Certification Authority of WoSign” > and “CA WoSign” root certificates, turn on all three trust bits for both > root certs, and enable EV treatment for both root certs.
[...] > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=851435 [...] > * The primary documents are as follows: > Document Repository: http://www.wosign.com/policy/cps_e.htm > CPS (English): http://www.wosign.com/policy/WoSign-Policy-1_2_2.pdf [...] > * The request is to turn on all three trust bits, and enable EV treatment. [...] > * EV Policy OID > Certification Authority of WoSign: 1.3.6.1.4.1.36305.2 > CA WoSign: 1.3.6.1.4.1.36305.6 Why are there 2 different OIDs for EV, under the same arc belonging to the same company? Your policy only defines the .2 one. > * Root Cert URL > Certification Authority of WoSign: http://www.wosign.com/Root/WS_CA1_NEW.crt > CA WoSign: http://www.wosign.com/Root/ws_ca2_new.crt All the tested certificates have the countryName element encoded as UTF8, which is invalid (only PrintableString is allowed, see X.520/6.3.1). This mistake is repeated from the roots down to the subscriber certificates, and extends to OCSP responder certificates. > * Test Website: > Certification Authority of WoSign: https://root1evtest.wosign.com > CA WoSign: https://root2evtest.wosign.com The jurisdictionOfIncorporationCountryName is also declared as an UTF8String, it MUST be a PrintableString. Non blocking: do you think it is really necessary to add Microsoft and Netscape SGC OIDs in the EKU? It's useless unless your customers have very old software versions *and* you alter their trust settings to grant this use to your root. > * CRL > Certification Authority of WoSign: > http://ocsp1.wosign.com/ca1 > http://ocsp1.wosign.com/class4/server/ca1 > http://ocsp.wosign.com/class3/server/ca > http://ocsp.wosign.com/class1/server/ca I guess this was a mistake in cut/paste operation, the right URLs seem to be http://crls1.wosign.com/ca1.crl http://crls1.wosign.com/ca1-server-4.crl http://crls.wosign.com/server-3.crl http://crls.wosign.com/server-1.crl Those 4 URLs (and the 4 ones declared below under the second root CA) return a CRL with a MIME type "text/plain". This must be "application/pkix-crl". The AIA:CAIssuers URLs return objects with a MIME type equal to "text/plain" instead of "application/pkix-cert" or "application/pkcs7-mime" (depending on the real object). > CA WoSign: > http://crls1.wosign.com/ca2.crl > http://crls1.wosign.com/ca2-server-4.crl > http://crls.wosign.com/ca2-server-3.crl > http://crls.wosign.com/ca2-server-1.crl > CPS section 7.8: CRL Next Update: 48 hours > > * OCSP > Certification Authority of WoSign: > http://ocsp1.wosign.com/ca1 > http://ocsp1.wosign.com/class4/server/ca1 > http://ocsp.wosign.com/class3/server/ca > http://ocsp.wosign.com/class1/server/ca > CA WoSign: > http://ocsp2.wosign.com/ca2 > http://ocsp2.wosign.com/class4/server/ca2 > http://ocsp2.wosign.com/class3/server/ca2 > http://ocsp2.wosign.com/class1/server/ca2 OCSP responders don't have the OcspNoCheck extension, but include this OID in the EKU extension. This isn't BR compliant. Non blocking: the OCSP service doesn't react well with non URL-encoded GET requests (seems to close the socket with no answer). > CPS section 4.9.9, OCSP: The current CRLs are reloaded at least every 60 > minutes. Does that mean that OCSP responders don't perform a database lookup and don't comply with BR 13.2.6 rule on non-issued certificates? > * Audit: Annual audits are performed by Ernst & Young according to the > WebTrust criteria. > Audit Report: https://cert.webtrust.org/SealFile?seal=1443&file=pdf This audit doesn't cover the second root CA, despite the fact that is was conducted in January 2013 and the second root CA seems to exist since 2009. > EV Readiness Audit Report: > https://bugzilla.mozilla.org/attachment.cgi?id=725294 This audit doesn't limit to the first root CA, has been performed by the same auditor at the same moment. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
