On 1/15/16 4:42 AM, [email protected] wrote:
Hi all.

We have developed a solution plan for this issues.

I believe that some of the concerns that were raised have been resolved,
and that the remaining open concerns are as follows. Please reply if I
missed any other items that still need to be resolved.

1) This root certificate has subordinate certificates that are not
technically constrained and not audited/disclosed according to sections
8-10 of Mozilla's CA Certificate Policy. The noted subCAs are "AC FNMT
Usuarios" (doesn't issue server certificates) and "ISA CA" (server
certificates are issued exclusively to a very restricted (almost
private) environment). Unless there are technical constraints on the
intermediate CA certificates representing those subCAs which make it
impossible for them to issue TLS or S/MIME certificates, they are
in-scope for this inclusion request, because they are a potential source
of mis-issuance which puts users of the Mozilla trust store at risk.

We are going to audit in-scope CAs. Finally our FNMT-RCM CAs hierarchy audit 
scheme will be as follows:

+ AC RAIZ FNMT-RCM
    + AC Administración Pública
      - Issues: SSL certs, QCP certs
      - Audits: WebTrust for CAs, WebTrust SSL BRs, ETSI 101 456
    + AC Componentes Informáticos
      - Issues: SSL certs
      - Audits: WebTrust for CAs, WebTrust SSL BRs
    + AC FNMT Usuarios
      - Issues: issues QCP certs, not restricted by EKU extension
      - Audits: (ETSI 101 456 or WebTrust for CAS) and audit of non-existence 
of SSL certs
    + ISA CA Will be revoked in early 2016
    + AC APE No longer used. Will be revoked in early 2016

As you can see, the two subCAs in-scope will be audited ("AC Usuarios) and revoked ("ISA 
CA"). Also, "AC APE" which is no longer used will be revoked

2) The allowed methods of verifying domain name ownership/control must
be in compliance with section 3.2.2.4 of version 1.3 (or later) of the
Baseline Requirements.

ISA CA is going to be revoked.

With this audit scheme, the remaining open issues would be solved.



I think this approach is reasonable, because I think the additional annual audit check to ensure the AC FNMT Usuarios intermediate has not issued SSL certs meets the intention of Mozilla's Policy and the BRs.

Does anyone see any problems with this approach?

Thanks,
Kathleen

_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to