Thanks Erwann. I'll try to answer to your questions.
> 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. > 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. 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. > 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. > Change the "%F3" into "%C3%B3" and the "%FA" into "%C3%BA" for the URLs to > work. Thanks for this info. We have been working in that and we are analyzing several scenarios that guarantee backward compatibility with several old apps. > 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? Yes, this practice stopped on December 2011. > These OCSP responders give a "good" answer for a nonexistent certificate. Yes, it has been detected and we have been working in this issue for a time. Currently, we plan to solve it within next weeks. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
