Le mercredi 21 octobre 2015 21:18:26 UTC+2, Kathleen Wilson a écrit : > FNMT has applied to include the "AC RAIZ FNMT-RCM" root certificate and > enable the Websites trust bit. [...] > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=435736
[...] > Document Repository: > https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion > CP: > https://www.sede.fnmt.gob.es/documents/11614/67070/dpc_componentes_english.pdf/ > > > CPS: https://www.sede.fnmt.gob.es/documents/11614/137578/dpc_english.pdf/ >From 31/10/2012, the CPS states that end-entity certificates are valid for a >maximum of 3 years. However, https://crt.sh/?id=8983568 shows a TLS server certificate valid for 4 years and delivered in 2015. > * CA Hierarchy > > ** This root has internally-operated subordinate CAs > - "AC Componentes Informáticos" issues certificates for SSL Servers and > code signing. > - "AC Administración Pública" is an updated version of the "APE CA" in > order to meet new requirements from Spanish Government about > certificates of Public Administrations. > - "APE CA" is no longer used. > > * This request is to enable the Websites trust bit. > > ** From dpc_componentes_english.pdf... > > > * EV Policy OID: Not applicable; not requesting EV treatment. > > * Root Cert URL: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt > > * Test Website: https://www.sede.fnmt.gob.es/certificados The SubjectAlternativeName extension of this certificate contains a directoryName entry, this isn't BR-compliant (see section 7.1.4.2.1 of BR 1.3.1). Why did you include an anyExtendedKeyUsage OID in the EKU extension, in addition to the serverAuth? Do you also add this OID in non TLS server certificates? > * CRL > ldap://ldapape.cert.fnmt.es/CN=CRL164,CN=AC%20Administraci%F3n%20P%FAblica,OU=CERES,O=FNMT-RCM,C=ES?certificateRevocationList > ldap://ldapfnmt.cert.fnmt.es/CN=CRL,OU=AC%20RAIZ%20FNMT-RCM,O=FNMT-RCM,C=ES?authorityRevocationList; There's 228 CRLs for this subCA. All are correctly restricted with a critical IssuingDistributionPoints extension. Good luck for OneCRL/CRLSets maintainers. The LDAP URLs are non compliant, because of not being UTF8 (it's mandatory for LDAP), but I guess this isn't a problem for Mozilla's application. Anyway, any request returns an error because of this UTF8 problem. Change the "%F3" into "%C3%B3" and the "%FA" into "%C3%BA" for the URLs to work. Looking at the CRLs content shows that a lot of certificates don't have the required 20bits minimum entropy (the serial number is sometimes a monotonic sequence). Did this practice stop? For all Sub-CAs? If yes, when? > * OCSP > http://ocspape.cert.fnmt.es/ocspape/OcspResponder > http://ocspap.cert.fnmt.es/ocspap/OcspResponder These OCSP responders give a "good" answer for a nonexistent certificate. > * Audit: FNMT is audited annually by PWC according to the WebTrust CA > and WebTrust BR criteria. I exchanged email with the auditor to confirm > the authenticity of the audit statement at this URL: > https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
