Bonsoir, Le mercredi 28 octobre 2015 14:53:39 UTC+1, [email protected] a écrit :
> > However, https://crt.sh/?id=8983568 shows a TLS server certificate valid > > for 4 years and delivered in 2015. > As already it has been commented, this subCA was developed for a private and > restricted environment and it was considered that ISA CA wasn't under the > scope of this request. However, as discussed, we have noticed that this SubCA > is within the scope of this request. We are currently analyzing all the > details to resolve issues related to ISA CA. In the next days we will take a > decision about it. This is another problem. ISA CA MUST be audited and disclosed, as discussed with other participants. The problem raised here is that the CPS is the root CPS, and this root CPS says that all end-entity certificates are valid for 3 years max. That is, even if ISA CA had been a technically constrained subCA, and as such unaudited, the certificates issued under it should still be limited to 3 years. > > 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). > About the subjectAlternativeName extension the BRs establish that this > extension must contain at least a dNSName and our certificates are compliant > with this requirement. What you're describing is the EV Guidelines, section 9.2.2: "This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject’s server." BR, section 7.1.4.2.1 says: "Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server." There's no other alternative. > In fact, you can see several CAs included in Mozilla CA List that set the > value of SAN extension similarly as we do in order to comply with regulations > related to eGovernment and identification of eOffices. That should be raised as a noncompliance, then. > > 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? > This OID was included for backward compatibility of several information > systems widely used on eAdministration. Do certificates issued under the "AC FNMT Usuarios" CA (for example) also have this OID? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
